Vous êtes ici: accueil » documentation » pkix » certficat
Ce document est une description du standard X.509v3
Il existe deux grandes familles de certificats : les certificats d'extrémités (terminal) et les certificats d'autorité de certification. Les certificats d'entité d'extrémité sont délivrés par une autorité de certification, à l'inverse les certificats d'extrémités ne peuvent délivrer de certificat à une autre entité d'extrémité. Les certificats d'AC sont délivrés soit, par une autorité de certification soit ils sont auto-signés (ou auto-délivrés). Cette nouvelle AC peut alors délivrer des certificats d'entité d'extrémité. Un certificat d'AC se distingue par la présence d'une extension nommée Basic Constraints avec la valeur “vrai”. Ce champ indique explicitement que le certificat est un certificat d'AC. L'extension Basic Constraints sera expliquée un peu plus loin dans ce document.
Plusieurs types de certificats d'AC peuvent être identifiés :
L'autorité de certification crée un certificat en signant un certain nombre d'information contenu dans la requête de certificat. Ces informations incluent la clé publique et le nom qui distingue l'entité. Il peut en outre comporter un identifiant unique optionnel qui contient des informations supplémentaires à propos de l'entité. Le standard X.509 défini le format d'un certificat numérique et son contenue. Ce standard est définit par l'ITU et le groupe de travail PKIX de l'IETF. Le format est représenté à la suite sous sa forme ASN.1.
Les certificats et les listes de révocation de certificats (LCR) sont codés en ASN.1 . L’ASN.1 est une notation formelle qui permet de spécifier les données transmises par les protocoles de télécommunications indépendamment des langages informatiques et de la représentation physique de ces données.
Chaque objet ASN.1 est représenté par une structure TLV (Tag, Longueur, Valeur). Le champ « Valeur » peut lui aussi être une structure TLV. Un fichier ASN.1 est donc une suite de structures TLV.
Le champ « Tag » définit des types prédéfinis ou des types composés. Par exemple le Tag 02 (en hexadécimal) correspond au type INTEGER (nombre entier). ⇔ La « Longueur » précise le nombre d’octets contenu dans le champ « Valeur » qui contient soit un type prédéfini (INTEGER par exemple) soit un type composé TLV.
Le champ « Longueur » peut être codé de plusieurs façon :
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
Le format X.509 sous sa forme ASN.1 n'est pas facilement visible pour ceux qui ne maîtrisent pas cette grammaire. Une forme symbolique est représentée à la suite. Le format général d'un certificat X.509 est affiché dans la figure 1 sous une forme graphique. En revanche, la forme ASN.1 reste la plus précise et la plus adaptée pour représenter le contenu d'un certificat. Les champs et extensions qui définissent les certificats sont les suivants :
Un certificat numérique est representé par une séquence Certificate, qui contient trois élements :
Le premier champ dans la séquence Certificate est le tbsCertificate (To be Signed Certificate). Ce champ est lui-même une séquence contenant le nom de l'émetteur et du sujet, la clé publique associée au sujet, la période de validité, et d'autres informations que nous verrons en détail dans la suite de ce document.
Le champ algorithme de signature indique l'algorithme qui a été utilisé pour signer la LCR (la séquence certficatList).
Le champ signatureValue contient la signature de l’AC qui a émis le certificat. La signature est vérifiée en utilisant le certificat du certificat de l’AC qui l’a émis.
La séquence tbsCertificate sous sa forme ASN.1 :
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
extensions [3] EXPLICIT Extensions OPTIONAL
}
La séquence tbsCertificate est constituée des éléments suivants :
Le champ version contient un nombre entier servant à indiquer la version du certificat :
Remarque : La dernière version de la norme X.509 est la version 4. En revanche, la plus utilisée est la version 3.
Le champ serialNumber (numéro de série) contient un nombre entier servant à désigner le numéro de série du certificat. Ce numéro est unique pour une AC donnée.
Le champ signature identifie l'algorithme utilisé pour signer le certificat. Ce champ est redondant au champ signatureAlgorithmdans présent dans la séquence certificate. Il doit contenir la même valeur que ce champ.
Figure 1
Identifie sous la forme d'un DN (distinguished name - de type X.501) l'entité qui a signé et délivré le certificat . Exemple : CN=Autorité Racine, o=theWSG, c=FR
La période de validité de certificat est l'intervalle de temps pendant lequel l'AC assure qu'il maintiendra une information sur le statut du certificat. Ce champ est une séquence représentée par deux dates : la date d'émission du certificat et la date à laquelle prend fin la période de validité du certificat.
La séquence ASN.1 de la période de validité :
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
Identifie sous la forme d'un DN (distinguished name - de type X.501) le nom de l'entité associé à la clé publique stockée dans le champ subjectPublicKeyInfo du certificat. Exemple : CN=Yannick, o=theWSG, c=FR
La séquence ASN.1 du subjectPublicKeyInfo :
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Ce champ est utilisé pour positionner la clef publique et identifier l'algorithme avec lequel la clef est utilisée (par exemple, RSA, DSA, ou Diffie-Hellman). L'algorithme est identifié utilisant la structure d'AlgorithmIdentifier.
Ils peuvent être dans le certificat pour permettre la réutilisation du nom du sujet et ou d'un nom d'émetteur dans le futur. Ce profil recommande que les noms pas soient réutilisés pour des entités différentes et que les certificats diffusés sur Internet ne se servent par d'identificateurs uniques.
Extensions ; Type, critique, Valeur (optionnel)
Les extensions sont soit standardisées, soit à la discrétion de l’autorité de certification. Ces extensions doivent posséder les trois champs suivants :
Les extensions sont très importantes dans les certificats, puisqu’elles les rendent flexibles et paramétrables. De sorte qu’un certificat ne peut servir qu’à une application particulière ou tout au contraire répondre à de multiples besoins. Mais elle est aussi source d’incompatibilité. Une application va rejeter un certificat si elle n’y trouve pas l’extension qu’elle attend. Par paramétrable, on entend la possibilité pour une IGC de déporter des composants de sécurité de l’IGC dans le certificat. Dans cette optique, la politique peut spécifier que tel certificat ne pourra être utilisé qu’à cet usage, ou définir des contraintes qui rendront incompatibles des certificats émit par d’autres AC.
On peut grouper les extensions en 4 types :
Le groupe d’extensions qui renseigne sur l’utilisation qui doit être faite de la clé publique et du certificat, est constitué des champs suivants :
ce champ spécifie de manière unique la paire de clés qui a été utilisée par l’AC pour signer le certificat. Il est utilisé pour faciliter le processus de vérification de la signature du certificat. Par exemple, dans le cas où l’AC aurait utilisée plusieurs clés depuis sa mise en oeuvre. Ce champ n'est pas critique. Il peut contenir un identificateur de clé implicite ou un identificateur de certificat explicite. Ce champ est utile pour le calcul des chemins de certification. L’identification est basée soit sur le champ KeyIdentifier (correspondant au champ Subject Key Identifier du certificat qui a émis le certificat) soit sur le nom de l’émetteur et de son numéro de série.
La séquence ASN.1 du champ authorityKeyIdentifier :
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
La valeur du champ keyIdentifier est dérivée de la clef publique qui est utilisée pour vérifier la signature du certificat. Elle correspond au champ Subject Key Identifier du certificat qui a émis ce certificat.
Ce champ identifie de manière unique la clé publique qui est contenue dans le 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. 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. Un certificat d'AC doit contenir ce champ pour faciliter le calcul du chemin de certification.
Ce champ renseigne sur l'utilisation qui doit être faite de la clé. Si ce champ est à critique, 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 l'IGC. Si le champ n'est pas positionné à critique, alors le champ Key usage est là à titre indicatif. Le champ Key usage peut avoir les valeurs :
La description des valeurs du champ Key Usage est la suivante :
Le bit digitalSignature est inséré quand le Subject key identifier est utilisé pour les mécanismes de signature électronique autre que la signature de keyCertSign ou de cRLSign
Le bit NonRepudiation est inséré quand le Subject key identifier est utilisé pour un service qui doit être sûr de la non-répudiation de la signature numérique.
Le bit keyEncipherment est inséré quand le Subject key identifier est utilisé pour le transport de clef. Par exemple, quand une clef RSA est utilisée pour la gestion de clef, ce bit doit être positionné.
Le bit dataEncipherment est inséré quand le Subject key identifier est employé pour le chiffrage de données d'utilisateur, d'autres que des clefs cryptographiques
Le bit keyAgreement est inséré quand le Subject key identifier est employé pour valider une clef. Par exemple, quand une clef Diffie-Hellman doit être employée pour la gestion de clef, alors ce bit est alors positionné.
Le bit keyCertSign est inséré quand le Subject key identifier est employé pour vérifier une signature et signer des requêtes de certificats.
Le bit cRLSign est inséré quand le Subject key identifier est employé pour vérifier une signature et signer la liste de révocation de certificat.
Le bit encipherOnly est inséré quand le Subject key identifier est employé seulement pour le chiffrement de données utilisé par le bit keyAgreement. Le bit keyAgreement doit être utilisé en complément, sinon le encipherOnly est considéré comme indéfini.
Le bit decipherOnly est inséré quand le Subject key identifier est employé seulement pour le déchiffrement de données utilisé par le bit keyAgreement. Le bit keyAgreement doit être utilisé en complément, sinon le encipherOnly est considéré comme indéfini.
Ce champ donne la date d’expiration de la clef privée qui est associée à la clef publique continue dans le certificat. Il est généralement utilisé pour la clé privée de signature dans le cas ou sa période d’utilisation serait différente de la période de validité du certificat.
Cette extension définit l’emplacement des LCR (liste des certificats révoqués).
Ce champ indique 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 où 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).
Ce champ indique une ou plusieurs fonctionnalités pour lesquelles la clef publique certifiée peut être employée, en complément des champs fournis par Key Usage. En général, cette extension apparaîtra seulement dans des certificats clients.
Si l'extension est présente, le certificat doit seulement être employé pour un des buts indiqués. Si des buts multiples sont indiqués, l’application n'a pas besoin de reconnaître tous les buts indiqués, tant que le but destiné est présent. L’application employant des certificats peut exiger qu'un but particulier soit indiqué pour le certificat pour être acceptable pour cette application.
Ce groupe d’extension permet de spécifier l’utilisation des certificats en accord avec la politique de certification définie dans l’IGC.
ce champ est une séquence constituée de deux extensions. Une extension ca qui indique si le certificat est une AC et l'extension pathLengConstraint qui indique la la profondeur maximun du chemin de certificat. La présence du champ ca et la valeur à vrai indique que le certificat est un certificat d’AC. Le champ pathLenConstraint n'est pris en compte que si l'extension ca est égale à vrai et l'extension Keyusage possède le bit keyCertSign. Dans ce cas, Il indique le nombre maximum de certificats intermédiaires non auto-délivrés à la suite dans le chemin de certification. Une longueur de zéro indique que seulement un seul certificat peut suivre dans la chaîne. Cette longueur doit être supérieure ou égale à zéro. En l'absence de cette contrainte, aucune limite n'est imposée.
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
Ce champ spécifie la politique de certification (PC) qui a présidé à l’émission du certificat. Les politiques de certification sont représentées par des Object Identifier (OID). Ces OID sont enregistrés au niveau international, et leur utilisation sont standardisées. Si ce champs est marqué comme étant critique, l’IGC impose que le certificat soit utilisé conformément à la PC. Dans le cas contraire, l’information est indicative. Ensuite, libre à l’application cliente de respecter ou pas la criticité.
Ce champ ne concerne que les certificats croisées (le certificat émis par une AC pour certifier la clé publique d’une autre AC). Il permet d’associer la politique d’une AC qui émet le certificat à la PC 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 PC qui peut être acceptée s’applique à tous les certificats.
Ce groupe d’extension permet de mieux spécifier l’identification des utilisateurs et des certificats.
Subject Alternative name
ce champs spécifie une ou plusieurs informations sur le propriétaire du certificate, les valeurs autorisés sont :
Issuer alternative name
ce champs permet de donner un nom spécifique à une AC.
Subject Directory Attributes
Ce Champ est une extension non critique qui permet l'inclusion des attributs d'un annuaire qui sont applicables au sujet (subject) d'un certificat.
Les extensions de ce groupe permettent de limiter et de contrôler les indices de confiance envers d’autres AC, en cas de certification croisée.
Name constraints
Ce champ n’est utilisé que dans les certifications croisées, et permet aux administrateurs de restreindre mes domaines de confiance dans un domaine de certification croisée.
Policy constraints
Ce champ s’applique aux co-certificats, et permet de spécifier les politiques de certifications acceptables pour des certificats dépendants du co-certificat.
InhibitAnyPolicyConstraint
Ce champ permet l'exclusion de l'identifieur de politique anyPolicy. Ceci permet le contrôle d'une AC en utilisant n'importe quelle politique par opposition à une politique explicite. Il peut être placé à critique ou à non-critique.
Quand une clef privée est considérée comme compromise le certificat doit être révoqué et un mécanisme de status doit être, fourni pour vérifier, l'état du certificat client. Pour ce faire une liste de révocation est mise en place pour réaliser ce service. En général, l'émetteur de la liste de révocation est l'autorité de certification. L'autorité de certification publie la CRL qui fournit des informations sur les certificats qui ont été révoqués. Cependant, une AC peut déléguer cette responsabilité à une autre autorité de certification. Toutes les fois que l'émetteur de la CRL n'est pas l'AC qui a émis le certificat, la CRL est désignée sous le nom de CRL indirect.
Chaque CRL a une portée particulière. La portée d'une CRL est l'ensemble des certificats qui pourraient apparaître dans une CRL avec une politique donnée. Par exemple, la portée a pu être “tous les certificats délivrés par l'AC X”, “tous les certificats d'AC délivrés par l'AC X”, “tous les certificats délivrés par l'AC X qui ont été révoqués pour des raisons de compromission de clef et d'AC compromise”, ou ont peux aussi mettre ensemble des certificats basés sur des informations arbitraires, telle que “tous les certificats délivrés aux employés de Cartel situés à Paris”.
Une CRL complète énumère tous les certificats expirés, qui ont été révoqués pour une des raisons de révocation couvertes par la portée de la CRL. L'émetteur de la CRL peut également produire des delta CRLs. Un delta CRL énumère seulement les certificats, dont le statut de révocation a changé depuis l'établissement d'une CRL complète référencé. Une CRL complète référencée est désignée sous le nom de CRL de base. La portée d'un delta CRL doit être identique à la CRL de base à laquelle elle se référe.
Une AC n'est pas exigée pour publier les CRLs si d'autres mécanismes de révocation ou de statut de certificat sont fournis. Quand les CRLs sont publiées, les CRLs doivent être en version 2, inclure la date de la prochaine CRL dans le champ nextUpdate, inclure l'extension nombre de CRL, et inclure l'extension authority key identifier (identifiant de la clef d'autorité). Des applications qui supportent les CRLs sont exigées pour traiter la version 1 et la version 2 en version complète et qui fournissent des informations de révocation pour tous les certificats délivrés par une AC. Des applications ne sont pas exigées pour supporter le traitement des delta CRLs, des CRLs indirectes, ou les CRLs avec une portée différente des certificats délivrés par une AC.
Le standard CRL X.509 v2 permet de gérer trois cas de demande de révocation :
Une L'autorité de certification génére une liste de révocation (CRL) qui contient l'ensemble des certificats révoqués dans un espace de temps précis. Le X.509 fait une distinction entre l'heure et la date quand un certificat est révoqué par une autorité de certification et la date et l'heure quand celui-ci sera publié pour la première fois. La date de la révocation réelle est indiquée avec l'entrée du certificat dans la CRL. La date de notification de révocation est indiquée dans l'en-tête de la CRL quand elle est publiée. Le lieu de conservation des informations de révocation peut changer pour différentes autorités de certification. Le certificat lui-même peut contenir un indicateur indiquant où l'information de révocation est localisée, sous forme d'URI, d'adresse IP, d'adresse email, etc.
Afin de maintenir l'uniformité et la tracabilité, l'autorité de certification necessite :
inclure schema CRL
Les champs présentés sont repris de la norme ASN.1 du RFC3280, pour une meilleure visibilité et présentation. Le standard définit pour la révocation d'un certificat les champs suivants :
Le champ tbsCertList est une séquence contenant le nom de l'émetteur, la date de diffusion, la date de diffusion de la prochaine liste, la liste optionnelle des certificats révoqués, et des extensions facultatives. Quand il n'y a aucun certificat révoqué, la liste des certificats révoqués est absente. Quand un ou plusieurs certificats sont révoqués, chaque entrée de certificat révoqué contient une séquence avec le numéro de série du certificat, de date de révocation, et les extensions facultatives.
Le champ signatureAlgorithm contient le type d'algorithme employé par l'émetteur de la CRL pour signer la CRL. Le champ est du type AlgorithmIdentifier, qui énumère les algorithmes supportés avec ses spécifications, mais d'autres algorithmes de signature peuvent également être utilisés. Ce champ doit contenir le même type d'algorithme que celui du champ de signature de la séquence tbsCertList.
Le champ signatureValue contient une signature numérique calculée à partir de l'ASN.1 de tbsCertList et codé en DER. L'ASN.1 tbsCertList codé en DER est employé comme entrée à la fonction de signature. Cette valeur de signature est codée comme une chaîne binaire et incluse dans le champ signatureValue de la CRL. Les ACs qui sont également des émetteurs de CRL peuvent employer une seule clef privée pour signer numériquement les certificats et les CRLs, ou elle peuvent employer des clefs privées séparées pour signer numériquement les certificats et les CRLs. Quand des clefs privées séparées sont utilisées, les clefs publiques correspondantes sont placées dans des certificats séparés. Un certificat avec le bit keyCertSign activé dans l'extension key usage et un certificat avec le bit cRLSign activé dans l'extension key usage. L'utilisation des certificats séparés d'AC pour la signature de certificat et la signature des CRL peut offrir un supplément de sécurité; cependant, elle impose un travail supplémentaire auprès des applications, et elle pourrait limiter l'interopérabilité.
TBSCertList :
la liste des certificats “to be signed” ou TBSCertList, est une séquence de champs obligatoires et optionnels. Les champs obligatoires identifient l'émetteur de la CRL, l'algorithme employé pour signer la CRL, la date et l'heure d'émission, le lien indiquant où la CRL a été publié et la date et l'heure de la prochaine CRL. Les champs facultatifs incluent la liste des certificats révoqués et les extensions de la CRL. La liste des certificats révoqués est facultative. Ce choix permet d'émettre des CRL vide, dans le cas ou une AC n'aurait révoquée aucun certificat qu'elle a émise. Le standard exige des émetteurs de CRL d'utiliser les extensions CRL number et authority key identifier (AKI) dans toutes CRLs émises en version 2.
* Version
La dernière version est la v2. Ce champs n'est pas obligatoire, mais en cas d'utilisation il doit être 2. Les CRLs qui contiennent des extensions critiques doivent être marquées comme version 2.
* Signature
Identifie le type de fonction hash (condensé) et l'algorithme de signature utilisé pour signer la liste de révocation. Le champs doit contenir le même identifiant d'algorithme que le champs signatureAlgorithm dans la séquence CertificateList.
* émetteur (Issuer Name)
Le nom de l'autorité qui a émis et signé la liste de révocation.
* ThisUpdate
Indique la date et l'heure de la publication de la liste de révocation
* NextUpdate
Indique la date et l'heure d'émission de la prochaine CRL
* revokedCertificates
Quand il n'y a aucun certificat révoqué, la liste des certificats révoqués doit être absente. Autrement, les certificats révoqués sont énumérés par leurs numéros de série. Des certificats révoqués par l'AC sont uniquement identifiés par le numéro de série de certificat. La date et l'heure de la révocation sont indiquées. Des informations supplémentaires peuvent être fournies dans les extensions de la CRL.
*Extensions
Ce champ peut seulement apparaître en version 2. S'il est présent, ce champ est une séquence d'une ou plusieurs extensions de CRL. Les extensions sont abordées plus loin dans ce chapitre.
* CRL Extensions
Les extensions définies par ANSI X9, ISO/iec, et ITU-t pour X.509 v2 CRLs (X.509 ) ( X9.55) fournissent des méthodes pour associer des attributs additionnels à des CRLs. Le format de X.509 v2 CRL permet également aux communautés de définir des extensions privées pour diffuser des informations spécifiques à ces communautés. Chaque extension dans une CRL peut être indiquée en tant que critique ou non critique. La validation de la CRL doit échouer si elle rencontre une extension critique qu'elle ne sait pas traiter. Cependant, des extensions non critiques non reconnues peuvent être ignorées. Les sous-sections suivantes présentent les extensions utilisées dans les CRLs sur Internet. Les Communautés peuvent choisir d'inclure des extensions dans les CRLs qui ne sont pas définis dans ces spécifications. Cependant, une attention particulière devrait être exercée pour les extensions critiques dans les CRLs qui pourraient être employées dans un contexte général. Les autorités émettrices des LCR doivent être conforme aux standards pour permettre l’inclusion des extensions authority key identifier (AKI) et CRL number dans toutes les LCR publiées.
En supplément des champs standards définis pour la CRL et décrits au dessus. Il y a des extensions qui s'appliquent à l'ensemble de la CRL et d'autres à différentes entrées spécifiques dans la CRL. Les sections suivantes décrivent ces extensions et énumèrent pour quoi elles sont employées.
Authority key Identifier
Ce champ spécifie de façon unique la paire de clés utilisée par une autorité de certification pour signer la CRL. Il est utilisé pour faciliter le processus de vérification de la signature de la CRL dans le cas où l’autorité de certification aurait utilisé plusieurs clés depuis sa mise en oeuvre. L'identification peut être basée en identifiant la clef ou sur le nom et le numéro de série de l'émetteur. Ce champ n'est pas critique. Il permet à une autorité de certification de fonctionner en utilisant des ensembles multiples de clefs, et permet à un utilisateur de certificat d'identifier explicitement quel ensemble de clef devrait être employé pour valider la signature sur la CRL.
Issuer Alternative Name
Cette extension contient une liste de différentes formes de nom qui peuvent être utilisées pour identifier l'émetteur de la CRL. Si cette extension est marquée comme critique, le champ émetteur peut contenir un nom nul, et au moins un des noms dans la liste doit être traité par l'utilisateur de certificat. Tous les noms qui ne sont pas reconnus sont ignorés. Les formes de noms reconnues peuvent être de type rfc822 (adresse de courrier électronique), un nom de DNS, une adresse IP, et une URI. Des noms et des formats multiples peuvent être insérés dans ce champ. Toutes les fois que de telles identités sont employées, l'extension issuer alternative name doit être employée; cependant, un nom de DNS peut être représenté dans le champ d'émetteur en utilisant l'attribut de domainComponent.
CRL number
CRL number est une extension non critique qui donne un nombre d'ordre monotoniquement croissant pour une portée donnée de CRL et un émetteur de CRL. Cette extension permet à des utilisateurs de déterminer facilement quand une CRL particulière remplace une autre CRL. CRL number supporte également l'identification complémentaire de CRL complète et de delta CRLs. Les émetteurs de CRL conformément à ce profil doivent inclure cette extension dans toutes les CRLs.
Si un émetteur de CRL produit des delta CRLs en plus de CRLs complètes pour une portée donnée, la CRL complète et le delta CRL doivent partager un ordre de numérotation. Si un delta CRL et une CRL complète qui couvrent la même portée sont publiés en même temps, ils doivent avoir le même CRL number et fournir les mêmes informations de révocation. C'est-à-dire, la combinaison du delta CRL et une CRL complète acceptable doit, fournir les mêmes informations de révocation que la CRL complète simultanément publié.
Si un émetteur de CRL produit deux CRLs (deux CRLs complètes, deux delta CRLs, ou une CRL complète et un delta CRL) pour la même portée à différentes heures, les deux CRLs ne doivent pas avoir le même CRL number. C'est-à-dire, si le champ update des deux CRLs n'est pas identique, les CRL numbers doivent être différents.
Delta CRL Indicator - Indicateur de Delta CRL
L'indicateur de delta CRL est une extension critique de CRL qui identifie une CRL en tant que delta CRL. Les delta CRLs contiennent des mises à jour des informations de révocation précédemment distribuées. L'utilisation de delta CRLs peut de manière significative réduire la charge de réseau et la durée de la transformation dans certains environnements. Les delta CRLs sont généralement plus petits que les CRLs, ainsi les applications qui récupèrent le delta CRLs consomment moins de bande passante sur le réseau que les applications qui récupèrent les CRLs complète. Les applications qui stockent les informations de révocation dans un format autre qu'une structure de CRL peuvent ajouter de nouvelles informations de révocation à la base de données locale sans retraiter l'information.
L'extension indicateur de delta CRL contient une valeur simple du type BaseCRLNumber. Le CRL number identifie la CRL complète, pour une portée donnée, qui a été employée comme le point de départ dans la génération de ce delta CRL. Un émetteur de CRL doit éditer la CRL de base comme une CRL complète. Le delta CRL contient toutes les mises à jour sur le statut de révocation pour cette même portée. La combinaison d'un delta CRL plus la CRL de base équivaut à une CRL complète, pour une portée donnée, à l'heure de la publication du delta CRL.
Issuing Distribution Point
Le point de distribution est une extension critique de CRL qui identifie le point de distribution et la portée d'une CRL. Il indique si la CRL couvre la révocation pour des certificats d'entité d'extrémité seulement, des certificats d'AC seulement, des certificats d'attribut seulement, ou un groupe limité de raison de révocation. Bien que l'extension soit considérée critique il n'est pas exigé dans le RFC d'implémentation pour supporter cette extension.
Si le champ distributionPoint est présent et contient une URI, la sémantique suivante doit être respéctée: l'objet est un pointeur de CRL le plus couramment utilisé par l'émetteur de la CRL. L'URI supporte ftp, HTTP, mailto [ RFC1738 ] et LDAP [ RFC1778 ] qui est définie à cette fin. L'URI doit être un nom absolu, pas un nom relatif, et DOIT indiquer la machine.
Je vais ici une petite précision concernant le cRLDistributionPoints et Issuing Distribution Point qui n'est pas très bien compris et correctement décrit dans le RFC3280. C'est deux extensions sont liées entre elles, le cRLDistributionPoints identifie un point de CRL. Le contenu d'un cRLDistributionPoints est le suivant :
Si le point de distribution omet le reason code, la CRL inclut toutes les raisons (donc pas de précision). Si le CRLIssuer est absent c'est l'AC qui a émis le certificat qui a aussi émis la CRL.
Partant de ce constat, si on utilise l'extension cRLDistributionPoints<, on se doit utiliser l'extension Issuing Distribution Point qui identifie les informations du cRLDistributionPoints. Elle indique à l'application quel type d'information on va obtenir à ce point de distribution : l'extension indique si la CRL est limitée aux révocations pour des certificats clients seulement, pour des certificats d'AC seulement, ou établie pour un Reason code précis. L'extension indique aussi que la CRL peut contenir des entrées d'AC autres que l'autorité qui a signé et a publié la CRL.
la séquence de l'extension Issuing Distribution Point est:
issuingDistributionPoint ::= SEQUENCE {
distributionPoint [0]
onlyContainsUserCerts [1]
onlyContainsCACerts [2]
onlySomeReasons [3]
indirectCRL [4]
onlyContainsAttributeCerts [5] }
Reason code
L'extension ReasonCode est une extension non critique de CRL qui permet de connaître la raison de la révocation d'un certificat. Les émetteurs de CRL sont fortement encouragé à inclure des raisons de révocation significatives dans des entrées de CRL. Les causes de la révocation sont définies par la liste suivante :
hold instruction code
Le code d'instruction de blocage est une extension non critique d'entrée de CRL. Il fournit, une identifiant d'instruction qui indique l'action à réaliser après la rencontre d'un certificat qui a été placé avec cette extension.
Une application qui rencontre un identifiant d'instruction de type id-holdinstruction-callissuer doit appeler l'émetteur du certificat ou rejeter le certificat. Une application qui rencontre un identifiant d'instruction id-holdinstruction-reject doit rejeter le certificat.
Invalidity Date
Certificate Issuer
Cette extension d'entrée de CRL identifie l'émetteur du certificat associé avec une CRL indirecte, c.-à-d., une CRL qui dans son extension de point de distribution a l'indicateur d'indirectCRL . Si cette extension n'est pas présente dans la première entrée de la CRL indirecte, l'émetteur par défaut du certificat est l'émetteur de la CRL.
