Certificats X509 v3

Généralités :
L’objet d’un certificat est de certifier une clé publique. Pour utiliser une clé publique il faut être sûr de l’identité de son détenteur. La première méthode est d’avoir une relation de confiance directe avec son détenteur, comme dans le modèle "web of trust" associé à PGP ou GPG. La deuxième méthode repose sur le principe que tous les interlocuteurs ont confiance en un tiers, qui certifiera les clés en les signant. X509 est un standard définissant le format des certificats émis par ces tiers, ou émetteurs de certificats (Certificate Authority, CA ne anglais).
Il est à noter que l’utilisation de certificats ne fait que reporter la question de la confiance (en bout de chaîne, il y a forcément un émetteur qui s’auto-certifie, en qui la communauté cible des utilisateurs doit avoir confiance). Il appartient aux émetteurs de certificats, ou autorités de certification, de s’assurer que telle clé appartient bien à telle personne (ou entité), et de publier les procédures définissant cette assurance (politiques de certification).
Lorsqu’un groupe précis d’utilisateurs n’a pas la main sur l’AC ou la PKI (ou encore ICP, Infrastructure à Clés Publiques), on peut émettre des réserves sur la sécurité de l’émission et de la gestion des certificats. Les émetteurs de certificats sur internet ne sont pas, selon moi, la panacée. En particulier lorsqu’ils n’émanent pas d’institutions légitimes, en qui l’on peut avoir confiance. Lorsqu’en plus ces émetteurs se retrouvent en situation de quasi monopole...

Les certificats X509, version 3, sont utilisés (entre autres) dans les applications, protocoles et standards suivants :
SSL/TLS, IPSec, S/MIME, SET, chiffrement, authentification, signature, non-répudiation, horodatage...

Les certificats X.509 en sont à la troisième version. (quatrième maintenant ; 30.01.03)
La première date de 1988 et la seconde de 1993.
Avec la version 3 sont apparues les extensions, champs qui permettent de rendre l’utilisation des certificats beaucoup plus flexible.
C’est aussi ce qui les rend bien souvent incompatibles entre eux.

Détail des certificats :
Un certificat contient les données suivantes :

Version du certificat
Numéro de série du certificat
Description de l’algorithme de signature de l’AC
Nom de l’AC qui a généré le certificat
Période de validité
Nom de l’utilisateur auquel appartient le certificat
Valeur de la clé publique
Description de l’algorithme à utiliser avec la clé publique
Identification alternative de l’AC (optionnel)
Identification alternative de l’utilisateur (optionnel)
Extensions (optionnel)
Signature de l’AC

Les champs exacts des certificats X.509v3 sont les suivants :

(les versions auxquelles sont apparus ces champs sont entre parenthèses) :

Certificate format version (v1)

Ce champ donne la version du certificat : 1, 2 ou 3. Dans la pratique, il n’a en général pas d’implications pour l’interprétation.

Certificate serial number (v1)

Numéro de série unique, dans le domaine de confiance auquel appartient le certificat, qui l’identifie de façon unique.
C’est ce numéro de série qui sera posté dans la liste de révocation en cas de révocation.

Signature algorithm identifier for CA (v1)

Désigne le procédé utilisé par l’AC pour signer le certificat : (norme ISO). Il s’agit d’un algorithme asymétrique et d’une fonction de condensation.
Un exemple est : RSA with SHA-1.
Cette information étant répétée dans le champ CA signature (le dernier), il n’est pas forcément d’une grande utilité.

Issuer X.500 name (v1)

Spécifie le DN (Distinguished Name) dans la norme X.500 de l’AC qui a généré le certificat.
Un exemple est : c=FR, o=Boite

Validity period (v1)

Donne les dates de début et de fin de validité du certificat.
Un logiciel client utilisant les certificats doit impérativement vérifier ces dates avant utilisation, et rejeter le certificat s’il est expiré. Cela ne suffit cependant pas, car cela dépend de l’horloge de la machine cliente. On peut avoir recours à la consultation des CRL (ou LCR, Liste de Certificats Révoqués), où peut être mise l’information concernant l’expiration.

Subject X.500 name (v1)

Spécifie le DN dans la norme X.500 (... un reste -judicieux- des télécoms) de l’utilisateur possédant la partie privée de la clé publique contenue dans le certificat.
Un exemple est : c=FR, o=Jussieu, cn=Marie Curie

Subject public key information (v1)

C’est le coeur du certificat. Ce champ contient la valeur de la clé publique du détenteur du certificat et les algorithmes avec lesquels elle doit être utilisée
RSA with MD5 par exemple

Issuer unique identifier (v2)

Ce champ optionnel, qui est apparu en v2, permet de donner une seconde identification au Issuer X.500 name (l’AC) dans le cas ou celui-ci à un DN commun avec une autre AC.

Subject unique identifier (v2)

