Glasnost

Extensions version 3

Sommaire

Les extensions permettent d'associer des attributs supplémentaires aux utilisateurs (représentés par leur clé publique) et de gérer une hiérarchie des certificats. Ce méchanisme permet aussi de définir des extensions propres à une politique ou communauté de certification.

Toutes les extensions peuvent être marquées comme critique. Cela signifie que si un logiciel n'est pas capable de comprendre, d'analyser ou de gérer l'extension, alors tout le certificat est considéré comme invalide.

Il y a des logiciels qui rejètent tous certificat possèdant une quelconque section critique. Cela n'est pas standard, mais nous devons faire avec. Nous faisons le choix d'essayer d'utiliser des certificats avec extension critique.

Chaque extension est une combinaison d'identifiant (OID ou Object ID) et de structure ASN.1. Chaque OID ne doit apparaître qu'une seule fois.

Les extensions basiques supportées par toutes les AC sont les identifiants de clés, les contraintes basiques, l'utilisation (but) de la clé, et la politique de certification. Si l'AC fournis un certificat avec un champs sujet vide, alors l'extension de nom de sujet alternatif doit être supporté.

Les applications doivent quand à elle reconnaitre les extensions suivantes: utilisation de la clé, politiques de certification, nom de subject alternatif, contraintes basiques, contraintes de nommage, contraintes sur le chemin de validation (policy constraints), usage étendu de la clé, inhibation de la politique du n'importe quoi (inhibit any-policy).

authorityKeyIdentifier

Cette extension fournis un moyen d'identifier la clé publique liée à la clé privée utilisée pour la signature du certificat. Cette extension est utilisée parcequ'un émetteur peut disposer de plusieurs paires de clés ou tout simplement changer son unique paire. Cette extension doit être présente dans tout certificat afin de faciliter la construction du chemin de certification.

Cette extension ne doit pas être marquée comme critique.

subjectKeyIdentifier

Cette extension fournis un moyen d'identifier un certificat contenant une clé publique particulière. Elle doit être présente dans tout certificat d'AC (c'est à dire que dans l'extension définissant les contraintes de base, CA est à vrai). Cette valeur doit être celle inscrite dans l'extension authorityKeyIdentifier des certificats émis par le sujet de ce certificat (donc l'AC, l'AR ou autres).

Ce champs devraient être un dérivé de la clé publique suivant deux méthodes courament utilisées:

  1. Le hashage SHA-1 sur cent soixante bits de la valeur de la chaîne de bits la clé publique du sujet (sans les tags, la longueur et le nombre de bits inutilisés);
  2. Quatre bits fixés à 0100 suivi des soixantes bits les moins significatifs de la chaîne de bits (sans les tags, la longueur et le nombre de bits inutilisés).

Cette extension devrait être incluse dans tous les certificats. (permettant d'identifier rapidement un jeu de certificats attribués à une entité quelconque).

Cette extension ne doit pas être marquée comme critique.

keyUsage

Cette extension définis l'utilité (signature digitale d'information, signature de certificat, chiffrage de communication, etc…) de la clé contenu dans le certificat. Elle doit être présente dans des certificats contenant des clés publiques destinées à la validation de signatures digitales sur d'autre certificats ou LRC et son interprétation devrait être marquée comme critique.

Il s'agit d'un octet où chaque bit a un sens et mis à 0 (désactivé) ou à 1 (activé):

  1. digitalSignature:

    Ce bit est fixé lorsque la clé du sujet est utilisée avec un méchanisme de signature digitale pour assurer des services de sécurités autres que la signature de certificats (5) ou de LRC (6). Rien à voir avec des enregistrement sur le long terme (contrats, etc…) <> accès identifié.

  2. nonRepudiation:

    Le bit de non-répudiation est fixé lorsque la clé publique du sujet est utilisé pour vérifier les signatures digitales utilisées pour fournir une service de non-répudiation. Ce service empêche l'entité signante de faussement nier des actions signées autres que la signature de certificat ou de LRC. Dans le cas d'un conflit ultérieur, une troisième partie peut déterminer l'authenticité des données signées.

    Le bit de non répudiation est une preuve, techniquement, il n'y a pas de différence avec la signature digitale. La valeur légale du bit de non répudiation dépends de la qualité de la politique de certification et du contexte dans lequel les signatures sont utilisées. Ainsi, il est important que la personne signant avec une clé publique incluse dans un certificat avec un bit de non répudiation soit consciente de son actes; il est donc préférable de positionner le bit de non répudiation dans un certificat non utilisé dans des processus automatisés…

  3. keyEncipherment:

    Fixé lorsque la clé publique du sujet est utilisée pour le transport de clés. Par exemple, quand une clée RSA doit être utilisée pour la gestion, ce bit est fixé.

  4. dataEncipherment:

    Fixé lorsque la clé publique est utilisée pour le chiffrage de données utilisateurs autres que les clés de chiffrage.

  5. keyAgreement:

    The keyAgreement bit is asserted when the subject public key is used for key agreement. For example, when a Diffie-Hellman key is to be used for key management, then this bit is set.

  6. keyCertSign:

    Fixé lorsque la clé publique du sujet est utilisée pour vérifier une signature sur des certificats de clé publique. Si ce bit est fixé, alors le bit CA doit être fixé dans les contraintes de bases.

  7. cRLSign:

    Fixé lorsque la clé publique du sujet est utilisée pour vérifier une signature sur une liste de révocation de certificats (LRC, delta LRC, …). Ce bit doit être fixé dans des certificats qui sont utilisés pour vérifier des signatures de LRCs.

  8. encipherOnly:

    Ce bit n'a pas de sens en l'absence du bit keyAgreement. Quand ces deux bits sont fixés, la clé publique du sujet peut être utilisée uniquement pour chiffrer les données durant l'agréement de la clé.

  9. decipherOnly:

    Ce bit n'a pas de sens en l'absence du bit keyAgreement. Quand ces deux bits sont fixés, la clé publique du sujet peut être utilisée uniquement pour déchiffrer les données durant l'agréement de la clé.

