Skip to main content

5. URL de certificat client

5.1. Traitement du message Hello du client​

Afin d'indiquer le support de multiples types de certificats, les clients PEUVENT inclure une extension de type "client_certificate_url" dans le client hello (étendu). Le champ "extension_data" de cette extension DOIT contenir "CertChainType", où :

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;

struct {
    CertChainType type;
} CertificateURL;

Si l'extension client_certificate_url est envoyée, elle DOIT contenir une valeur de la liste énumérée CertChainType. Les clients qui envoient cette extension DOIVENT être préparés à gérer les messages CertificateURL contenant soit le type individual_certs soit pkipath.

L'extension client_certificate_url peut être considérée comme une indication au serveur que le client se préparera, si le serveur l'accepte, à envoyer des URL qui pointent vers les certificats dans son message Certificate au lieu des certificats eux-mêmes. De cette façon, les serveurs peuvent éviter de recevoir un grand message Certificate du client (par exemple via une liaison commutée à faible bande passante).

5.2. Traitement du message Hello du serveur​

Un serveur qui reçoit une extension client_certificate_url dans le client hello PEUT choisir d'autoriser le client à envoyer des URL de certificat au lieu de certificats en incluant une extension de type "client_certificate_url" dans le server hello (étendu). Si le serveur prend en charge plusieurs encodages de chaîne de certificats pour les URL, il peut utiliser le CertChainType dans l'extension client_certificate_url pour déterminer lequel des types est préféré par le client. Le champ "extension_data" de cette extension DOIT être vide.

Les clients recevant une extension client_certificate_url dans le server hello indiquant que le serveur est prêt à accepter des URL de certificat PEUVENT choisir d'envoyer des URL de certificat comme décrit dans la Section 5.3 au lieu d'envoyer des certificats.

5.3. Message Certificate du client​

Normalement, si une authentification de client basée sur des certificats est demandée par le serveur, le client DOIT envoyer le message Certificate contenant sa chaîne de certificats. Cependant, si le serveur a accepté l'extension client_certificate_url, le client PEUT à la place envoyer le message CertificateURL (étendu), où :

enum {
    X509(0), OpenPGP(1), (255)
} CertificateType;

struct {
    CertificateType cert_type;
    uint16 url_and_hash_len;
    URLAndOptionalHash url_and_hash_list[1..2^16-1];
} CertificateURL;

struct {
    opaque url<1..2^16-1>;
    unint1 padding;
    opaque SHA1Hash[20];
} URLAndOptionalHash;

unint1 URLAndOptionalHash.padding = 0;

Ici, "url_and_hash_list" contient une séquence de URLs (et de hashes optionnels) dans l'ordre croissant de préférence. Chacune de ces URLs devrait pointer vers un certificat individuel ou vers une séquence de certificats contenant la chaîne de certificats du client. Les serveurs DOIVENT être préparés à gérer des URLs HTTP [RFC2616] qui pointent vers des URLs HTTP non valides, et PEUVENT supporter d'autres schémas tels que FTP [RFC0959] et HTTPS [RFC2818] (qui peut être utilisé pour identifier et authentifier les serveurs qui hébergent les URLs de certificats). Les URLs ne DOIVENT PAS spécifier un port autre que le port par défaut pour le schéma d'URL. Le CertificateType DOIT être X509. S'il y a d'autres valeurs de CertificateType présentes, elles PEUVENT être ignorées par le serveur.

Lorsque des URLs sont utilisées, il existe deux manières dont la chaîne de certificats peut être structurée. Le type individual_certs indique que chaque URL de certificat pointe vers un seul certificat au format DER [X690]. Le type pkipath indique que la séquence d'URLs pointera vers une séquence de certificats, dans l'ordre décrit par PkiPath [RFC4366] et [RFC3280]. Une telle séquence peut être produite en codant la séquence pkiPath [RFC3280], Section 10.1 en utilisant les conventions d'encodage DER [X690].

Le serveur doit décider s'il acceptera d'utiliser les URLs ou s'il exigera que le client envoie le message Certificate normal contenant les certificats. Si le serveur accepte les URLs, alors le traitement du serveur dépend du type de chaîne de certificats qu'il reçoit.