Ce champ optionnel, qui est apparu en v2, permet de donner une seconde identification au Subject X.500 name (l’utilisateur) dans le cas ou celui-ci à un DN en commun à un ou plusieurs autres utilisateurs.

Extensions : Type, Criticality, Value (v3)

Chaque extension est constituée de 3 champs :

Type : Décrit le format du champ Value. Ce peut être un nombre, une chaîne de caractères, des données complexes...

Criticality : C’est un flag d’un bit. Si une extension est marquée comme étant critique, une application qui ne saurait qu’en faire devrait en principe rejeter le certificat.
Peut créer des problèmes d’interopérabilité.

Value : Contient la valeur des données de l’extension. Celle-ci peut être un texte, une date ou même une photo (mais là, c’est quand même du vice...).

CA signature (v1)

C’est la signature de l’autorité de certification (CA). Cette signature est effectuée en passant l’ensemble du certificat au travers d’une fonction de condensation puis en chiffrant le résultat à l’aide de la clé privée de l’autorité de certification.

Les extensions X.509v3 :

Dans le standard X.509v3, il y a des extensions dites standard. Les extensions sont très importantes dans les certificats, puisqu’elles les rendent flexibles et "ajustables" à souhait (tel certificat ne peut servir que pour telle application par exemple). Mais elles sont aussi source d’incompatibilité (telle application va rejeter un certificat si elle n’y trouve pas l’extension qu’elle attend). En développant un logiciel utilisant des certificats on peut cependant l’autoriser à ne pas prendre en compte telle ou telle extension.
Par "ajustable", on entend en fait la possibilité pour une AC ou une PKI de définir une politique de sécurité de l’AC ou de la PKI. Dans cette optique, la politique peut spécifier que tel certificat ne pourra être utilisé qu’à cet usage ou définir toute autre contrainte qui rendra incompatibles des certificats émis par d’autres AC.

On peut les grouper en quatre types :

1) Informations sur les clés

2) Informations sur l’utilisation du certificat

3) Attributs des utilisateurs et des AC

4) Contraintes sur la co-certification

Dans le détail, ça donne :

1) Informations sur les clés :

Ce groupe d’extensions, qui renseigne sur l’utilisation qui doit être faite de la clé publique et du certificat, est constitué de quatre champs :

Authority Key Identifier :
Ce champ identifie de façon unique la paire de clé utilisée par l’émetteur de certificats pour signer le certificat. Il peut être utilisé par une application pour faciliter le processus de vérification de la signature du certificat dans le cas ou l’AC à utilisé plusieurs clés depuis sa mise en service.

Subject Key Identifier :

Ce champ identifie de façon unique la paire de clé dont la clé publique est contenue dans le certificat. Il peut être utile si l’utilisateur possède un historique de clés (c’est à dire que ses clés ont été renouvelées une ou plusieurs fois). Par exemple, pour déchiffrer un document chiffré avec une clé qui n’est plus celle en cours de validité, ce champ permet de retrouver rapidement la bonne clé privée.

Key usage :

Ce champ renseigne sur l’utilisation qui doit être faite de la clé.
Si le champ criticality de cette extension est à TRUE, alors la clé ne doit être utilisée que dans le but spécifié, et toute autre utilisation serait contrevenir à la politique de l’AC ou de la PKI.
Si le champ criticality de cette extension est à FALSE, alors le champ Key usage est là à titre indicatif pour faciliter les processus par exemple.
Le champs Key usage peut avoir les valeurs :

non-repudiation
certificate signing
CRL signing
digital signature
data signature
symetric key encryption for key transfer
Diffie-Hellman key agreement

Private Key Usage Period :

Ce champ donne la date d’expiration de la clé privée associée à la clé publique contenue dans le certificat. Il est en général utilisé pour les clés privées de signature (et donc contenu dans les certificats de signature dans le cas ou ils sont distincts de ceux de chiffrement), qui peuvent expirer, ce qui n’est pas le cas des clés privées de déchiffrement (il doit toujours être possible de déchiffrer des données, même si celles-ci ont été chiffrées avec une clé publique qui est maintenant expirée).

2) Informations sur l’utilisation du certificat :

Ce groupe d’extensions, qui contient deux champs, permet à un émetteur de certificats de spécifier les façons dont un certificat doit être utilisé, en accord avec la politique qu’il a définie (PC).
Les deux champs sont : Certificate Policies et Policy Mappings.

Certificate Policies :

Ce champ peut donner, soit la politique de certification qui a présidé à l’émission du certificat, soit les utilisations qui doivent être faites du certificat. Il peut spécifier ces deux informations à la fois.
Les politiques de certificats sont représentées par des Object Identifier (OID), qui sont des séries de nombres séparées par des points. Ces OID sont enregistrées au niveau international, et leur utilisation est standardisée.
Un certificat peut contenir plusieurs OID, pourvu qu’elles ne soient pas incompatibles.
Si ce champ est marqué comme étant critique, l’émetteur de certificats impose que le certificat soit utilisé conformément à la politique de certification. Dans le cas contraire, l’information est indicative ("ce certificat devrait être utilisé dans tel but" par exemple)... Libre à l’application cliente (son implémentation ou sa configuration) de respecter ou pas la criticité.