Généralement, un certificat d'entité finale contient les bits numéro zéro, deux, trois ou le numéro un seul.

Généralement, un certificat d'AC contient les bits numéro zéro, deux, trois, ou zéro, cinq, six, ou encore un, cinq, six.

Private Key Usage Period

Période d'utilisation de la clé privé, à ne pas utiliser. (RFC 3280).

Certificate Policies

Ce champs contient une série d'un ou plusieurs termes définissant les informations politiques du certificat, consitué d'un OID et de qualificatifs optionnels. Les qualifiants, optionnels, ne sont pas sensé modifier la définition de la politique utilisée.

Les applications possèdant des prérequis politiques spécifiques devraient avoir une listes des politiques acceptées à comparer avec les OID des politiques contenus dans le certificat.

Si l'interprétation de cette extension est critique, le logiciel de validation de la chaîne de certification doit être capable de l'interpréter, ou doit rejeter le certificat (évidement…).

Il est recommander de fixer l'information sur la politique à un seul OID, avec des attributs si nécessaire. Les attributs recommandés sont le pointeur sur l'EPC et la notification utilisateur:

  1. Pointeur sur l'État de la Pratique en matière de Certification (Certification Practice Statement) publié par l'AC. Ce pointeur est un Identifiant Universel de Ressource (IUR, ou URI en anglais :)). Les besoins nécessaire à son traitement ne concerne que l'application locale. Aucune action n'est exigée par rapport à cet attribut, et ce sans se soucier du niveau critique associé à cette extension.

  2. La notification utilisateur est écrite pour s'afficher à l'utilisation du certificat. L'application devrait afficher toutes les notifications utilisateur de tous les certificats utilisés dans la chaîne de certification, à l'exception des notifications identiques déjà affichées. Afin d'éviter des duplications, ce qualificatif ne devrait être présent que dans les certificats d'entités finales, ou dans les AC émis pour d'autres organisations ou structures. La notification utilisateur a deux champs optionnels, le champs de référence et le champs de texte explicite:

    • noticeRef:

      Si ce champs est utilisé, il nomme une organisation et identifie par un nombre un texte particulier préparé par cette organisation. Il s'agit donc de référence à des documents internes, et que l'application qui réceptionne ces certificats est prête à interpréter.

    • explicitText:

      Ce champs permet d'inclure le texte, la note, l'information, directement dans le certificat. La taille maximale est de deux cents caractères.

    Si aussi bien les options noticeRef et explicitText sont inclus dans un des qualificatif, et que le l'application est capable de localiser le texte indiqué par la référence, alors ce texte devrait être affiché, ou sinon, la notification explicite par défaut.

Certaines AC se permette de fournir des notifications explicites dépassant les deux cents caractères.

Policy mappings

Cette extension permet à l'AC de définir des équivalences poliques entre l'OID d'une politique utilisée par l'émetteur de son certificat et les OID utiliser dans sa politique de certification.

Toutes les extensions définies ici devraient être utilisées dans l'extension certificate policies et ne devrait pas être utilisé pour définir une équivalence sur la politique n'importe quoi (anyPolicy).

Subject Alternative Name

L'extension de nom alternatif de sujet permet d'ajouter des informations d'identification liées au certificat. Les informations standards incluent l'adresse électronique Internet, un nom de SND (DNS), une adresse IP, et un IUR (URI). D'autres informations existent, même des informations internes ou locales aux utilisateurs du certificat. Il est possible d'avoir plusieurs fois la même information sous des formes différentes. Il est impératif d'utiliser cette extension si de telles informations doivent être liées au certificat.

