1. Introduction

1. Introduction

Traditionnellement, les clés publiques des clients et serveurs TLS sont obtenues dans des conteneurs PKIX en bande dans le cadre de la procédure de handshake TLS et sont validées à l'aide d'ancres de confiance (trust anchors) basées sur une autorité de certification (CA) [PKIX]. Cette méthode peut ajouter une relation de confiance complexe qui est difficile à valider. Des exemples d'une telle complexité peuvent être vus dans [Defeating-SSL]. TLS est cependant également couramment utilisé avec des certificats auto-signés (self-signed certificates) dans des déploiements plus petits où les certificats auto-signés sont distribués hors bande à tous les points de terminaison de protocole impliqués. Cette pratique nécessite cependant toujours la surcharge de la génération de certificat même si aucune des informations trouvées dans le certificat n'est réellement utilisée.

Des méthodes alternatives sont disponibles qui permettent à un client/serveur TLS d'obtenir la clé publique du serveur/client TLS :

• Le client TLS peut obtenir la clé publique du serveur TLS à partir d'un enregistrement de ressource sécurisé par DNSSEC en utilisant l'authentification basée sur le DNS des entités nommées (DANE) [RFC6698].

• La clé publique du client ou du serveur TLS est obtenue à partir d'une chaîne de certificats [PKIX] d'un serveur ou d'une page Web via le protocole d'accès à l'annuaire léger [LDAP].

• La clé publique du client et du serveur TLS est provisionnée dans l'image du micrologiciel (firmware) du système d'exploitation et mise à jour via des mises à jour logicielles. Par exemple :

  Certains objets intelligents (smart objects) utilisent le protocole d'application contraint basé sur UDP [CoAP] pour interagir avec un serveur Web afin de télécharger des données de capteur à intervalles réguliers, telles que des relevés de température. CoAP peut utiliser DTLS pour sécuriser la communication client-serveur. Dans le cadre du processus de fabrication, le dispositif intégré peut être configuré avec l'adresse et la clé publique d'un serveur CoAP dédié, ainsi qu'une paire clé publique/clé privée pour le client lui-même.

Ce document introduit l'utilisation de clés publiques brutes (raw public keys) dans TLS/DTLS. Avec les clés publiques brutes, seul un sous-ensemble des informations trouvées dans les certificats typiques est utilisé : à savoir, la structure SubjectPublicKeyInfo d'un certificat PKIX qui contient les paramètres nécessaires pour décrire la clé publique. Les autres paramètres trouvés dans les certificats PKIX sont omis. En omettant diverses structures liées aux certificats, la clé publique brute résultante est maintenue assez petite par rapport au certificat d'origine, et le code pour traiter les clés peut être plus simple. Seul un analyseur ASN.1 minimaliste est nécessaire ; le code pour la validation du chemin de certification et d'autres traitements liés à PKIX n'est pas requis. Notez cependant que la structure SubjectPublicKeyInfo est toujours au format ASN.1. Pour réduire davantage la taille des informations échangées, cette spécification peut être combinée avec l'extension TLS Cached Info [CACHED-INFO], qui permet aux pairs TLS d'échanger uniquement des empreintes de leurs clés publiques.

Le mécanisme défini ici ne fournit une authentification que lorsqu'un mécanisme hors bande est également utilisé pour lier la clé publique à l'entité présentant la clé.

La Section 3 définit la structure des deux nouvelles extensions TLS, client_certificate_type et server_certificate_type, qui peuvent être utilisées dans le cadre d'un handshake TLS étendu lorsque des clés publiques brutes doivent être utilisées. La Section 4 définit le comportement du client TLS et du serveur TLS. Des exemples d'échanges sont décrits dans la Section 5. La Section 6 décrit les considérations de sécurité avec cette approche. Enfin, dans la Section 7, ce document enregistre une nouvelle valeur dans le sous-registre IANA "TLS Certificate Types" (Types de certificats TLS) pour la prise en charge des clés publiques brutes.