Policy Mappings :

Ce champ ne concerne que les co-certificats (le certificat émis par une AC pour certifier la clé publique (le certificat) d’une autre AC). Il permet d’associer la politique de certification de l’AC qui émet le certificat à la politique de certification indiquée dans le co-certificat. S’il est défini comme critique, il permet aux applications qui vérifient un certificat appartenant à une chaîne de certification de s’assurer qu’une politique de certification acceptable s’applique à tous les certificats.

3) Attributs des utilisateurs et des AC :

Ce groupe d’extensions (3 champs) permet de mieux spécifier l’identification des utilisateurs et des certificats.

Subject Alternative Name :

Ce champ spécifie un ou plusieurs noms uniques et supplémentaires pour le détenteur du certificat. Ils peuvent être utilisés dans les applications de messagerie, web, réseau où il peut être très utile d’identifier un utilisateur, ou une machine, autrement que par un DN. Les noms autorisés sont :

Une adresse mail
Un nom de domaine
Une adresse IP
Une adresse mail X.400
Un nom EDI
Une URL
Un nom défini par une OID

Issuer Alternative Name :

Ce champ permet de donner un nom spécifique à une AC, et les noms autorisés sont les mêmes que ceux du champ précédent.

4) Contraintes sur la co-certification :

Les trois extensions de ce groupe permettent de limiter et contrôler la confiance envers d’autres AC en cas de co-certification.

Basic Constraints :

Ce champ indique si l’utilisateur est un utilisateur final ou s’il peut être une AC. S’il peut être AC, le certificat est alors un co-certificat. On définit alors une " distance de certification ". Elle spécifie jusqu’où doit remonter une application qui veut vérifier un certificat en consultant sa CRL, et jusqu’ou est étendue la confiance dans la chaîne. Si cette distance est par exemple à 1, les utilisateurs ne peuvent que vérifier les certificats émis par l’AC défini dans le co-certificat.

Name Constraints :

Ce champs n’est utilisé que dans les co-certificats, et permet aux administrateurs de restreindre les domaines de confiance dans un domaine de co-certification. Supposons que ce site émette des certificats à mes amis, avec des noms du type : c=FR, o=cryptosec, cn=[mes amis]. J’ai un ami qui fait de même. Il émet des certificats à ses visiteurs, avec des noms du type c=FR, o=mantis, o=amis, cn=[ses visiteurs] et à ses amis, avec des noms du type c=FR, o=mantis, o=amis, cn=[ses amis]. Je veux me co-certifier avec lui, et comme c’est un ami, je fais confiance à ses amis. Mais je ne fais pas confiance à ses visiteurs. Je vais donc émettre un co-certificat qui ne va être valide que pour les certificats émis dans la branche c=FR, o=mantis, o=amis, cn=[ses amis].

Policy Constraints :

Ce champ s’applique aux co-certificats, et permet de spécifier les politiques de certification acceptables pour les certificats dépendants du co-certificat.

Pour lire un certificat, il faut lire l’ASN.1 (Abstract Syntax Notation)

C’est une grammaire abstraite qui permet de représenter des objets ou des messages. ASN.1 permet de représenter des types de données simples comme des entiers ou des types plus complexes de données comme des séquences ou des données représentées par la combinaisons de types simples.
Le codage BER (Basic Encoding Rules), ou son dérivé DER (Distinguished Encoding rules), est utilisé pour représenter concrètement les données ASN.1 en tableaux d’octets. Les codages BER et DER sont indépendants des plate-formes utilisées, ce qui permet d’échanger sans problème des données. Pour développer il existe des " compilateurs " ASN.1, et l’on travaille souvent sur des objets ASN.1 sans avoir à se plonger dans le codage lui même (voir SSLeay qui fournit ce genre de librairies).

Dans le cas d’un certificat, le codage DER en réduit les champs de données à des listes d’éléments simples (comme des entiers, des chaînes de caractères) où à des combinaisons complexes de ces derniers.
Chaque champ est ainsi décomposé en un triplet : tag, lenght et value.

tag donne le type de donnée par une convention définie par l’ISO.

lenght donne la longueur du champ " value "

value est une série d’octets qui représente les données.

Afin de permettre l’édition des certificats, l’envoi de ceux-ci par des messageries simples ou les opérations de "copier-coller" requises par certaines applications, les octets ainsi obtenus sont codés en base-64.
Lorsqu’une application va utiliser un certificat, elle appliquera évidemment le processus inverse auparavant.

 
 
 
 
 
 
Partager sur Twitter  |  Partager sur LinkedIn