Si le serveur a reçu une liste de type individual_certs, il DEVRAIT essayer les URLs dans l'ordre dans lequel elles ont été reçues jusqu'à ce qu'il obtienne avec succès les certificats requis. Si une URL ne peut pas être mise en cache à un endroit auquel le serveur peut accéder (par exemple, parce que le protocole de récupération ne permet pas la mise en cache), le serveur devrait essayer l'URL suivante dans la liste ; la décision de faire une nouvelle tentative avec l'URL d'origine après un délai devrait dépendre du protocole utilisé pour récupérer l'URL et du code de réponse reçu.

Si le serveur a reçu une liste de type pkipath, il DEVRAIT essayer les URLs dans l'ordre jusqu'à ce qu'il obtienne avec succès un ensemble complet de certificats. Les considérations de mise en cache sont les mêmes que pour le traitement individual_certs. Il est possible qu'un serveur reçoive plusieurs URLs pkipath où un sous-ensemble des certificats est le même entre différents PkiPaths. Dans ce cas, le serveur PEUT utiliser les certificats qu'il a déjà mis en cache lors du traitement d'une URL pkipath ultérieure.

L'un des éléments dans url_and_hash_list PEUT avoir un hachage associé (voir la discussion dans la Section 5.4 pour les détails). Les serveurs qui reçoivent un message CertificateURL qui contient au moins un hachage DOIVENT vérifier que le hachage du certificat récupéré (ou de l'ensemble de certificats pour pkipath) correspond au hachage donné. Si le certificat (ou l'ensemble de certificats) ne correspond pas au hachage donné, le serveur DOIT abandonner la connexion avec une alerte bad_certificate_hash_value(114).

5.4. Informations de hachage de certificat​

Le certificat URL peut également contenir un hachage SHA-1 [SHA] des données encodées DER qui correspondent à l'URL. Cela permet au serveur de faire correspondre un certificat qu'il a déjà mis en cache avec les URLs dans le message. Si le serveur a mis en cache le(s) certificat(s) correspondant(s), il n'a pas besoin de récupérer le certificat depuis l'URL. Lorsque le remplissage a la valeur zéro, le hachage est présent ; si le remplissage a une valeur autre que zéro, il n'y a pas de hachage présent, et le reste de URLAndOptionalHash après l'URL est absent.

Lorsque le hachage est présent pour le type individual_certs, le hachage est calculé sur les données encodées DER qui correspondent à l'URL (c'est-à-dire le seul certificat récupéré depuis l'URL). Lorsque le hachage est présent pour le type pkipath, le hachage est calculé sur la séquence complète encodée pkiPath ; c'est-à-dire que le hachage couvre la totalité des données octets encodés DER pour la séquence de certificats.

L'URL et le hachage, si présent, permettent au serveur d'identifier facilement un certificat mis en cache même lorsque la chaîne est du type individual_certs. Notez que la récupération du certificat pourrait échouer soit parce que le serveur ne peut pas accéder à l'URL soit parce que le certificat a été déplacé depuis que le client l'a vu pour la dernière fois. Dans ce dernier cas, il se peut que le client doive recharger le certificat et refaire le handshake pour fournir au serveur un hachage de certificat qui est à jour.

5.5. Traitement côté serveur du message CertificateURL​

Lorsque le serveur reçoit un message CertificateURL, il DOIT valider que le message est correctement formé conformément à la spécification dans la Section 5.3. En particulier :

  • Chaque URL DOIT avoir un schéma de récupération supporté.
  • Les URLs NE DOIVENT PAS spécifier un port autre que le port par défaut pour le schéma.
  • Le CertificateType DOIT être une valeur que le serveur comprend. Les serveurs DOIVENT comprendre le type X509.

Si le serveur détermine que le message CertificateURL est mal formé, il DOIT abandonner la connexion avec une alerte decode_error.

Le serveur PEUT tenter de récupérer les certificats référencés dans le message CertificateURL. Si cette récupération échoue pour toutes les URLs contenues dans le message, le serveur PEUT avorter la connexion avec une alerte certificate_unobtainable(111).

Le serveur DOIT effectuer les vérifications de certificat décrites dans [RFC5246], en utilisant le ou les certificats récupérés. Si les vérifications échouent, le serveur DOIT abandonner la connexion avec une alerte appropriée comme défini dans [RFC5246].

Si le serveur sélectionne un certificat mis en cache sur la base d'un hachage de certificat, et que le contenu de ce certificat diffère du certificat qui aurait été récupéré depuis une URL, le serveur DOIT considérer ce scénario comme une attaque et PEUT abandonner la connexion avec une alerte bad_certificate_hash_value(114).

Last updated on