Comme toutes ces informations sont liées au certificat, l'AC doit en vérifier l'exactitude. Si l'identification du sujet s'effectue par une manière alternative, alors, le champs sujet du certificat doit être vide et l'interprétation de cette extension doit être marquée comme critique.

La sémantique des champs se trouvent dans la RFC 3280, section 4.2.1.7.

Issuer Alternative Name

Comme pour l'extension précédente, mais pour l'émetteur du certificat. L'interprétation de cette extension ne devrait pas être considérée comme critique.

Subject Directory Attributes

C'est une extension optionnelle permettant d'associer des informations d'identification dans un répertoire. L'interprétation de cette extension ne doit pas être critique.

Basic constraints

L'extension des contraintes de base permet de définir si le sujet du certificat est un AC et la profondeur maximale de la chaîne de certification l'incluant.

Le booléen CA permet d'indiquer si la clé publique certifiée appartient à une AC. Dans ce cas, le bit keyCertSign ne doit pas être fixé.

La contrainte de longueur de chemin (pathLenConstraint) n'est significatif que si le booléen CA est fixé et que l'extension spécifiant les usages de la clé a fixé le bit keyCertSign. Dans ce cas, il donne le nombre maximum de certificats intermédiaire non auto-signé suivant ce certificat dans la chaîne de certification. Un certificat est considéré comme auto-signé si les noms distinctifs de l'émetteur et du sujet sont identiques et non vides. Le dernier certificat d'une chaîne ne peut donc être auto-signé, et est généralement un certificat d'entité finale. Une longueur de zéro indique que seulement un seul certificat peut suivre dans la chaîne. Cette longueur est donc supérieur ou égale à zéro. En l'absence de cette contrainte, aucune limite n'est imposée.

L'interprétation de cette extension doit être critique dans tous les certificats d'AC qui contiennent des clés publiques utilisées pour valider les signatures digitales des certificats émis. Dans le cas de certificat de clé publique utilisée pour valider non pas des signatures de certificats, mais des signatures de LRC par exemple, l'interprétation n'est pas obligatoirement critique. Dans les certificats d'entité finale, les deux types d'interprétaion sont possibles.

Les AC ne doivent pas émettre de certificats contenant la contrainte sur la longueur de la chaîne de certification uniquement lorsque le booléen CA est fixé et que le bit keyCertSign est fixé dans l'extension définissant l'utilisation de la clé.

Name Constraints

L'extension posant des contraintes sur le nom, ne peut être présente uniquement dans les certificats d'AC, indique un espace de nommage dans lequel tous les noms de sujet des certificats suivant (dans la chaîne) doivent se retrouvert. Ces restrictions s'appliquent aussi bien au nom du sujet qu'à son nom alternatif.

Les restrictions sont exprimées à l'aide de deux contraintes, les permissions (permittedSubTrees) et les exclusions (excludedSubtrees). Cette extension doit être critique.

À part la définition de la contrainte littérale (voir RFC 3280), la longueur minimale doit être zéro et la longueur maximale non spécifiée (absente).

Policy Contraints

L'extension définissant les contraintes politiques peut être utilisée dans les certificats émis pour une AC. Les contraintes s'applique sur la chaîne de validation de deux manières. Elle peut être utilisé pour interdire l'équivalence politique (inhibitPolicyMapping) ou obliger que chaque certificat dans la chaîne contienne un identifiant acceptable de sa politique (requireExplicitPolicy).

Si le champs requireExplicitPolicy est présent, sa valeur indique le nombre de certificats additionnels qui peuvent apparaitre dans la chaîne avant que l'équivalence de politique ne soit plus permise. Par exemple, une valeur de un indque que l'équivalence de politique peut être traité dans les certificats émis par le sujet du certificat, mais pas dans les certificats ultérieurs.

Si le champs requireExplicitPolicy est présent, sa valeur indique le nombre de certificats additionnels qui peuvent apparaître avant qu'une politique explicite soit nécessaire pour la chaîne en entier. Dans ce cas, il est nécessaire pour tous les certificats dans le chemin restant d'avoir un identifiant acceptable de politique dans leur extension de politiques de certification (certificat policies). Un identifiant acceptable de politique est un identifiant de politique demandé par le vérificateur de la chaîne de certification ou l'identifiant d'une politique qui a été déclarée comme équivalente à un identifiant valide (via policy mapping).

Les ACs ne doivent pas émettre de certificats contenant une extension de contrainte politique vide. C'est à dire qu'il doit y avoir au minimum le champs inhibitPolicyMapping ou requireExplicitPolicy.

Son interprétation peut être critique ou non.

Extended Key Usage

L'extension d'usage étendu de la clé indique un ou plusieurs butp pour lesquels la clé doit être utilisé. Si cette extension est présente, le certificat ne peut être utilisé que pour l'un des buts spécifiés dans cette dernière.

Il est possible de définir un but particulier anyExtendedKeyUsage qui permet de ne pas restreindre l'utilisation du certificat aux seuls buts indiqués dans l'extension, dans ce cas, l'interprétation ne devrait pas être critique.

Si le certificat contient aussi bien l'extension keyUsage et extendedKeyUsage, alors les deux extensions doivent être traitées indépendement et le certificat doit être utilisé dans un but conforme aux usages contenu dans les deux extensions. Si aucun but n'est conforme à ces deux extensions, alors le certificat ne doit être utilisé dans aucun but.

Une liste de buts avec leur conformité avec les buts de keyUsage est disponible dans la RFC 3280 § 4.2.1.13.

CRL Distribution Points

L'extension définissant le points de distribution de la LRC identifie comment elle est obtenue. C'est une série de points de distribution. Chaque point de distribution est composé de trois champs: distributionPoint qui est le nommage X.500 du point en lui-même, reasons qui sont raison de révocations invoquées par la liste de révocation disponible à ce point, et cRLIssuer qui est le nom distinctif de l'émetteur des LRC à ce point.

Chacun de ces champs est optionel, mais leurs combinaisons suit quelques règles:

Le champs distributionPoint est composé d'une série de noms généraux ou d'une seule entrée: nameRelativeToCRLIssuer. Si ce champs contient un nom général de type IUR (URI, voir RFC 1738), l'IUR doit pointer sur à la LRC pour les raisons spécifiées (reasons) qui sera émis par l'cRLIssuer associé. Si le nom général contient plusieurs valeurs, chaque valeur offre un méchanisme différent pour atteindre la même LRC. Si ce champs contient l'unique valeur nameRelativeToCRLIssuer, elle fournie un fragment de nom distinctif. Ce fragment est ajouté au nom distinctif de l'émetteur de LRC (cRLIssuer ou le nom distinctif de l'AC) afin d'obtenir le nom du point de distribution. Cette valeur ne doit pas être utilisée quand cRLIssuer contient plusieurs noms distinctifs d'émetteur de LRC.

Si le point de distribution oublie le champs reasons, alors il est utilisé pour n'importe quelle raison.

Le champs cRLIssuer identifie le signataire et l'émetteur de la LRC. Si ce champs est présent, il doit contenir au moins un nom distinctif X.500 et peut aussi contenir d'autre forme de nommage. Puisque ce champs est comparé au nom de l'émetteur de la LRC (contenu dans cette dernière), le type Name X.501 doit suivre les règles d'encodage du champs issuer du certificat.

Inhibit Any-Policy

Cette extension qui peut être utilisé dans les certifcats fournis aux AC indique que l'OID spéciale de politique n'importe quoi (anyPolicy) n'est pluss une politique explicite à partir d'un certain niveau. La valeur indique le nombre de certificats additionnel qui peuvent apparaître dans la chaîne avant que la politique n'importe quoi ne soit plus acceptée.

Freshest CRL (dit Delta CRL Distribution Point)

Cette extension identifie comment obtenir un delta de la LRC. L'interpréation de cette extension ne doit pas être critique. Cette extension est construite comme l'extension cRLDistributionPoints.

Private Internet Extensions

Voir la RFC 3280.

Authority Information Access

Permet d'obtenir des infos supplémentaire sur l'AC (via oscp ou caIssuer).

Subject Information Access

Permet d'obtenir des infos supplémentaire sur le sujet du certificat.

Online Certification Status Protocol

Le Protocole En Ligne d'État de Certification permet aux applications de déterminer l'état (de révocation) d'un certificat identifié. Ce protocole est définie en détail dans la RFC 2560.

Le PELEC peut être utilisé pour connaître l'état de révocation de certificats (comme les LRC), mais aussi pour obtenir d'autres informations. Le demandeur requert un serveur suivant le PELEC, et suspend l'acceptation du certificat jusqu'à obtention d'une réponse.

La demande est composée de la version du protocole utilisé, le service demandé et le certificat en question, et optionnellement des extensions qui pourraît éventuellement être comprises par l'interlocuteur répondant au PELEC.

La réponse devrait être signée digitalement. Si c'est le cas, la clé privée utilisée pour la signature doit être soit celle de l'AC, d'une AR authorisé à répondre pour le compte l'AC, ou encore un répondeur de confiance. La réponse en elle-même se compose du numéro de version de la syntaxe utilisée, du nom du répondant, des réponses (voir ci-après) individuelles à chaque certificats présents dans la demande, d'extensions optionnelles, l'OID de l'algorithme de signature, et enfin la signature digitale. Une réponse individuelle se compose de l'identifiant du certificat en question, de son état, de son intervalle de validité, d'extensions optionnelles. L'état d'un certificat peut être: