Document sur le projet OpenPKI - RFC2510

Yannick Quenec'hdu, yannick.quenechdu@Cartel-securite.com

7-07-2000
Traduction du RFC2510 . Protocole de gestion des normes PKIX-CMP.

1. Protocole de gestion des normes PKIX-CMP

1.1 Résumé

Ce document décrit Le protocole de gestion de certificats d'une IPKI (Internet X509 Public Key Infrastructure). Le protocole de message prend en compte tous les aspects de la création et de la gestion de certificat. Note : la notion de certificat ce refère au document relatif au certificat X509v3.

Les différentes sections de ce document sont les suivantes :

1.2 Présentation de la gestion de la PKI

La PKI doit être structurée pour être conformé aux types d'individus qui doivent la gérer. Fournir à des administrateurs des choix illimités complique non seulement le logiciel mais augmente également les chances qu'une erreur soit réalisé par un administrateur ou un développeur de logiciel. Ceci aurait comme conséquence d'augmenter les risques de compromission. De même, des administrateurs limités par des mécanismes compliqués, n'utiliseront pas la PKI.

Les protocoles de gestion sont nécessaires pour supporter les interactions en ligne entre les composants de la PKI. Pour exemple, Un protocole de gestion pourrait être utilisé entre une autorité de certification (CA) et un système client auquelle une clé paire est associée.

Modèle de gestion de PKI

Avant d'indiquer des formats particuliers de message et des procédures nous définissons d'abord les entités impliquées dans la gestion de PKI et leurs interactions (en termes de gestion de PKI et des fonctions requises). Nous groupons alors ces fonctions dans l'ordre afin de faciliter l'identification des différents types et les entités d'extrémités.

Définition des entités de la PKI

Les entités impliquées dans la gestion de PKI incluent l'entité d'extrémité (c.-à-d., l'entité nommée dans le champs sujet d'un certificat) et l'autorité de certification (c.-à-d., l'entité nommée dans le champs emetteur d'un certificat). Une autorité d'enregistrement PEUT également être impliquée dans la gestion de PKI.

Sujet et entité d'extremité

Le terme "sujet" est employé ici pour se réferer à l'entité nommée dans le champs sujet d'un certificat; quand nous souhaitons distinguer les outils et/ou logiciels employés par le sujet (par exemple, un module local de gestion de certificat) nous utiliserons le terme "equipement de sujet". En général, le terme " entité d'extrémité " (EE) plutôt que le sujet est préféré afin d'éviter la confusion avec le champs nom.

Il est important de noter que les entités d'extrémité ici incluront non seulement les utilisateurs des applications, mais également les applications elles-mêmes (par exemple, pour la sécurité IP). Ce facteur influence les protocoles qui sont utilisés pour la gestion de la PKI; par exemple, le logiciel d'application pourrai ainsi savoir exactement quelles sont les extensions exigées pour un utilisateur. Les entités de gestion de PKI sont également des entités d'extrémité dans le sens qu'elles sont parfois nommées dans le champs sujet du certificat. Le cas échéant, le terme "entité d'extermité " sera employé pour se rapporter aux entités d'extrémité qui ne sont pas des entités de gestion de PKI.

Toutes les entités d'extrémité exigent un accès local sécurisé a certaines informations -- au minimum, à son nom et à sa clé privée, le nom de la CA auquel l'entité fait confiance et la clé publique de la CA (ou une empreinte digitale de la clé publique auto-certifiée est disponible ailleurs). Les implémentations PEUVENT utiliser une sauvegarde locale sécurisé pour plus que ce minimum (par exemple, le certificat de l'entité d'extremité ou des informations spécifiques à l'application). La forme de la sauvegarde peut aussi varier -- à partir des fichiers à la jeton cryptographique résistante. Une telle sauvegarde locale de confiance est désignée ici pour une entité d'extrémité sous le nom Environnement Personnel de Sécurité (PSE)

Quoique le format PSE n'est pas étudié dans ce document (ils sont très dépendants des équipements), un format d'echange générique pour PSE est définit ici -- un message de réponse de certification PEUT être utilisé.

Autorité de certification

L'autorité de certification (CA) peut ou ne peut

1.3 Aperçu

La norme IETF PKIX RFC 2510 (protocoles de gestion de certificat):

Cette section donne un aperçu de l'utilisation des normes PKIX-CMP pour assurer le processus de gestion de l'ICP, les normes PKIX-CMP définissent le message et la syntaxe de message nécessaires pour effectuer les différentes opérations de gestion de l'ICP, y compris ce qui suit :

  1. Initialisation (initReq, initRep)
  2. Demande de certificat (certReq, certRep)
  3. Cocertification (crossCertReq, crossCertRep)
  4. Mise à jour de clé (keyUpdReq, keyUpdRep)
  5. Révocation (revReq, revRep)
  6. Récupération de clé (keyRecReq , keyRecRep)
  7. Message de confirmation de la norme PKIX (pKIConfirm)
  8. Message général de la norme PKIX (genM, genP)

Format et protocole de production de message

Tous les messages utilisés aux fins de gestion de l'ICP dans la présente spécification utilisent la structure suivante :

PKIMessage ::= SEQUENCE {
         header   PKIHeader,
         body PKIBody,
         protection [0] PKIProtection OPTIONAL,
         extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL }

L'élément PKIHeader contient l'information propre à plusieurs messages de l'ICP. Il contient certains renseignements d'en-tête aux fins d'adressage et d'identification de la transaction.

L'élément PKIBody contient de l'information propre au message (p. ex., CertReqMessages, CertRepMessage).

L'élément PKIProtection, lorsqu'il est utilisé, contient les bits de protection du message de l'ICP. Selon les situations, les bits de cet élément peuvent contenir un code MAC ou une signature numérique. La protection appliquée à des messages particuliers de la norme PKIX est décrite à la section "Authentification de l'origine du message"

Le champ extraCerts peut contenir des certificats éventuellement utiles pour le destinataire. Par exemple, ces certificats peuvent être utilisés par une AC ou une AE pour transmettre à une entité finale des certificats dont elle a besoin pour vérifier son propre nouveau certificat (si, par exemple, l'AC qui a émis le certificat de l'entité finale n'est pas une AC racine de l'EC).

La figure illustre le mode de fonctionnement du protocole général de la norme PKIX.

        
        Client                                       Autorité de certification
                                              
(1)demande de format  |    (2) demande (Req)      |
                      |-------------------------->| (3)Traitement de la demande
                      |    (5) Reponse (rep)      | 
(6)Traitement de la   |<--------------------------| (4)Format de la réponse
    réponse           |                           |
                      |                           |
(7)Confirmation du    |(8)Confiration (PKIconfirm)|
   format             |-------------------------->|
                      |                           |

                   Figure 3. Protocole de la norme PKIX

Toutes les fonctions (transactions) de gestion de l'ICP qui sont prises en charge sont enclenchées par le client et elles incluent toutes une demande (du client à l'AC), suivie d'une réponse (de l'AC au client), suivie elle-même d'une confirmation (du client à l'AC). La dernière demande sert d'accusé de réception final à l'AC (pKIConfirm). Toutes les fonctions de gestion de l'ICP, dont le résultat est la production d'un certificat par l'AC, requièrent du client qu'il envoie un message de confirmation lorsqu'il accepte le certificat nouvellement émis. Si un client choisit de rejeter une réponse de certificat de l'AC, il peut :

Toutes les demandes de certificats, qu'il s'agisse ou non de la première initialisation, exigent que l'AC établisse une preuve de possession à la fois pour les clés de signature et les clés de chiffrement.

Dans le cas des clés de signature, le client signe une valeur pour prouver la possession de la clé privée. Cette valeur est contenue dans la demande de certificat. Dans le cas des clés de chiffrement, le client peut transmettre la clé privée à l'AC ou être tenu de déchiffrer une valeur afin de prouver la possession de la clé privée. L'AC prend en charge la méthode indirecte selon laquelle l'AC doit émettre un certificat chiffré pour le client et demander à ce dernier de démontrer sa capacité de le déchiffrer dans un message de confirmation.

En-tête de l'ICP

Tous les messages de l'ICP requièrent certains renseignements d'en-tête aux fins d'adressage et d'identification de la transaction. Certains de ces renseignements figurent également dans une enveloppe propre au moyen de transport utilisé. Toutefois, si le message de l'ICP est protégé, l'information l'est également. On utilise la structure de données ci-dessous pour conserver ces renseignements :


PKIHeader ::= SEQUENCE {
      pvno  INTEGER { ietf-versi on2 (1) },
      -- actuellement 1
      sender GeneralName,
      -- identifie l'émetteur
      recipient GeneralName,
      -- identifie le destinataire prévu
      messageTime [0] GeneralizedTime OPTIONAL,
      -- heure de production du message
      protectionAlg [1] AlgorithmIdentifier OPTIONAL,
      -- algorithme utilisé pour le calcul des bits de protection
      senderKID [2] KeyIdentifier OPTIONAL,
      -- pour identifier les clés particulières utilisées aux fins de protection
      -- (numéro de référence)
      recipKID [3] KeyIdentifier OPTIONAL,
      -- pour identifier les clés particulières utilisées aux fins de protection
      -- (numéro de référence)
      transactionID [4] OCTET STRING OPTIONAL,
      -- identifie la transaction (cette information est la même dans la
      -- demande, la réponse et les messages de confirmation correspondants)
      senderNonce [5] OCTET STRING OPTIONAL,
      -- inséré par le créateur du message pour assurer la protection contre la répétition
      recipNonce [6] OCTET STRING OPTIONAL,
      -- valeur nonce insérée précédemment dans un message connexe par le
      -- destinataire prévu du message pour assurer la protection contre la répétition
      freeText [7] PKIFreeText OPTIONAL,
      -- champ destiné au personnel
      generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
      -- ce champ peut être utilisé pour transmettre de l'information liée au contexte }

PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
      -- texte codé (chaîne UTF-8)

AlgorithmIdentifier ::= SEQUENCE {
      Algorithm OBJECT IDENTIFIER, 
      Parameters ANY DEFINED BY algorithm OPTIONAL }

Les champs de la structure de données PKIHeader sont décrits ci-dessous :

PKI Body

Le bloc PKIBody contient des renseignements propres au message et varie selon l'opération de gestion d'ICP concernée.


PKIBody ::= CHOICE {

      ir     [0] CertReqMessages,      --Demande d'initialisation
      ip     [1] CertRepMessage,       --Réponse d'initialisation
      cr     [2] CertReqMessages,      --Demande de certification
      cp     [3] CertRepMessage,       --Réponse de certification
      p10cr  [4] CertificationRequest, --Dem. de cert. PKCS #10
      kur    [7] CertReqMessages,      --Demande de mise à jour de clé
      kup    [8] CertRepMessage,       --Réponse de mise à jour de clé
      krr    [9] CertReqMessages,      --Dem. de récupération de clé
      krp    [10] KeyRecRepContent,    --Rép. de récupération de clé
      rr     [11] RevReqContent,       --Demande de révocation
      rp     [12] RevRepContent,       --Réponse de révocation
      ccr    [13] CertReqMessages,     --Demande de cocertification
      ccp    [14] CertRepMessage,      --Réponse de cocertification
      conf   [19] PKIConfirmContent,   --Confirmation
      genm   [21] GenMsgContent,       --Message général
      genp   [22] GenRepContent,       --Réponse générale
      error  [23] ErrorMsgContent      --Message d'erreur }

Protection de message de l'ICP

L'intégrité de certains messages de l'ICP doit être protégée. Si on utilise un algorithme asymétrique pour protéger un message et que la composante publique concernée a déjà été certifiée, alors l'origine du message peut également être authentifiée. D'autre part, si la composante publique n'est pas certifiée, l'origine du message ne peut être automatiquement authentifiée, mais elle peut l'être en utilisant des mécanismes hors bande. On utilise la structure ci-dessous pour l'application des mesures de protection :

PKIProtection ::= BIT STRING

Les données d'entrées utilisées pour le calcul de l'élément PKIProtection sont le codage DER de la structure de données suivante :

ProtectedPart ::= SEQUENCE {
         header    PKIHeader, 
         body      PKIBody }

Selon les situations, les bits de l'élément PKIProtection peuvent contenir un code d'authentification de message (code MAC) ou une signature.

Protection fondée sur le code MAC

Lorsque l'émetteur et le destinataire partagent de l'information secrète (établie par des mécanismes hors bande ou à partir d'une opération de gestion de l'ICP antérieure), l'élément PKIProtection contient une valeur de code MAC et l'élément protectionAlg (MSG_MAC_ALG), l'information suivante :


PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}

PBMParameter ::= SEQUENCE {
         salt           OCTET STRING,
         owf            AlgorithmIdentifier,
         -- AlgId pour une fonction à une voie (SHA-1 recommandé)
         iterationCount INTEGER,
         -- nombre de fois que l'élément OWF est appliqué
         mac            AlgorithmIdentifier
         -- AlgId de code MAC (c.-à-d., CAST5-MAC) }

AlgorithmIdentifier ::= SEQUENCE {
         Algorithm      OBJECT IDENTIFIER, 
         Parameters     ANY DEFINED BY algorithm OPTIONAL }

Protection fondée sur la signature

Lorsque l'émetteur possède une biclé de signature, il peut simplement s'en servir pour signer le message de l'ICP. L'élément PKIProtection contient la valeur de signature et l'élément protectionAlg (MSG_SIG_ALG), l'identificateur d'algorithme AlgorithmIdentifier de signature numérique (p. ex., md5WithRSAEncryption ou dsaWithSha-1).

Authentification de l'origine du message

Tous les messages envoyés par les clients doivent contenir de l'information d'authentification d'origine. Les méthodes d'authentification sont déterminées par l'opération concernée. Deux possibilités sont prises en charge :

Code MAC fondé sur un mot de passe

Dans ce cas, tous les messages dont on effectue la gestion sont authentifiés en utilisant le schéma authentifié de base. L'authentification de l'origine du message est effectuée par l'AC, qui émet au client un numéro de référence (utilisé aux fins d'identification) et une valeur secrète ou code d'authentification (utilisé pour produire une clé secrète partagée); cette information permet d'obtenir l'authentification de l'origine du message lorsqu'on l'utilise pour protéger les messages concernés. Cette information est obtenue hors bande. L'AC et le client protègent les messages de la même manière, ce qui permet à l'AC d'authentifier l'ICP auprès du client. Les opérations ci-dessous utilisent ce schéma d'authentification de message :

Signature numérique

Dans les cas où un client existant possède déjà une biclé de signature valable (d'où l'existence implicite d'une authentification de l'origine des messages), il est possible d'authentifier les messages en utilisant une signature numérique. On utilise cette approche avec les messages suivants :

Preuve de possession

Toutes les demandes de certificats (qu'il s'agisse de la première initialisation, d'une mise à jour, etc.) exigent que l'AC établisse une preuve de possession à la fois pour les clés de signature et les clés de chiffrement. Dans le cas des clés de signature, le client signe une valeur pour prouver la possession de la clé privée. Cette valeur est contenue dans la demande de certificat. Dans le cas des clés de chiffrement, le client peut transmettre la clé privée à l'AC ou être tenu de déchiffrer une valeur afin de prouver la possession de la clé privée. L'AC prend en charge la méthode indirecte selon laquelle l'AC doit émettre un certificat chiffré pour le client et demander à ce dernier de démontrer sa capacité de le déchiffrer dans un message de confirmation.

Protection des clés privées

Dans certaines situations, l'information de clé privée est transmise entre le client et l'AC. Par exemple, cela se produit lorsqu'une AC crée une biclé de chiffrement et renvoie la clé privée au client. De manière générale, le destinataire final (client ou AC) qui doit envoyer l'information de clé privée doit obtenir une clé de chiffrement de protocole de l'autre point d'extrémité. Cette clé sert à protéger une clé symétrique qui, à son tour, est utilisée pour protéger la composante de la clé privée concernée.

Algorithmes

Algorithmes de signature numérique

Les normes PKIX-CMP offrent au client les choix d'algorithme de signature suivants:

RSA-512, RSA-1024 (implicite), RSA-2048, DSA-1024, et ECDSA-192.

Les normes PKIX-CMP offrent à l'AC les choix d'algorithme de signature suivants :

RSA-1024 (implicite), RSA-2048, et DSA-1024. Aux fins de l'interopérabilité avec les normes PKIX-CMP, la prise en charge de l'algorithme DSA/SHA-1 est obligatoire. Ceci concerne le champ MSG_SIG_ALG. L'algorithme RSA/MD5 peut être utilisé au lieu de l'algorithme obligatoire indiqué dans l'élément AlgorithmIdentifier.

Algorithmes de code MAC (Message Authentication Code)

Les normes PKIX-CMP offrent au client les choix d'algorithme de signature suivants:

triple-DES, CAST5-128 (implicite), et HMAC-SHA-1.

Les normes PKIX-CMP offrent à l'AC un seul choix d'algorithme, soit HMAC-SHA-1.

Aux fins de l'interopérabilité avec les normes PKIX-CMP, la prise en charge de code MAC fondé sur un mot de passe (PasswordBasedMAC) est obligatoire. Ceci concerne le champ MSG_MAC_ALG. L'algorithme HMAC peut être utilisé à la place de l'algorithme obligatoire précisé dans l'élément AlgorithmIdentifier.

Algorithmes de chiffrement

Le client a le choix de clés de chiffrement éphémère suivant : RSA 1024 (implicite) et RSA 2048. Cette clé est chiffrée avec une clé symétrique. Le client a le choix d'algorithmes de chiffrement asymétrique suivant : CAST5-128 (implicite) et triple-DES.

L'AC a le choix d'algorithmes de chiffrement éphémère suivant : RSA 1024 (implicite) et RSA 2048. Cette clé est chiffrée avec une clé symétrique. L'AC a le choix d'algorithmes de chiffrement symétrique suivant : CAST5-128 (implicite) et triple-DES.

Aux fins de l'interopérabilité avec les normes PKIX-CMP, la prise en charge par le client et l'AC de l'algorithme triple-DES est obligatoire. Ceci concerne le champ PROT_SYM_ALG. Les algorithmes RC5, CAST5-128 et autres peuvent être utilisés au lieu de l'algorithme obligatoire indiqué dans l'élément AlgorithmIdentifier.

Identificateurs et spécifications obligatoires d'algorithme

DSA/SHA-1

PasswordBasedMAC

Triple-DES

1.4 Message général

Avant l'exécution de toute autre fonction de gestion de l'ICP, il se peut qu'il y ait échange d'un message général. Dans certains cas, il se peut que le client doive obtenir de l'information de l'AC avant d'accomplir des fonctions de gestion de l'ICP. Par exemple, si un client demande un certificat de chiffrement pour une biclé produite par le client, avec sauvegarde, il doit obtenir un certificat de chiffrement de protocole de l'AC afin de protéger la partie privée de la biclé. À cette fin, on utilise un échange de message général.

Actuellement, un client peut demander un certificat de politique (voir les sections Demande de certificat de politique et et Réponse de certificat de politique) ou un certificat de chiffrement de protocole de l'AC (voir les sections Demande de certificat de chiffrement de protocole AC et Réponse de certificat de chiffrement de protocole AC) en utilisant un message général PKIX (genM). Le client envoie un message général à l'AC pour demander des détails qui seront nécessaires pour les opérations ultérieures de gestion de l'ICP (c.-à-d., un certificat de chiffrement de protocole ou un certificat de politique). L'AC doit répondre en utilisant le message genP. Le client n'est pas tenu d'envoyer un message pKIConfirm.

L'échange de message général comprend deux messages :

Demande de message général

Demande de certificat de politique


genM:: client ------------------->> CA

{
       pvno                         1
       sender                       Nom de l'utilisateur
       recipient                    Nom de l'AC
       messageTime                  Heure actuelle
       protectionAlg                MSG_SIG_ALG ou MSG_MAC_ALG 
       senderKID                    Obligatoire aux fins de vérification de la protection du message
       transactionID                Propre à l'implémentation (significatif pour le client)
       senderNonce                  Nombre pseudoaléatoire à 128 bits
       freeText                     N'importe quel texte
       body                         GenMsgContent
       protection                   bits calculés en utilisant l'algorithme MSG_SIG_ALG ou MSG_MAC_ALG } signature (signée avec la clé de signature du client) ou MAC (clé fondée sur un code d'autorisation et utilisée pour créer 
le code MAC pour la structure)

GenMsgContent ::= SEQUENCE OF InfoTypeAndValue

InfoTypeAndValue ::= SEQUENCE {
       infoType      OBJECT IDENTIFIER,
       infoValue     ANY DEFINED BY infoType OPTIONAL }
       
InfoType ::= private-clientInfo
InfoValue ::= Policy Certificate

Demande de certificat de chiffrement de protocole AC


genM:: client ------------------->> CA
{
       pvno                         1
       sender                       Nom de l'utilisateur
       recipient                    Nom de l'AC
       messageTime                  Heure actuelle
       protectionAlg                MSG_SIG_ALG ou MSG_MAC_ALG
       senderKID                    Obligatoire aux fins de vérification de la protection du message
       transactionID                Propre à l'implémentation (significatif pour le client)
       senderNonce                  Nombre pseudoaléatoire à 128 bits
       freeText                     N'importe quel texte
       body                         GenMsgContent
       protection                   bits calculés en utilisant l'algorithme MSG_SIG_ALG ou MSG_MAC_ALG } signature (signée avec la clé de signature du client) ou MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC pour la structure)
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue

InfoTypeAndValue ::= SEQUENCE {
       infoType      OBJECT IDENTIFIER,
       infoValue     ANY DEFINED BY infoType OPTIONAL }
InfoType ::= CAProtEncCert {id-it 1}
InfoValue ::= Certificate

Réponse de message général

Réponse de certificat de politique

genP:: CA ------------------->> client
{
       pvno                     1
       sender                   nom de l'AC
       recipient                Nom de l'utilisateur
       messageTime              Heure actuelle
       protectionAlg            MSG_SIG_ALG ou MSG_MAC_ALG
       recipKID                 Obligatoire aux fins de vérification de la protection du message
       transactionID            Propre à l'implémentation (significatif pour le client)
       senderNonce              Nombre aléatoire du message genM correspondant
       recipNonce               Nombre pseudoaléatoire à 128 bits
       body                     GenRepContent
       protection               bits calculés en utilisant l'algorithme MSG_SIG_ALG ou MSG_MAC_ALG } signature (signée avec la clé de signature de protocole de l'AC) ou MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC pour la structure)
GenRepContent ::= SEQUENCE OF InfoTypeAndValue

InfoTypeAndValue ::= SEQUENCE {
       infoType      OBJECT IDENTIFIER,
       infoValue     ANY DEFINED BY infoType OPTIONAL }

InfoType ::= private-clientInfo

InfoValue ::= Policy Certificate

Réponse de certificat de chiffrement de protocole AC

genP:: CA ------------------->> client
{
       pvno                     1
       sender                   nom de l'AC
       recipient                Nom de l'utilisateur
       messageTime              Heure actuelle
       protectionAlg            MSG_SIG_ALG ou MSG_MAC_ALG
       recipKID                 Obligatoire aux fins de vérification de la protection du message
       transactionID            Propre à l'implémentation (significatif pour le client)
       senderNonce              Numéro aléatoire du message genM correspondant
       recipNonce               Nombre pseudoaléatoire à 128 bits
       body                     GenRepContent
       protection               bits calculés en utilisant l'algorithme MSG_SIG_ALG ou MSG_MAC_ALG } signature (signée avec la clé de signature de protocole de l'AC) ou MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC pour la structure)

GenRepContent ::= SEQUENCE OF InfoTypeAndValue

InfoTypeAndValue ::= SEQUENCE {
       infoType      OBJECT IDENTIFIER,
       infoValue     ANY DEFINED BY infoType OPTIONAL }

InfoType ::= CAProtEncCert {id-it 1}

InfoValue ::= Certificate

1.5 Initialisation (initialisation/enregistrement/certification)

Processus par lequel un client se fait d'abord connaître de l'AC. Lorsque cette opération est réussie, il y a émission d'au moins un certificat et initialisation sécurisée du stockage protégé du client avec sa ou ses clés et son ou ses certificats ainsi qu'avec la clé publique de l'AC.

L'échange d'initialisation comprend trois messages :

Pour ce qui concerne l'initialisation initiale, il faut que le client reçoive de l'information hors bande de l'AC ou de l'AE. Cette information inclut un numéro de référence et un code d'authentification. Le client peut effectuer l'initialisation en utilisant l'une ou l'autre des façons suivantes :

Demande de vérification seulement

Le client doit toujours fournir une clé publique et prouver sa possession de la clé privée dans le message de demande.

Demande de vérification et de chiffrement

La façon d'effectuer ce type de demande varie selon le point d'origine des clés de chiffrement (client ou AC) et, lorsque la clé provient du client, selon que la composante privée est envoyée ou non aux fins d'archivage et (ou) de preuve de possession.

Les variantes peuvent être subdivisées comme suit :

Biclé de chiffrement provenant de l'AC

Biclé de chiffrement provenant du client

La présence d'une valeur de clé publique dans l'élément CertTemplate de la partie chiffrement de la demande indique que le client fournit la biclé de chiffrement.

Envoi de clé privée

Si le client envoie la partie privée de la biclé de chiffrement soit aux fins d'archivage ou de preuve de possession, il doit ensuite extraire d'abord le certificat de chiffrement de protocole de l'AC en utilisant un échange de message général (genM) (voir la section Demande de certificat de chiffrement de protocole AC). Le client utilise la clé publique dans le certificat de chiffrement de protocole pour protéger une clé symétrique qui est ensuite utilisée pour protéger l'information de clé privée envoyée dans le message.

Pas d'envoi de clé privée

Si le client n'envoie pas de composante privée de la biclé de chiffrement, le flux de messages est modifié de la façon indiquée ci-après.

Dans la réponse de certificat, le certificat de chiffrement nouvellement produit doit être chiffré par l'AC avec une nouvelle clé symétrique (clé symétrique de l'AC) et cette clé doit être chiffrée avec la clé publique qui figure dans le certificat de chiffrement nouvellement créé. Cette procédure est nécessaire pour établir la preuve de possession. À cette fin, le client démontre qu'il est en mesure de déchiffrer le certificat. La confirmation finale du client doit être protégée en utilisant une clé symétrique nouvellement produite et fondée sur les bits de la clé symétrique de l'AC reçue dans la réponse.

Authentification du message

L'authentification de l'origine du message est assurée par le client et par l'AC en utilisant un code MAC fondé sur un mot de passe.

Incidence sur le flux de messages

Le client enclenche toujours l'échange en utilisant un message de demande de certificat.

Lorsque l'opération est réussie, l'AC fournit une réponse dans laquelle sont inclus un ou plusieurs nouveaux certificats ainsi que le certificat de l'AC. Si l'AC rejette la demande, elle doit retourner un message d'erreur indiquant la raison en détail. Ce texte doit être exprimé en clair.

Le client peut accepter cette réponse de l'AC et envoyer un message de confirmation, ou il peut rejeter le ou les certificats soit en envoyant un message d'erreur donnant les détails du motif du rejet, soit en n'envoyant pas de confirmation. Remarquez qu'un rejet signifie que tous les certificats dans la réponse ont été rejetés puisque le protocole n'inclut aucun mécanisme permettant d'indiquer un rejet pour des raisons particulières.

L'AC doit révoquer le ou les certificats nouvellement créés si elle reçoit du client des renseignements autres qu'une confirmation.

Flux de messages

Demande d'initialisation

Un message de demande d'initialisation contient en guise d'élément PKIBody une structure de données CertReqMessages qui précise le ou les certificats demandés. De manière générale, les champs modèles SubjectPublicKeyInfo, KeyId et Validity sont ceux qui peuvent être fournis pour chaque certificat demandé. Le message doit être utilisé par les entités qui effectuent leur première initialisation dans l'ICP.

initReq:: client ------------------->> CA
{
          pvno                         1
          sender                       Nom de l'utilisateur
          recipient                    Nom de l'AC
          messageTime                  Heure actuelle
          protectionAlg                MSG_MAC_ALG
          senderKID                    Numéro de référence
          transactionID                Propre à l'implémentation (significatif pour le client)
          senderNonce                  Nombre pseudoaléatoire à 128 bits
          freeText                     Texte
          body                         CertReqMessages
          protection                   bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC pour la structure)

L'AC vérifie le message. S'il est valable, l'AC crée ensuite un nouveau certificat à l'intention du client. L'AC répond en envoyant un message initRep au client.


CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
          certReq       CertRequest,
          pop           ProofOfPossession OPTIONAL,
          -- le contenu est déterminé par le type de clé }

Le champ de preuve de possession sert à démontrer que l'entité qui doit être associée au certificat possède réellement la clé privée correspondante. Ce champ peut être calculé en utilisant l'ensemble du contenu du champ certReq, et sa structure et son contenu varient selon le type d'algorithme de clé publique et le mode opérationnel.

L'information directement associée au contenu du certificat doit être incluse dans l'élément de contenu certReq. Toutefois, l'inclusion par l'AE de contenu supplémentaire dans l'élément certReq peut invalider le champ pop.

CertRequest ::= SEQUENCE {
           certReqId     INTEGER, 
           -- ID pour apparier la demande et la réponse
           certTemplate  CertTemplate, 
           -- Champs sélectionnés du certificat à émettre
           controls      Controls OPTIONAL
           -- Attributs ayant une incidence sur l'émission }


CertTemplate ::= SEQUENCE {
            version       [0] Version                    OPTIONAL,
            serialNumber  [1] INTEGER                    OPTIONAL,
            signingAlg    [2] AlgorithmIdentifier        OPTIONAL,
            issuer        [3] Name                       OPTIONAL,
            validity      [4] OptionalValidity           OPTIONAL,
            subject       [5] Name                       OPTIONAL,
            publicKey     [6] SubjectPublicKeyInfo       OPTIONAL,
            issuerUID     [7] UniqueIdentifier           OPTIONAL,
            subjectUID    [8] UniqueIdentifier           OPTIONAL,
            extensions    [9] Extensions                 OPTIONAL }

Les champs additionnels reconnus par l'AC et qui peuvent être inclus dans une demande d'initialisation PKIX-CMP sont les suivants : authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, extKeyUsage, privateKeyUsagePeriod, certificatePolicies, privateVersInfo, subjectAltName, basicConstraints et cRLDistributionPoints.


AlgorithmIdentifier ::= SEQUENCE {
            Algorithm            OBJECT IDENTIFIER,
            Parameters           ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
            Algorithm            AlgorithmIdentifier,
            SubjectPublicKey     BIT STRING }

Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
            type                 OBJECT IDENTIFIER,
            value                ANY DEFINED BY type }


id-regCtrl-regToken              OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-authenticator         OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-pkiPublicationInfo    OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiArchiveOptions     OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-oldCertID             OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey       OBJECT IDENTIFIER ::= { id-regCtrl 6 }

ProofOfPossession ::= POPOSigningKey

Si la demande de certification concerne une biclé de signature (c.-à-d., une demande de certificat de vérification), la preuve de possession de clé de signature privée est démontrée par l'utilisation de la structure POPOSigningKey. D'autre part, si la demande de certification concerne une biclé de chiffrement (c.-à-d., une demande de certificat de chiffrement), la preuve de possession de la clé de déchiffrement privée est alors démontrée par l'inclusion de la clé privée (chiffrée) dans l'élément CertRequest (dans la structure de contrôle PKIArchiveOptions).


POPOSigningKey ::= SEQUENCE {
           poposkInput           [0]  POPOSigningKeyInput OPTIONAL,
           algorithmIdentifier   AlgorithmIdentifier,-

           signature             BIT STRING }

AlgorithmIdentifier ::= SEQUENCE {
           Algorithm             OBJECT IDENTIFIER,
           Parameters            ANY DEFINED BY algorithm OPTIONAL }

POPOSigningKeyInput ::= SEQUENCE {
           publicKeyMAC          PKMACValue
           publicKey             SubjectPublicKeyInfo }

SubjectPublicKeyInfo ::= SEQUENCE {
           Algorithm             AlgorithmIdentifier,
           SubjectPublicKey      BIT STRING }

AlgorithmIdentifier ::= SEQUENCE {
           Algorithm             OBJECT IDENTIFIER,
           Parameters            ANY DEFINED BY algorithm OPTIONAL }

PKMACValue ::= SEQUENCE {
           algId  AlgorithmIdentifier,
           -- la valeur d'algorithme est indiquée par l'élément PasswordBasedMac {1 2 840 113533 7 66 13}
           -- la valeur de paramètre est l'élément PBMParameter
           value BIT STRING }

PBMParameter ::= SEQUENCE {
           salt                  OCTET STRING,
           owf                   AlgorithmIdentifier,
           -- AlgId pour une fonction à une voie (SHA-1 recommandé)
           iterationCount        INTEGER,
           -- nombre de fois que l'élément OWF est appliqué
           mac                   AlgorithmIdentifier

           -- AlgId du code MAC }

Réponse d'initialisation

Un message de réponse d'initialisation contient en guise d'élément PKIBody une structure de données CertRepMessage qui inclut, pour chaque certificat demandé, un champ PKIStatusInfo, un certificat de sujet et possiblement une clé privée (normalement chiffrée avec une clé de session, elle-même chiffrée avec l'élément protocolEncKey).

initRep:: CA ------------------->> client
{
        pvno                       1
        sender                     Nom de l'AC
        recipient                  Nom de l'utilisateur
        messageTime                Heure à laquelle l'AC a produit le message
        protectionAlg              MSG_MAC_ALG
        recipKID                   Numéro de référence
        transactionID              Valeur tirée du message initReq correspondant
        senderNonce                Valeur tirée du message initReq correspondant
        recipNonce                 Nombre pseudoaléatoire à 128 bits
        freeText                   Texte
        body                       CertRepMessage
        certificate                Présent
        privateKey                 Présent
        protection                 bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)
Le message est vérifié par le client. Ce dernier envoie ensuite un message pKIConfirm à l'AC.


CertRepMessage ::= SEQUENCE {
               caPubs             [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,               
               response           SEQUENCE OF CertResponse }

CertResponse ::= SEQUENCE {
               certReqId          INTEGER,
               -- pour apparier cette réponse et la demande correspondante (la valeur -1
               -- doit être utilisée si l'élément certReqId n'est pas précisé dans la demande correspondante)
               status             PKIStatusInfo,
               certifiedKeyPair   CertifiedKeyPair       OPTIONAL,
               rspInfo            OCTET STRING OPTIONAL }

PKIStatusInfo ::= SEQUENCE {
               status             PKIStatus,
               statusString       PKIFreeText            OPTIONAL,
               failInfo           PKIFailureInfo         OPTIONAL }

CertifiedKeyPair ::= SEQUENCE {
               certOrEncCert      CertOrEncCert,
               privateKey         [0] EncryptedValue     OPTIONAL,
               publicationInfo    [1] PKIPublicationInfo OPTIONAL }

CertOrEncCert ::= CHOICE {
               certificate        [0] Certificate,
               encryptedCert      [1] EncryptedValue }

Dans le cas où des valeurs chiffrées (dans la présente spécification, ces valeurs sont restreintes et représentent soit des clés privées, soit des certificats) sont envoyées dans des messages de l'ICP, on utilise la structure de données EncryptedValue.

L'utilisation de cette structure de données requiert du créateur et du destinataire prévu qu'ils soient respectivement en mesure de chiffrer et de déchiffrer le message. De manière générale, cela signifie que l'émetteur et le destinataire possèdent, ou sont en mesure de produire, une clé de secret partagé. Si le destinataire du message PKIMessage possède déjà une clé privée, utilisée aux fins de déchiffrement, le champ encSymmKey peut alors contenir une clé de session avec la clé publique du destinataire.

Confirmation d'initialisation

Cette structure de données est utilisée comme message PKIMessage final dans les protocoles à trois voies. Le contenu du corps est le même dans tous les cas - de fait, il n'y a aucun contenu puisque l'élément PKIHeader contient toute l'information requise.


pkiConfirm:: client ------------------->> CA
{
             pvno                         1
             sender                       Nom de l'utilisateur
             recipient                    Nom de l'AC
             messageTime                  Heure actuelle
             protectionAlg                MSG_MAC_ALG
             senderKID                    Numéro de référence
             transactionID                Valeur tirée du message initReq correspondant
             senderNonce                  Valeur tirée du message initReq correspondant
             recipNonce                   Valeur tirée du message initRep correspondant
             freeText                     Texte
             protection                   bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC pour la structure)

1.6 Demande de certificat

Ce processus permet au client de demander des certificats supplémentaires. Par exemple, si on a émis seulement un certificat de vérification durant la première initialisation, le client peut retourner à l'AC pour demander un certificat de chiffrement.

Cette opération requiert que le client soit déjà initialisé avec des clés valables capables d'effectuer des opérations de signature. Ce processus est nécessaire pour l'authentification de message.

La présente section inclut un profil pour le message de demande de certificat PKIX-CMP et la réponse correspondante ainsi que pour les messages de confirmation concernant l'inscription des abonnés à l'ICP. Elle indique les champs qui doivent être présents dans le message de demande ainsi que la manière dont leur contenu est dérivé. Elle indique également la réponse qui sera retournée dans différentes situations ainsi que ce que le demandeur doit effectuer lorsqu'il reçoit ces réponses.

L'échange de demande de certificat comprend trois messages :

Authentification de message

La protection des messages est assurée par une signature numérique. Le client doit posséder au moins une clé de signature valable pour authentifier chaque message envoyé à l'AC et il doit posséder le certificat actuel de l'AC. L'AC utilise une clé de signature de protocole pour protéger les messages de demande de certificat. Le certificat de vérification de protocole doit être inclus dans toute réponse envoyée par l'AC et dans laquelle la clé de signature de protocole est utilisée aux fins d'authentification de message.

Incidence sur le flux de messages

Le flux de messages varie également de la manière décrite ci-dessous lorsque les demandes de certificat de chiffrement ont été traitées. Cette variation est encore une fois liée au lieu d'origine de la biclé de chiffrement, client ou AC, et à l'envoi ou non de la composante privée à l'AC si la bilclé provient du client.

Un client peut demander n'importe quel certificat supplémentaire en utilisant ce message. Une même demande peut permettre la mise à jour d'un maximum de deux certificats.

Pour chaque certificat à mettre à jour, le client doit fournir le numéro de série du certificat. Sinon, l'AC doit produire un message d'erreur. Toute nouvelle demande de certificat doit inclure des paramètres d'utilisation de clé qui permettent de distinguer le certificat en question des certificats valables que le client possède déjà. Sinon, l'AC doit produire un message d'erreur. Autrement dit, si le client possède déjà un certificat incluant un élément digitalSignature d'utilisation de clé, toute demande d'un autre certificat possédant un élément digitalSignature d'utilisation de clé entraînera la production d'une erreur de la part de l'AC. D'autre part, si la demande de certificat contient un élément d'utilisation de clé différent (c.-à-d., nonRepudiation), la demande doit être accordée. Une combinaison d'utilisation de clé qui inclut une signature numérique (digitalSignature) sans répudiation (nonRepudiation) est différente d'une utilisation de clé qui utilise uniquement une signature numérique (digitalSignature).

L'ajout de ce message accroît le nombre de clés qu'un client peut posséder, aspect intéressant pour la croissance future. Actuellement, jusqu'à trois biclés (utilisation de clé indiquée entre parenthèses) sont prises en charge :

Flux de messages

Demande de certificat

certReq:: client ------------------->> CA
{
          pvno                         1
          sender                       Nom de l'utilisateur
          recipient                    Nom de l'AC
          messageTime                  Heure actuelle
          protectionAlg                MSG_SIG_ALG (tout algorithme authentifié de protection)
          senderKID                    Aux fins de vérification de la protection du message
          transactionID                Propre à l'implémentation (significatif pour le client)
          senderNonce                  Nombre pseudoaléatoire à 128 bits
          freeText                     Texte
          body                         CertReqMessages
          protection                   bits calculés en utilisant l'algorithme
MSG_SIG_ALG
} Signature (signée avec la clé de signature du client)

L'AC utilise une clé de signature de protocole pour protéger les messages de demande de certificat. Le certificat de vérification de protocole doit être inclus dans toute réponse de l'AC dans laquelle on utilise la clé de signature de protocole pour l'authentification d'un message.

Un message de demande de certification contient en guise d'élément PKIBody une structure de données CertReqMessages qui précise les certificats demandés. Ce message s'adresse aux entités de l'ICP existantes qui désirent obtenir des certificats supplémentaires. Au choix, l'élément PKIBody peut être une demande de certification (CertificationRequest) (cette structure est définie en détail dans la structure CertificationRequest de la syntaxe ASN.1 mentionnée dans le document de référence no4 à la section 7). Cette structure peut être nécessaire pour des demandes de certificat concernant des biclés de signature lorsqu'on veut assurer l'interopération avec des systèmes antérieurs; toutefois, on dissuade fortement les utilisateurs de se servir de cette structure, sauf lorsque c'est absolument nécessaire.

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
           certReq      CertRequest,
           pop          ProofOfPossession OPTIONAL,
           -- le contenu est déterminé par le type de clé }

Le champ de preuve de possession sert à démontrer que l'entité qui doit être associée au certificat possède réellement la clé privée correspondante. Ce champ peut être calculé en utilisant l'ensemble du contenu du champ certReq, et sa structure et son contenu varient selon le type d'algorithme de clé publique et le mode opérationnel.

L'information directement associée au contenu du certificat doit être incluse dans l'élément de contenu certReq. Toutefois, l'inclusion par l'AE de contenu supplémentaire dans l'élément certReq peut invalider le champ pop.


CertRequest ::= SEQUENCE {
            certReqId              INTEGER, 
            -- ID pour apparier la demande et la réponse certTemplate CertTemplate,
            -- Champs sélectionnés du certificat à émettre
            controls               Controls OPTIONAL
            -- Attributs ayant une incidence sur l'émission }

CertTemplate ::= SEQUENCE {
             version               [0] Version                OPTIONAL,
             serialNumber          [1] INTEGER                OPTIONAL,
             signingAlg            [2] AlgorithmIdentifier    OPTIONAL,
             issuer                [3] Name                   OPTIONAL,
             validity              [4] OptionalValidity       OPTIONAL,
             subject               [5] Name                   OPTIONAL,
             publicKey             [6] SubjectPublicKeyInfo   OPTIONAL,
             issuerUID             [7] UniqueIdentifier       OPTIONAL,
             subjectUID            [8] UniqueIdentifier       OPTIONAL,
             extensions            [9] Extensions             OPTIONAL }

Les champs additionnels reconnus par l'AC et qui peuvent être inclus dans la demande de certificat sont les suivants : authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, extKeyUsage, privateKeyUsagePeriod, certificatePolicies, privateVersInfo,subjectAltName, basicConstraints et cRLDistributionPoints.


Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
             type                  OBJECT IDENTIFIER,
             value                 ANY DEFINED BY type }

             id-regCtrl-regToken           OBJECT IDENTIFIER ::= { id-regCtrl 1 }
             id-regCtrl-authenticator      OBJECT IDENTIFIER ::= { id-regCtrl 2 }
             id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
             id-regCtrl-pkiArchiveOptions  OBJECT IDENTIFIER ::= { id-regCtrl 4 }
             id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }

             id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }

ProofOfPossession ::= CHOICE {
             signature             [1] POPOSigningKey,
             keyEncipherment       [2] POPOPrivKey }

Si la demande de certification concerne une biclé de signature (c.-à-d., une demande de certificat de vérification), la preuve de possession de clé de signature privée est démontrée par l'utilisation de la structure POPOSigningKey. D'autre part, si la demande de certification concerne une biclé de chiffrement (c.-à-d., une demande de certificat de chiffrement), la preuve de possession de la clé de déchiffrement privée est alors démontrée par l'inclusion de la clé privée (chiffrée) dans l'élément CertRequest (dans la structure de contrôle PKIArchiveOptions).


POPOSigningKey ::= SEQUENCE {
             poposkInput          [0] POPOSigningKeyInput       OPTIONAL,
             algorithmIdentifier  AlgorithmIdentifier,
             signature            BIT STRING }

POPOSigningKeyInput ::= SEQUENCE {
             authInfo             CHOICE {
             sender               [0] GeneralName,
             -- utilisé uniquement si une identité authentifiée a été établie pour l'émetteur (p. ex., 
             -- un nom distinctif tiré d'un certificat émis antérieurement et actuellement valable) 
             publicKeyMAC         PKMACValue },
             -- utilisé s'il n'existe pas actuellement d'élément GeneralName authentifié pour
             -- l'émetteur; l'élément publicKeyMAC contient un code MAC fondé sur un mot de
             -- passe pour la valeur de l'élément publicKey codée selon les règles DER
             publicKey            SubjectPublicKeyInfo
             -- de CertTemplate }

AlgorithmIdentifier ::= SEQUENCE {
             Algorithm            OBJECT IDENTIFIER,
             Parameters           ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
             Algorithm            AlgorithmIdentifier,
             SubjectPublicKey     BIT STRING }

PKMACValue ::= SEQUENCE {
             algId                AlgorithmIdentifier,
             -- la valeur d'algorithme est indiquée par l'élément PasswordBasedMac {1 2 840113533 7 66 13}
             -- la valeur de paramètre est l'élément PBMParameter 
             value BIT STRING }

PBMParameter ::= SEQUENCE {
             salt                 OCTET STRING,
             owf                  AlgorithmIdentifier,
             -- AlgId pour une fonction à une voie (SHA-1 recommandé)
             iterationCount       INTEGER,
             -- nombre de fois que l'élément OWF est appliqué
             mac                  AlgorithmIdentifier
             -- AlgId du code MAC }

Réponse de certificat

Un message de réponse de certificat contient en guise d'élément PKIBody une structure de données CertRepMessage possédant une valeur d'état pour chaque certificat demandé et, au choix, une clé publique de l'AC, de l'information sur le rejet, un certificat de sujet ainsi qu'une clé privé chiffrée.

certRep:: CA ------------------->> client
{
          pvno                     1
          sender                   Nom de l'AC
          recipient                Nom de l'utilisateur
          messageTime              Heure actuelle
          protectionAlg            MSG_SIG_ALG
          recipKID                 Aux fins de vérification de la protection du message
          transactionID            Valeur tirée du message certReq correspondant
          senderNonce              Valeur tirée du message certReq correspondant
          recipNonce               Nombre pseudoaléatoire à 128 bits
          freeText                 Texte
          body                     CertRepMessages
          certificate              Présent
          privateKey               Présent
          protection               bits calculés en utilisant l'algorithme MSG_SIG_ALG 
          extraCerts               Certificat de vérification de protocole de l'AC
} Signature (signée avec une clé de signature de protocole AC)

Le message est vérifié par le client. Ce dernier envoie ensuite un message pKIConfirm à l'AC.


CertRepMessage ::= SEQUENCE {
            caPubs           [1] SEQUENCE SIZE (1..MAX) OF Certificate  OPTIONAL,
            response         SEQUENCE OF CertResponse }

CertResponse ::= SEQUENCE {
            certReqId        INTEGER,
            -- pour apparier cette réponse et la demande correspondante (la valeur -1
            -- doit être utilisée si l'élément certReqId n'est pas précisé dans la demande
            -- correspondante)
            status           PKIStatusInfo,
            certifiedKeyPair CertifiedKeyPair    OPTIONAL,
            rspInfo          OCTET STRING        OPTIONAL }

PKIStatusInfo ::= SEQUENCE {
            status           PKIStatus,
            statusString     PKIFreeText         OPTIONAL,
            failInfo         PKIFailureInfo      OPTIONAL }

CertifiedKeyPair ::= SEQUENCE {
            certOrEncCert    CertOrEncCert,
            privateKey       [0] EncryptedValue  OPTIONAL,
            publicationInfo  [1] PKIPublicationInfo OPTIONAL }

CertOrEncCert ::= CHOICE {
            certificate      [0] Certificate,
            encryptedCert    [1] EncryptedValue }

Il ne peut y avoir dans chaque réponse CertResponse (selon l'état) qu'un seul des champs suivants : champ failInfo (dans PKIStatusInfo) et des champs de certificat (dans CertifiedKeyPair). Pour certaines valeurs d'état (p. ex., en attente), aucun des champs facultatifs ne doit être présent.

On peut obtenir le certificat à partir d'un élément EncryptedCert et de la clé de déchiffrement connexe. Cela permet à une AC de retourner la valeur d'un certificat, mais avec la contrainte suivante : seul le destinataire prévu peut obtenir le certificat réel. L'avantage de cette approche est de permettre à une AC de répondre en utilisant un certificat même en l'absence de preuve que le demandeur est bien l'entité finale qui peut utiliser la clé privée connexe (remarquez que la preuve n'est pas obtenue tant que l'AC n'a pas reçu le message PKIConfirm). Donc, l'AC ne sera pas tenu de révoquer ce certificat advenant qu'il y ait un problème au niveau de la preuve de possession.

Confirmation de demande de certificat

Cette structure de données est utilisée comme message PKIMessage final dans les protocoles à trois voies. Le contenu du corps est le même dans tous les cas - de fait, il n'y a aucun contenu puisque l'élément PKIHeader contient toute l'information requise.

pkiConfirm:: client ------------------->> CA
{
             pvno                         1
             sender                       Nom de l'utilisateur
             recipient                    Nom de l'AC
             messageTime                  Heure actuelle
             transactionID                Valeur tirée du message certReq correspondant
             senderNonce                  Valeur tirée du message certReq correspondant
             recipNonce                   Valeur tirée du message certRep correspondant
             protectionAlg                MSG_SIG_ALG
             senderKID                    Aux fins de vérification de la protection du message
             freeText                     Texte
             protection                   bits calculés en utilisant l'algorithme MSG_SIG_ALG
} Signature (signée avec la clé de signature du client)

1.7 Mise à jour de la clé

Cette section inclut un profil pour le message de renouvellement/mise à jour PKIX-CMP et le message de réponse correspondant pour le renouvellement de certificat de l'ICP par les abonnés et les AC de sujet. Elle indique les champs qui doivent être présents dans le message de demande ainsi que la façon dont leur contenu est dérivé. Elle indique également les réponses retournées dans différentes situations ainsi que la procédure que demandeur doit effectuer lors de la réception de ces réponses.

Pour mettre à jour les deux biclés, le client doit identifier dans la demande les certificats qu'il faut mettre à jour en indiquant les numéros de série de certificat. Le client fournit toujours la clé publique et doit prouver la possession de la composante privée. Il doit également fournir le numéro de série du certificat de vérification qu'il faut mettre à jour. Le client exécute les étapes ci-dessous dans une demande de mise à jour de clé. Dans un premier temps, il produit un nombre aléatoire. Ensuite, soit que l'application de sécurité fournit le logiciel client et la biclé de signature ainsi que les modèles de certificat qu'il désire obtenir, soit que l'application de sécurité demande au logiciel client de créer

une biclé de signature. Le client envoie ensuite un message keyUpdReq à l'AC. Ce message est authentifié avec la clé privée de signature du client. L'échange de mise à jour de clé comprend trois messages :

Authentification du message

La protection du message s'effectue différemment de celle effectuée lors de l'échange de première initialisation et du client et de l'AC. Le client doit posséder au moins une clé de signature valable pour authentifier chaque message envoyé par l'AC et il doit posséder le certificat actuel de l'AC. L'AC utilise une clé de signature de protocole pour protéger les messages de demande de mise à jour. Le certificat de vérification de protocole doit être inclus dans toute réponse de l'AC dans laquelle la clé de signature de protocole est utilisée aux fins d'authentification du message.

Incidence sur le flux de messages

Le flux de messages varie de la façon indiquée lorsque les mises à jour de certificat de chiffrement sont terminées. Cette variation est encore une fois liée au lieu d'origine de la biclé de chiffrement, client ou AC, et à l'envoi ou non de la composante privée à l'AC si la biclé provient du client. Toute nouvelle demande de certificat doit inclure des paramètres d'utilisation de clé qui permettent de distinguer le certificat en question des certificats valables que le client possède déjà. Sinon, l'AC doit produire un message d'erreur. Autrement dit, si le client possède déjà un certificat incluant un élément digitalSignature d'utilisation de clé, toute demande d'un autre certificat possédant un élément digitalSignature d'utilisation de clé entraînera la production d'une erreur de la part de l'AC. D'autre part, si la demande de certificat contient un élément d'utilisation de clé différent (p. ex., nonRepudiation), la demande doit être accordée, pour autant que le message de demande réponde aux autres critères.

Mise à jour d'un seul certificat

Mise à jour d'un certificat de vérification

Comme c'est le cas lors de la première initialisation, le client fournit toujours la clé publique et doit prouver la possession d'une composante privée. Il doit également fournir le numéro de série du certificat de vérification qu'il faut mettre à jour.

Mise à jour d'un certificat de chiffrement

Dans le cas d'une première initialisation, on peut avoir besoin d'un échange de message général si le client doit envoyer la partie privée de la biclé de chiffrement. De plus, le client doit envoyer une clé de chiffrement de protocole si l'AC fournit la biclé de chiffrement. Comme toujours, on doit établir une preuve de possession et cette opération peut s'effectuer dans le message de confirmation du client.

Mise à jour de deux certificats

Dans ce cas, on demande à l'AC de mettre à jour deux certificats; de manière générale, il s'agit d'un certificat de vérification et d'un certificat de chiffrement. Le client doit identifier dans la demande les certificats qu'il faut mettre à jour en fournissant les numéros de série des certificats.

Flux de messages

Demande de mise à jour de clé

On utilise la syntaxe CertReqMessages pour les demandes de mise à jour de clé. De manière générale, les champs modèles SubjectPublicKeyInfo, KeyId et Validity sont ceux que l'on doit fournir pour la mise à jour de chaque clé. Le but de ce message est de servir de demande de mise à jour de certificats existants (non révoqués et non expirés).


keyUpdReq:: client ------------------->> CA
{
            pvno                         1
            sender                       Nom de l'utilisateur
            recipient                    Nom de l'AC
            messageTime                  Heure actuelle
            protectionAlg                MSG_SIG_ALG
            senderKID                    Aux fins de vérification de la protection du message
            transactionID                Propre à l'implémentation (significatif pour le client)
            senderNonce                  Nombre pseudoaléatoire à 128 bits
            freeText                     Texte
            body                         CertReqMessages
            protection                   bits calculés en utilisant l'algorithme MSG_SIG_ALG
} Signature (signée avec la clé de signature du client)
L'AC utilise une clé de signature de protocole pour protéger les messages de demande de mise à jour. Le certificat de vérification de protocole doit être inclus dans toute réponse de l'AC dans laquelle la clé de signature de protocole est utilisée aux fins d'authentification du message. L'AC vérifie le message. S'il est valable, l'AC crée un certificat de vérification pour le client et répond en produisant un message keyUpdRep.

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
          certReq       CertRequest,
          pop           ProofOfPossession    OPTIONAL,
          -- le contenu est lié au type de clé }

Le champ de preuve de possession sert à démontrer que l'entité qui doit être associée au certificat possède actuellement la clé privée correspondante. Ce champ peut être calculé en utilisant l'ensemble du contenu du champ certReq et sa structure et son contenu varient selon le type d'algorithme de clé publique et le mode opérationnel.

L'information directement associée au contenu du certificat doit être incluse dans l'élément de contenu certReq. Toutefois, l'inclusion de contenu supplémentaire par l'AE dans l'élément certReq peut invalider le champ pop.

CertRequest ::= SEQUENCE {
           certReqId     INTEGER, 
           -- ID pour apparier la demande et la réponse
           certTemplate  CertTemplate, 
           -- Champs sélectionnés du certificat à émettre
           controls      Controls    OPTIONAL
           -- Attributs ayant une incidence sur l'émission }

CertTemplate ::= SEQUENCE {
           version       [0] Version             OPTIONAL,
           serialNumber  [1] INTEGER             OPTIONAL,
           signingAlg    [2] AlgorithmIdentifier OPTIONAL,
           issuer        [3] Name                OPTIONAL,
           validity      [4] OptionalValidity    OPTIONAL,
           subject       [5] Name                OPTIONAL,
           publicKey     [6] SubjectPublicKeyInfo OPTIONAL,
           issuerUID     [7] UniqueIdentifier    OPTIONAL,
           subjectUID    [8] UniqueIdentifier    OPTIONAL,
           extensions    [9] Extensions          OPTIONAL }

Les champs additionnels reconnus par l'AC et qui peuvent être inclus dans une demande de mise à jour de clé PKIX-CMP sont les suivants : authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, extKeyUsage, privateKeyUsagePeriod, certificatePolicies, privateVersInfo, subjectAltName, basicConstraints et cRLDistributionPoints.


AlgorithmIdentifier ::= SEQUENCE {
          Algorithm              OBJECT IDENTIFIER,
          Parameters             ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
          Algorithm              AlgorithmIdentifier,
          SubjectPublicKey       BIT STRING }

Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
          type                   OBJECT IDENTIFIER,
          value                  ANY DEFINED BY type }

          id-regCtrl-regToken           OBJECT IDENTIFIER ::= { id-regCtrl 1 }
          id-regCtrl-authenticator      OBJECT IDENTIFIER ::= { id-regCtrl 2 }
          id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
          id-regCtrl-pkiArchiveOptions  OBJECT IDENTIFIER ::= { id-regCtrl 4 }
          id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
          id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }
          
ProofOfPossession ::= POPOSigningKey

Si la demande de certification concerne une biclé de signature (c.-à-d., une demande de certificat de vérification), l'utilisation de la structure POPOSigningKey permet d'établir la preuve de possession de la clé de signature privée. D'autre part, si la demande de certification concerne une biclé de chiffrement (c.-à-d., une demande de certificat de chiffrement), l'inclusion de la clé privée (chiffrée) dans l'élément CertRequest (dans la structure de contrôle PKIArchiveOptions) établit la preuve de possession de la clé de déchiffrement privée.

POPOSigningKey ::= SEQUENCE { algorithmIdentifier AlgorithmIdentifier, signature BIT STRING }

Réponse de mise à jour de clé

Dans le cas des réponses de mise à jour de clé, on utilise la syntaxe CertRepMessage. La réponse est identique à la réponse d'initialisation. Un message de réponse de mise à jour de clé contient en guise d'élément PKIBody une structure de données CertRepMessage qui inclut, pour chaque certificat demandé, un champ PKIStatusInfo, un certificat de sujet, et possiblement une clé privée (normalement chiffrée avec une clé de session, elle-même chiffrée avec l'élément protocolEncKey).


keyUpdRep:: CA ------------------->> client
{
            pvno                     1
            sender                   Nom de l'AC
            recipient                Nom de l'utilisateur
            messageTime              Heure actuelle
            protectionAlg            MSG_SIG_ALG
            recipKID                 Aux fins de vérification de la protection du message
            transactionID            Valeur tirée du message keyUpdReq correspondant
            senderNonce              Valeur tirée du message keyUpdReq correspondant
            recipNonce               Nombre pseudoaléatoire à 128 bits
            freeText                 Texte
            body                     CertRepMessage
            certificate              Présent
            privateKey               Présent
            protection               bits calculés en utilisant l'algorithme MSG_SIG_ALG 
            extraCerts               Présent
} Signature (signée avec une clé de signature de protocole AC)
Le message est vérifié par le client. Ensuite, ce dernier envoie un message pKIConfirm à l'AC.

CertRepMessage ::= SEQUENCE {
              caPubs       [1] SEQUENCE SIZE (1..MAX) OF Certificate  OPTIONAL,
              response     SEQUENCE OF CertResponse }

CertResponse ::= SEQUENCE {
              certReqId        INTEGER,
              -- pour apparier cette réponse et la demande correspondante (la valeur -1
              -- doit être utilisée si l'élément certReqId n'est pas précisé dans la demande
              -- correspondante)
              status           PKIStatusInfo,
              certifiedKeyPair CertifiedKeyPair OPTIONAL,
              rspInfo          OCTET STRING     OPTIONAL }

PKIStatusInfo ::= SEQUENCE {
              status           PKIStatus,
              statusString     PKIFreeText      OPTIONAL,
              failInfo         PKIFailureInfo   OPTIONAL }

CertifiedKeyPair ::= SEQUENCE {
              certOrEncCert    CertOrEncCert,
              privateKey       [0] EncryptedValue       OPTIONAL,
              publicationInfo  [1] PKIPublicationInfo   OPTIONAL }

CertOrEncCert ::= CHOICE {
              certificate      [0] Certificate,
              encryptedCert    [1] EncryptedValue }

Dans le cas où des valeurs chiffrées (dans la présente spécification, ces valeurs sont restreintes et représentent soit des clés privées, soit des certificats) sont envoyées dans des messages ICP, on utilise la structure de données EncryptedValue. L'utilisation de cette structure de données requiert du créateur et du destinataire prévu qu'ils soient respectivement en mesure de chiffrer et de déchiffrer le message. De manière générale, cela signifie que l'émetteur et le destinataire possèdent, ou sont en mesure de produire, une clé de secret partagé. Si le destinataire du message PKIMessage possède déjà une clé privée, utilisée aux fins de déchiffrement, le champ encSymmKey peut alors contenir une clé de session chiffrée avec la clé publique du destinataire.

Confirmation de mise à jour de clé

Cette structure de données est utilisée comme message PKIMessage final dans les protocoles à trois voies. Le contenu du corps est le même dans tous les cas - de fait, il n'y a aucun contenu puisque l'élément PKIHeader contient toute l'information requise.

pkiConfirm:: client ------------------->> CA
{
             pvno                         1
             sender                       Nom de l'AC
             recipient                    Nom de l'utilisateur
             messageTime                  Heure actuelle
             transactionID                Valeur tirée du message keyUpdReq correspondant
             senderNonce                  Valeur tirée du message keyUpdRep correspondant
             recipNonce                   Valeur tirée du message keyUpdRep correspondant
             protectionAlg                MSG_SIG_ALG
             senderKID                    Aux fins de vérification de la protection du message
             freeText                     Texte
             protection                   bits calculés en utilisant l'algorithme MSG_SIG_ALG
} Signature (signée avec la clé de signature du client)

1.8 Cocertification

Cette section inclut un profil pour le message de demande PKIX-CMP ainsi qu'une réponse correspondante et des messages de confirmation pour l'inscription des AC de sujet. Elle indique les champs qui doivent être présents dans le message de demande ainsi que la façon dont leur contenu est dérivé. De plus, elle indique les réponses qui seront retournées selon les différentes situations ainsi que la procédure que le demandeur doit effectuer à la réception de ces réponses. Le flux de messages est le même puisque toutes les demandes donnent lieu à la production d'un certificat. Il faut donc obtenir un message de confirmation du client.

L'échange de cocertification comprend trois messages :

Flux de messages

Demande de cocertification

Les demandes de cocertification utilisent la même syntaxe que celle utilisée dans le cas des demandes de certification normales, sauf que la biclé doit avoir été produite par l'AC qui fait la demande, et la clé privée ne doit pas être envoyée à l'AC correspondante.


certReq:: CA1 ------------------->> CA2
{
          pvno                      1
          sender                    Nom de l'AC1
          recipient                 Nom de l'AC2
          messageTime               Heure de production du message
          protectionAlg             MSG_MAC_ALG
          senderKID                 Numéro de référence
          transactionID             Propre à l'implémentation (significatif pour l'AC)
          senderNonce               Nombre pseudoaléatoire à 128 bits
          freeText                  Texte
          body                      CertReqMessage
          protection                bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)


CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
          certReq       CertRequest,
          pop           ProofOfPossession    OPTIONAL
          -- le contenu est déterminé par le type de clé }

Le champ de preuve de possession sert à démontrer que l'entité qui doit être associée au certificat possède réellement la clé privée correspondante. Ce champ peut être calculé en utilisant l'ensemble du contenu du champ certReq, et sa structure et son contenu varient selon le type d'algorithme de clé publique et le mode opérationnel. L'information directement associée au contenu du certificat doit être incluse dans l'élément de contenu certReq. Toutefois, l'inclusion par les AE de contenu supplémentaire dans l'élément certReq peut invalider le champ pop.

CertRequest ::= SEQUENCE {
            certReqId    INTEGER, 
            -- ID pour apparier la demande et la réponse
            certTemplate CertTemplate
            -- Champs sélectionnés du certificat à émettre }

CertTemplate ::= SEQUENCE {
            version      [0] Version               OPTIONAL,
            -- v1 (0) ou v3 (2)
            signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
            -- L'AC qui fait la demande doit connaître d'avance l'algorithme avec lequel
            -- elle désire signer le certificat
            issuer       [3] Name                  OPTIONAL,
            -- peut inclure une valeur null seulement si une valeur est proposée pour le
            --champ additionnel issuerAltName
            validity     [4] OptionalValidity      OPTIONAL,
            subject      [5] Name                  OPTIONAL,
            -- peut inclure une valeur null seulement si une valeur est proposée pour le
            --champ additionnel subjectAltName
            publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
            -- clé de l'AC à certifier
            extensions   [9] Extensions            OPTIONAL
            -- l'AC qui effectue la demande doit proposer des valeurs pour tous les champs
            -- additionnels dont elle requiert la présence dans le cocertificat }

Les champs additionnels reconnus par l'AC et qui peuvent être inclus dans une demande de cocertification PKIX-CMP sont les suivants : authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, extKeyUsage, privateKeyUsagePeriod, certificatePolicies, privateVersInfo, subjectAltName, basicConstraints et cRLDistributionPoints.

AlgorithmIdentifier ::= SEQUENCE {
              Algorithm          OBJECT IDENTIFIER,
              Parameters         ANY DEFINED BY algorithm OPTIONAL }


SubjectPublicKeyInfo ::= SEQUENCE {
              Algorithm          AlgorithmIdentifier,
              SubjectPublicKey   BIT STRING }


OptionalValidity ::= SEQUENCE {
              notBefore      [0]Time    OPTIONAL,
              notAfter       [1]Time    OPTIONAL
              --au moins un doit être présent }

Time ::= CHOICE {
              utcTime        UTCTime,
              generalTime    GeneralizedTime }

ProofOfPossession ::= POPOSigningKey
Étant donné que la demande de cocertification est une demande de certificat de vérification, l'utilisation de la structure POPOSigningKey établit la preuve de possession de la clé de signature AC.

POPOSigningKey ::= SEQUENCE {
              algorithmIdentifier AlgorithmIdentifier,
              signature           BIT STRING }
L'AC2 utilise sa clé de signature pour protéger les messages de demande de cocertificat. On doit inclure le certificat de vérification AC1 dans toute réponse de l'AC2 dans laquelle la clé de signature de protocole est utilisée aux fins d'authentification du message.

Réponse de cocertification

Les réponses de cocertification utilisent la même syntaxe que celle des réponses de certification normales, sauf que l'on ne peut envoyer de clé privée chiffrée.

certRep:: CA2 ------------------->> CA1
{
          pvno                      1
          sender                    Nom de l'AC2
          recipient                 Nom de l'AC1
          messageTime               Heure à laquelle l'AC a produit le message
          protectionAlg             MSG_MAC_ALG
          senderKID                 Aux fins de vérification de la protection du message
          recipKID                  Numéro de référence
          transactionID             Valeur tirée du message certReq correspondant
          senderNonce               Valeur tirée du message certReq correspondant
          recipNonce                Nombre pseudoaléatoire à 128 bits
          freeText                  Texte
          body                      CertRepMessage
          response                  Présent
          status                    Présent - indicateur d'état de l'ICP
          failInfo                  Présent, selon l'état
          certifiedKeyPair          Biclé certifiée           
          certificate               Cocertificat
          protection                bits calculés en utilisant l'algorithme MSG_MAC_ALG
          extraCerts                Certificat de vérification de l'AC
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)

CertRepMessage ::= SEQUENCE {
          caPubs       [1] SEQUENCE SIZE (1..MAX) OF Certificate     OPTIONAL,
          response     SEQUENCE OF CertResponse }

CertResponse ::= SEQUENCE {
          certReqId        INTEGER,
          -- pour apparier cette réponse et la demande correspondante (la valeur -1
          -- doit être utilisée si l'élément certReqId n'est pas précisé dans la demande
          -- correspondante)
          status           PKIStatusInfo,
          certifiedKeyPair CertifiedKeyPair OPTIONAL,
          rspInfo          OCTET STRING     OPTIONAL }

PKIStatusInfo ::= SEQUENCE {
          status           PKIStatus,
          statusString     PKIFreeText      OPTIONAL,
          failInfo         PKIFailureInfo   OPTIONAL }

CertifiedKeyPair ::= SEQUENCE {
          certOrEncCert    CertOrEncCert,
          privateKey       [0] EncryptedValue       OPTIONAL,
          publicationInfo  [1] PKIPublicationInfo   OPTIONAL }
          
CertOrEncCert ::= CHOICE {
          certificate      [0] Certificate,
          encryptedCert    [1] EncryptedValue }

Dans le cas où des valeurs chiffrées (dans la présente spécification, ces valeurs sont restreintes et représentent soit des clés privées, soit des certificats) sont envoyées dans des messages de l'ICP, on utilise la structure de données EncryptedValue.

L'utilisation de cette structure de données requiert du créateur et du destinataire prévu qu'ils soient respectivement en mesure de chiffrer et de déchiffrer le message. De manière générale, cela signifie que l'émetteur et le destinataire possèdent, ou sont en mesure de produire, une clé de secret partagé. Si le destinataire du message PKIMessage possède déjà une clé privée, utilisée aux fins de déchiffrement, le champ encSymmKey peut alors contenir une clé de session chiffrée avec la clé publique du destinataire.

L'AC1 qui fait la demande envoie ensuite un message pKIConfirm au destinataire AC2.

Confirmation de cocertification

Cette structure de données est utilisée comme message PKIMessage final dans les protocoles à trois voies. Le contenu du corps est le même dans tous les cas - de fait, il n'y a aucun contenu puisque l'élément PKIHeader contient toute l'information requise.

pkiConfirm:: CA1 ------------------->> CA2
{
             pvno                      1
             sender                    Nom de l'AC1
             recipient                 Nom de l'AC2
             transactionID             Valeur tirée du message certReq correspondant
             senderNonce               Valeur tirée du message certRep correspondant
             recipNonce                Valeur tirée du message certRep correspondant
             protectionAlg             MSG_MAC_ALG
             senderKID                 Numéro de référence
             freeText                  Texte
             protection                bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)

1.9 Récupération de clé

Cette section inclut un profil pour le message de demande PKIX-CMP ainsi que la réponse correspondante et les messages de confirmation pour la récupération de clé de l'ICP des abonnés. Elle indique les champs qui doivent être présents dans le message de demande ainsi que la façon dont leur contenu est dérivé. Elle indique également les réponses qui sont retournées dans différentes situations ainsi que la procédure que le demandeur doit effectuer lors de la réception de ces réponses.

Le client reçoit un code d'autorisation et un numéro de référence qu'il utilise ensuite pour identifier le client et l'AC et pour authentifier les messages échangés. Le logiciel envoie un message keyRecReq à l'AC. Ce message est protégé en utilisant un code MAC dérivé du code d'autorisation. Cet échange est effectué lorsqu'un client ne possède plus de biclé de signature valable ou lorsque l'information de clé du client a été perdue. Il sert à obtenir l'historique de cléde chiffrement de l'AC.

L'échange de demande de récupération de clé comprend trois messages :

Authentification du message

Le message est protégé en utilisant un code MAC fondé sur un mot de passe. Le client doit obtenir le numéro de référence et le code d'authentification par des mécanismes hors bande.

Incidence sur le flux de messages

Un client qui demande une récupération de clé demande toujours un nouveau certificat de vérification ainsi que l'historique de la clé de chiffrement. Il n'est pas nécessaire d'inclure l'utilisation de la clé dans chacune des demandes de certificat.

Flux de messages

Demande de récupération de clé


keyRecReq:: client ------------------->> CA
{
            pvno                         1
            sender                       Nom de l'utilisateur
            recipient                    Nom de l'AC
            messageTime                  Heure actuelle
            protectionAlg                MSG_MAC_ALG
            senderKID                    Numéro de référence
            transactionID                Propre à l'implémentation (significatif pour le client)
            senderNonce                  Nombre pseudoaléatoire à 128 bits
            freeText                     Texte
            body                         CertReqMessages
            protection                   bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)
Dans le cas des demandes de récupération de clé, la syntaxe utilisée est identique à celle indiquée dans l'élément CertReqMessages de la demande d'initialisation. De manière générale, les champs modèles SubjectPublicKeyInfo et KeyId doivent être utilisés pour obtenir une clé publique de signature pour laquelle on doit produire un certificat.


CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
           certReq      CertRequest,
           pop          ProofOfPossession OPTIONAL
           -- le contenu est déterminé par le type de clé }
L'information directement associée au contenu du certificat doit être incluse dans l'élément de contenu certReq. Toutefois, l'inclusion de contenu supplémentaire dans l'élément certReq par les AE peut invalider le champ pop.

Remarquez que s'il a besoin de l'historique de la clé, le demandeur doit fournir dans le message de demande un contrôle de clé de chiffrement de protocole. L'AC vérifie le message. S'il est valable, l'AC crée ensuite un certificat de vérification pour le client et prépare l'historique de clé de déchiffrement et les certificats de chiffrement à envoyer au client. L'AC répond en envoyant un message keyRecRep au client.

CertRequest ::= SEQUENCE {
           certReqId     INTEGER, 
           -- ID pour apparier la demande et la réponse
           certTemplate  CertTemplate, 
           -- Champs sélectionnés du certificat à émettre
           controls      Controls OPTIONAL
           -- Attributs ayant une incidence sur l'émission }

CertTemplate ::= SEQUENCE {
           version       [0] Version    OPTIONAL,
           serialNumber  [1] INTEGER    OPTIONAL,
           signingAlg    [2] AlgorithmIdentifier OPTIONAL,
           issuer        [3] Name       OPTIONAL,
           validity      [4] OptionalValidity    OPTIONAL,
           subject       [5] Name       OPTIONAL,
           publicKey     [6] SubjectPublicKeyInfo OPTIONAL,
           issuerUID     [7] UniqueIdentifier     OPTIONAL,
           subjectUID    [8] UniqueIdentifier     OPTIONAL,
           extensions    [9] Extensions           OPTIONAL }

Les champs additionnels reconnus par l'AC et qui peuvent être inclus dans la demande de cocertification PKIX-CMP sont les suivants : authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, extKeyUsage, privateKeyUsagePeriod, certificatePolicies, privateVersInfo, subjectAltName, basicConstraints et cRLDistributionPoints.

AlgorithmIdentifier ::= SEQUENCE {
            Algorithm      OBJECT IDENTIFIER,
            Parameters     ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
            Algorithm         AlgorithmIdentifier,
            SubjectPublicKey  BIT STRING }

Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
            type              OBJECT IDENTIFIER,
            value             ANY DEFINED BY type }
            id-regCtrl-regToken           OBJECT IDENTIFIER ::= { id-regCtrl 1 }
            id-regCtrl-authenticator      OBJECT IDENTIFIER ::= { id-regCtrl 2 }
            id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
            id-regCtrl-pkiArchiveOptions  OBJECT IDENTIFIER ::= { id-regCtrl 4 }
            id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
            id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }

Réponse de récupération de clé

keyRecRep:: CA ------------------->> client
{
            pvno                     1
            sender                   Nom de l'AC
            recipient                Nom de l'utilisateur
            messageTime              Heure actuelle
            protectionAlg            MSG_MAC_ALG
            recipKID                 Numéro de référence
            transactionID            Valeur tirée du message keyRecReq correspondant
            senderNonce              Valeur tirée du message keyRecReq correspondant
            recipNonce               Nombre pseudoaléatoire à 128 bits
            freeText                 Texte
            body                     KeyRecRepContent
            certificate              Présent
            privateKey               Présent
            protection               bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)
On utilise la syntaxe ci-dessous pour les réponses de récupération de clé. Pour certaines valeurs d'état (p. ex., en attente) aucun des champs facultatifs n'est présent.

KeyRecRepContent ::= SEQUENCE {
               status       PKIStatusInfo,
               newSigCert   [0] Certificate OPTIONAL,
               caCerts      [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
               keyPairHist  [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL
}

PKIStatusInfo ::= SEQUENCE {
             status         PKIStatus,
             statusString   PKIFreeText    OPTIONAL,
             failInfo       PKIFailureInfo OPTIONAL }
Le client vérifie le message. Les certificats de vérification et l'historique de clé de chiffrement sont transmis à l'application de sécurité. Le client envoie ensuite un message pKIConfirm à l'AC.

Confirmation de récupération de clé

pkiConfirm:: client ------------------->> CA
{
             pvno                         1
             sender                       Nom de l'utilisateur
             recipient                    Nom de l'AC
             transactionID                Valeur tirée du message keyRecRep correspondant
             senderNonce                  Valeur tirée du message keyRecRep correspondant
             recipNonce                   Valeur tirée du message keyRecRep correspondant
             protectionAlg                MSG_MAC_ALG
             senderKID                    Numéro de référence
             freeText                     Texte
             protection                   bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)

1.10 Révocation

Cette section inclut un profil pour le message de demande de révocation PKIX-CMP et le message de réponse correspondant pour la révocation de certificat de l'ICP par les abonnés et les AC de sujet. Elle indique les champs qui doivent être présents dans le message de demande et la façon dont leur contenu est dérivé. Elle indique également les réponses qui sont retournées dans différentes situations ainsi que la procédure que le demandeur doit effectuer lors de la réception de ces réponses. Cet échange est effectué lorsqu'un client doit révoquer son ou ses propres certificats. Cette transaction exige du client qu'il possède au moins une clé de signature valable. Un client peut demander la révocation de plusieurs certificats dans un même message. L'AC répond en attribuant un état à chacun des certificats dont on a demandé la révocation. Le client n'envoie aucun message de confirmation. Pour chaque certificat à révoquer, le client doit fournir à l'AC un moyen de déterminer le certificat cible (p. ex., le numéro de série du certificat).

L'échange de demande de révocation de clé comprend deux messages :

Authentification du message

Les clients authentifient le message en utilisant une clé de signature valable. L'AC authentifie le message en utilisant une clé de signature de protocole.

Incidence sur le flux de messages

Un client peut demander la révocation de plusieurs certificats dans un même message. L'AC répond en indiquant un état pour chacun des certificats dont on a demandé la révocation. Le client n'envoie aucun message de confirmation puisque cela n'est pas nécessaire dans ce cas. Pour chaque certificat à révoquer, le client doit fournir à l'AC un moyen de déterminer le certificat cible. À cette fin, on effectue l'une ou l'autre des procédures suivantes :

Au choix, le client peut préciser un motif de révocation (ReasonFlags), un élément GeneralizedTime représentant une date " not valid since " ainsi qu'un élément crlEntryExtensions. Le code de motif certificateHold n'est pas pris en charge. Toute demande contenant ce code de motif est rejetée par l'AC. L'AC doit s'assurer que le client qui demande la révocation est réellement le sujet de la révocation pour chaque demande incluse dans le message. Cette restriction est levée dans le cas d'un client de l'AE. L'AC répond en envoyant un message qui donne le détail de l'état de chacune des demandes de révocation.

Flux de messages

Demande de révocation

Lorsque l'on demande la révocation d'un certificat (ou de plusieurs certificats), on utilise la structure de données ci-dessous. Le nom du demandeur figure dans la structure PKIHeader.

revReq:: client ------------------->> CA
{
         pvno                         1
         sender                       Nom de l'utilisateur
         protectionAlg                MSG_SIG_ALG
         senderKID                    Aux fins de vérification de la protection du message
         transactionID                Propre à l'implémentation (significatif pour le client)
         senderNonce                  Nombre pseudoaléatoire à 128 bits
         freeText                     Texte
         body                         RevReqContent
         protection                    bits calculés en utilisant l'algorithme MSG_SIG_ALG
} Signature (signée avec la clé de signature du client)


RevReqContent ::= SEQUENCE OF RevDetails

RevDetails ::= SEQUENCE {
          certDetails    CertTemplate,
          -- permet au demandeur de préciser le maximum d'information concernant le
          -- certificat pour lequel il demande la révocation (p. ex., dans les cas où l'élément
          -- serialNumber n'est pas disponible)
          revocationReason ReasonFlags      OPTIONAL,
          -- motif de demande de la révocation
          badSinceDate     GeneralizedTime  OPTIONAL,
          -- indique la meilleure connaissance de l'émetteur
          crlEntryDetails  Extensions       OPTIONAL
          -- crlEntryExtensions demandé }

CertTemplate ::= SEQUENCE {
          version         [0] Version             OPTIONAL,
          serialNumber    [1] INTEGER             OPTIONAL,
          signingAlg      [2] AlgorithmIdentifier OPTIONAL,
          issuer          [3] Name                OPTIONAL,
          validity        [4] OptionalValidity    OPTIONAL,
          subject         [5] Name                OPTIONAL,
          publicKey       [6] SubjectPublicKeyInfo OPTIONAL,
          issuerUID       [7] UniqueIdentifier    OPTIONAL,
          subjectUID      [8] UniqueIdentifier    OPTIONAL,
          extensions      [9] Extensions          OPTIONAL }

AlgorithmIdentifier ::= SEQUENCE {
          Algorithm       OBJECT IDENTIFIER,
          Parameters      ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
          Algorithm          AlgorithmIdentifier,
          SubjectPublicKey   BIT STRING }

L'AC vérifie le message. S'il est valable, l'AC révoque le certificat concerné pour le client et envoie un message modifyRequest au directeur pour qu'il émette une nouvelle LCR qui inclut le certificat révoqué. L'AC répond en envoyant un message revRep au client.

Réponse de révocation

La réponse de révocation est envoyée au demandeur de la révocation.


revRep:: CA ------------------->> client
{
         pvno                     1
         sender                   Nom de l'AC
         recipient                Nom de l'utilisateur
         messageTime              Heure actuelle
         protectionAlg            MSG_SIG_ALG
         recipKID                 Numéro de référence
         transactionID            Valeur tirée du message revReq correspondant
         senderNonce              Valeur tirée du message revReq correspondant
         recipNonce               Nombre pseudoaléatoire à 128 bits
         freeText                 Texte
         body                     RevRepContent
         certificate              Présent
         privateKey               Présent
         protection               bits calculés en utilisant l'algorithme
         MSG_SIG_ALG extraCerts   Certification de vérification de protocole de l'AC
} Signature (signée avec une clé de signature de protocole AC)


RevRepContent ::= SEQUENCE {
        status        SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
        revCerts      [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
        crls          [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL }

PKIStatusInfo ::= SEQUENCE {
        status        PKIStatus,
        statusString  PKIFreeText       OPTIONAL,
        failInfo      PKIFailureInfo    OPTIONAL }

CertId ::= SEQUENCE {
        issuer        GeneralName,
        serialNumber  INTEGER }

CertificateList ::= SEQUENCE {
        tbsCertList             TBSCertList,
        signatureAlgorithm      AlgorithmIdentifier,
        signatureValue          BIT STRING }

TBSCertList ::= SEQUENCE {
        version                 Version       OPTIONAL,
        -- si présent, doit inclure la valeur v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time          OPTIONAL,

revokedCertificates SEQUENCE OF SEQUENCE {
        userCertificate         CertificateSerialNumber,
        revocationDate          Time,
        crlEntryExtensions      Extensions              OPTIONAL
        -- si présent, doit inclure la valeur v2 }      OPTIONAL,
        crlExtensions           [0] EXPLICIT Extensions OPTIONAL
        -- si présent, doit inclure la valeur v2 }

AlgorithmIdentifier ::= SEQUENCE {
        Algorithm               OBJECT IDENTIFIER,
        Parameters              ANY DEFINED BY algorithm OPTIONAL }

2. Mise à jour de clé de l'AC

2.1 Introduction

Cette section donne un aperçu de la procédure de mise à jour de clé de l'AC et indique la façon dont les utilisateurs de certificat obtiennent la nouvelle clé de l'AC. Ce mécanisme ne constitue pas une transaction de message PKIX-CMP.

2.2 Mise à jour d'une clé de l'AC racine

Le fondement de la présente procédure est le suivant : l'AC protège sa nouvelle clé publique en utilisant sa clé privée précédente, et vice versa. Ainsi, lorsqu'une AC met à jour sa biclé, elle doit produire deux valeurs d'attribut cACertificate supplémentaires si les certificats sont émis par le biais d'un Annuaire X.500. Il y a au total quatre attributs :

Lorsque l'AC modifie ses biclés, les entités qui ont acquis l'ancienne clé publique de l'AC par des mécanismes « hors bande » sont les plus touchées. Ces entités finales sont celles qui doivent accéder à la nouvelle clé publique de l'AC protégée avec l'ancienne clé privée de l'AC. Toutefois, les entités n'auront besoin de cette information que pour une période limitée (jusqu'à ce qu'elles acquièrent la nouvelle clé publique de l'AC en utilisant un mécanisme « hors bande »). Ces entités finales atteindront de manière générale cet objectif lorsque leurs certificats expireront. La structure de données utilisée pour protéger les anciennes et les nouvelles clés publiques de l'AC est un certificat standard (qui peut également contenir des champs additionnels). Aucune autre nouvelle structure de données n'est requise. Ce schéma n'utilise aucun des champs additionnels X.509 v3 puisqu'il doit être en mesure de fonctionner, même avec des certificats de version 1. La présence du champ additionnel KeyIdentifier permet d'apporter d'améliorer l'efficacité. Bien que le schéma puisse être généralisé afin de traiter les situations où l'AC met à jour ses biclés plus d'une fois durant la période de validité de l'un de ses certificats d'entité finale, ce genre d'approche est plus ou moins valable. Puisqu'une telle généralisation est impossible, la période de validité d'une biclé de l'AC doit donc être supérieure à celle de tout certificat émis en utilisant la biclé de cette AC. Ce schéma impose aux entités finales l'acquisition de la nouvelle clé publique de l'AC à l'expiration de leur dernier certificat signé (en utilisant des mécanismes « hors bande ») avec l'ancienne clé privée de l'AC. Les opérations de mise à jour de clé et de certificat effectuées à d'autres moments ne requièrent pas nécessairement l'utilisation de cette procédure (selon l'équipement de l'entité finale'). Après la mise à jour d'une clé de l'AC, il est important que les utilisateurs, quelque temps avant l'expiration de leurs ancienne AC racine de confiance, mettent à jour cette AC racine en utilisant la nouvelle clé publique de vérification de l'AC. Cette mise à jour s'accomplit lorsque l'utilisateur communique avec l'AC pour exécuter une opération de récupération ou de mise à jour de clé. Durant cette opération, le client reçoit sa nouvelle AC racine de confiance, qu'il conserve en toute sécurité dans son profil. Après la réception de cette AC racine, toutes les validations de certificat de client doivent mener de cette AC jusqu'au certificat en cours de validation.

2.3 Interventions de l'opérateur de l'AC

Pour modifier la clé de l'AC, l'opérateur de l'AC effectue ce qui suit :

  1. il produit une nouvelle biclé;
  2. il crée un certificat contenant l'ancienne clé publique de l'AC signée avec la nouvelle clé privée (certificat « old with new »);
  3. il crée un certificat contenant la nouvelle clé publique de l'AC signée avec l'ancienne clé privée (certificat « new with old »);
  4. il crée un certificat contenant la nouvelle clé publique de l'AC signée avec la nouvelle clé privée (certificat « new with new »);
  5. il publie ces nouveaux certificats dans l'Annuaire; et
  6. il exporte la nouvelle clé publique de l'AC de façon que les entités finales puissent l'acquérir en utilisant un mécanisme « hors bande » (s'il y a lieu). Ensuite, l'ancienne clé privée de l'AC n'est plus requise. Toutefois, on continue d'utiliser l'ancienne clé publique de l'AC pendant un certain temps. Cette dernière ne sera plus requise (autre qu'à des fins de non-répudiation) au moment où toutes les entités finales de l'AC concernée auront acquis en toute sécurité la nouvelle clé publique de l'AC. La période de validité du certificat « ancienne clé avec nouvelle clé » doit commencer au moment de la production de l'ancienne biclé et se terminer à l'expiration de l'ancienne clé publique. La période de validité du certificat « nouvelle clé avec ancienne clé » doit commencer au moment de la production de la nouvelle biclé et se terminer au moment où toutes les entités finales de cette AC seront en possession sécurisée de la nouvelle clé publique de l'AC (au plus tard, à la date d'expiration de l'ancienne clé publique). La période de validité du certificat « nouvelle clé avec nouvelle clé » doit débuter au moment de la production de la nouvelle biclé et se terminer au moment où l'AC effectue la prochaine mise à jour de sa biclé.

3. Protocole d'inscription de la norme PKCS

Cette section donne un aperçu du processus d'inscription de l'ICP associé aux normes PKCS. Elle inclut un profil de la norme PKCS #10 brute, du message de demande et de la norme PKCS #7, et du message de réponse ainsi que les formats PKIX-CMP, pour l'inscription des abonnés et des AC de sujet.

3.1 Tableaux de flux du protocole

La figure 4 illustre une demande unique d'inscription et les messages de réponse. Le contenu de ces messages est indiqué en détail ci-dessous.

Figure 4. Messages de demande et de réponse ICP simples Demande ICP simple Réponse ICP simple ------------------------- -------------------------- +------------------+ | message CMS | +----------+ | « certificats | | PKCS #10 | | seulement » | +----------+--------------+ | (PKCS #7) | | | +------------------+------ + | Demande de certificat | | | | | | Données signées CMS, | | Nom du sujet | | aucun élém. signerInfo| | Inform. de clé publique | | | | du sujet (K_PUB) | | L'élément signedData | | Attributs | | contient un ou plusieurs| | | | certificats dans sa | +-----------+-------------+ | partie « certificats » | | signé avec | | | | la clé | | | | K_PRIV cor- | | encapsulatedContentInfo | | respondante | | est vide. | +-------------+ | | +--------------+---------- + | non signé| +---------- +

3.2 Messages de l'ICP Cette section aborde les détails d'assemblage des différents messages de demande et de réponse d'inscription.

Demande d'inscription simple

Un message PKCS #10 ordinaire représente la forme la plus simple de demande d'inscription. Si l'on utilise cette forme de demande pour une clé privée capable de produire une signature, le message PKCS #10 doit être signé avec cette clé privée. Les serveurs doivent prendre en charge le message de demande simple d'inscription. Si l'on utilise ce message, les serveurs doivent retourner le message de réponse d'inscription simple si la demande d'inscription est accordée. Si la demande d'inscription échoue, la réponse d'inscription complète, ou aucune réponse, peut être retournée.

Réponse d'inscription simple

Les AC doivent utiliser le message de réponse d'inscription simple chaque fois que c'est possible. Les clients doivent être en mesure de traiter ce message. Le message de réponse d'inscription comprend un objet signedData, sans objet signerInfo. Les certificats demandés sont retournés dans le compartiment de certificat de l'objet signedData. Les clients ne doivent pas présumer que les certificats sont dans un ordre particulier. Les serveurs doivent inclure tous les certificats intermédiaires requis pour former les chaînes d'un ou de plusieurs certificats autosignés, et non seulement le(s) certificat(s) nouvellement émis. Les clients ne doivent pas accorder implicitement leur confiance au(x) certificat(s) autosigné(s) inclus en raison de leur seule présence le compartiment de certificat. Advenant que les clients reçoivent un nouveau certificat autosigné du serveur, ils doivent prévoir un mécanisme pour permettre à l'utilisateur d'accorder explicitement sa confiance au certificat.

3.3 PKCS #10

Les demandes de certification sont fondées soit sur des messages PKCS #10 ou CRMF (PKIX-CMP). Les sections suivantes précises la syntaxe

Aperçu général

La norme PKCS #10 décrit une syntaxe pour les demandes de certification. Une demande de certification comprend un nom distinctif, une clé publique, et au choix, un ensemble d'attributs collectivement signés par l'entité qui demande la certification. Les demandes de certification sont envoyées à l'AC, qui les transforme en un certificat à clé publique X.509. Un message PKCS #7 représente une forme typique que l'AC utilise pour retourner le nouveau certificat signé. L'application préliminaire prévue de la norme PKCS#10 consiste à prendre en charge les messages cryptographiques PKCS #7.

Syntaxe générale

Lors de la production d'un corps de demande PKCS #10, les clients doivent produire un corps de message PKCS #10 contenant un nom de sujet et une clé publique. Une entité doit de manière générale envoyer une demande de certification PKCS #10 (qui est ensuite enveloppée dans un message PKIX) à l'AC, pour la première initialisation, après avoir produit une paire de clés publique/privée; toutefois, l'entité peut également effectuer cette opération après une modification du nom distinctif (DN) de l'entité. Le client doit quand même extraire par un mécanisme hors bande un numéro de référence et un code d'autorisation. Ainsi, le sujet inclut dans le message PKCS #10 doit être soit le nom distinctif (DN) réel de l'utilisateur associé au numéro de référence donné, soit un DN de la forme cn=. Certains produits de certification fonctionnent avec un dépôt central d'information utilisé pour attribuer des noms de sujet lors de la réception d'une clé publique aux fins de certification. Pour tenir compte de ce mode de fonctionnement, le nom de sujet dans l'élément CertificationRequest doit être nul, mais présent. Les AC qui reçoivent un élément CertificationRequest dont le nom de sujet est nul peuvent rejeter de telles demandes. Si elles les rejettent et qu'une réponse est retournée, elles doivent répondre en utilisant la valeur badRequest dans l'attribut failInfo. Une demande de certification PKCS #10 comprend trois parties :

CertificationRequest

Une demande de certification doit utiliser le type CertificationRequest de la syntaxe ASN.1 :

CertificationRequest ::= SEQUENCE {
                 version               0
                 -- La version actuelle de PKCS #10 est 0
                 subject               User name,
                 subjectPublicKeyInfo  SubjectPublicKeyInfo,
                 -- Information de clé pour la clé de vérification publique
                 attributes            [0] IMPLICIT Attributes
                 -- Doit inclure l'élément keyUsage et le champ additionnel extKeyUsage
                 signatureAlgorithm    SignatureAlgorithmIdentifier
                 -- p. ex., md5WithRSAEncryption
                 signature             Signature }
La structure CertificationRequest décrite ci-dessus est construite à partir des structures de base CertificationRequest et CertificationRequestInfo, décrites ci-dessous.

AlgorithmIdentifier ::= SEQUENCE {
                 Algorithm            OBJECT IDENTIFIER,
                 Parameters           ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
                 Algorithm            AlgorithmIdentifier,
                 SubjectPublicKey     BIT STRING }

CertificationRequest ::= SEQUENCE {
                 certificationRequestInfo     CertificationRequestInfo,
                 signatureAlgorithm           SignatureAlgorithmIdentifier,
                 signature                    Signature }

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

Signature ::= BIT STRING
Les champs de type CertificationRequest ont les significations suivantes :

CertificationRequestInfo

L'information de demande de certification doit posséder le type CertificationRequestInfo de la syntaxe ASN.1 :


CertificationRequestInfo ::= SEQUENCE {
                  version                  0
                  subject                  User name,
                  subjectPublicKeyInfo     SubjectPublicKeyInfo,
                  attributes               [0] IMPLICIT Attributes }

Version ::= INTEGER

AlgorithmIdentifier ::= SEQUENCE {
                 Algorithm                OBJECT IDENTIFIER,
                 Parameters               ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
                 Algorithm                AlgorithmIdentifier,
                 SubjectPublicKey         BIT STRING }

Attributes ::= SET OF Attribute

Attribute ::= SEQUENCE {
                 type                     AttributeType,
                 values                   SET OF AttributeValue
                 -- Doit inclure l'élément keyUsage et le champ additionnel extKeyUsage }

AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY

Les champs de type CertificationRequestInfo ont les significations suivantes :

3.4 PKCS #7

La norme PKCS #7 décrit une syntaxe générale pour les données auxquelles on peut appliquer des opérations cryptographiques telles les signatures et les enveloppes numériques. Un cas dégénéré de la syntaxe offre un moyen de diffuser les certificats et les LCR. C'est le cas pour la réponse PKCS #7 à la demande PKCS #10.

Aperçu général

La syntaxe de la norme PKCS #7 accepte la récurrence de manière que, par exemple, une enveloppe peut être imbriquée dans une autre, ou qu'une partie peut signer certaines données numériques enveloppées antérieurement. Elle permet également d'authentifier des attributs arbitraires, telle l'heure de signature, avec le contenu de message et d'associer d'autres attributs, telles des contre-signatures, à une signature. Un cas dégénéré de la syntaxe offre le moyen de diffuser des certificats et des LCR. La syntaxe de la norme PKCS #7 est de nature suffisamment générale pour prendre en charge plusieurs types de contenus différents. La norme PKCS #7 définit six types :

Dans le cas de la réponse PKCS #7 à la demande PKCS #10, on utilise les types de contenu données et données signées.

Syntaxe générale

Champ Contentinfo global

La syntaxe générale du contenu échangé entre entités conformément à la norme PKCS #7 associe un type de contenu avec le contenu. La syntaxe utilise le type ContentInfo de la syntaxe ASN.1 :

ContentInfo ::= SEQUENCE {
          contentType      signedData (1.2.840.113549.1.7.2)
          version          1
          -- Valeur 1 pour cette version de la norme PKCS #7
          digestAlgorithms DigestAlgorithmIdentifiers
          -- Valeur NULL
          contentType      data (1.2.840.113549.1.7.1)
          certificate      
                  
                  version                  [0] Version,
                  serialNumber             CertificateSerialNumber,
                  signature                AlgorithmIdentifier,
                  issuer                   Name,
                  validity                 Validity,
                  subject                  Name,
                  subjectPublicKeyInfo     SubjectPublicKeyInfo,
                  issuerUniqueIdentifier   [1] IMPLICIT UniqueIdentifier OPTIONAL,
                  -- Valeur NULL
                  subjectUniqueIdentifier  [2] IMPLICIT UniqueIdentifier OPTINAL

                  -- Valeur NULL
                  extensions               [3] Extensions OPTIONAL
                  -- Si le champ est présent, la version doit être v3 }
                  crls                     [1] IMPLICIT CertificateRevocationLists OPTIONAL
                  -- Valeur NULL
                  signerInfos              SignerInfos
                  -- Valeur NULL }

AlgorithmIdentifier ::= SEQUENCE {
                  Algorithm                OBJECT IDENTIFIER,
                  Parameters               ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
                  Algorithm                AlgorithmIdentifier,
                  SubjectPublicKey         BIT STRING }

Les champs de type ContentInfo ont les significations suivantes :

Type de contenu Signed-data

Le type de contenu signed-data comprend un contenu de n'importe quel type ainsi quedes condensés par hachage de message chiffré du contenu pour aucun ou plusieurssignataires. Le condensé par hachage chiffré d'un signataire est la « signature numérique » du contenu pour ce signataire. N'importe quel type de contenu peut être signé simultanément par n'importe quel nombre de signataires. On prévoit que l'application générale du type de contenu signed-data consistera à représenter la signature numérique d'un signataire du contenu du type de contenu de données.

Nota : La syntaxe possède un cas dégénéré dans lequel il n'y a aucun signataire du contenu. Ce cas offre un moyen de diffuser les certificats et les LCR. C'est le cas d'une réponse à une demande PKCS.

Nota : Pour répondre à une demande PKCS #10, une application type consistera à diffuser les certificats et les LCR.

Le type de contenu signed-data doit utiliser le type SignedData de la syntaxe ASN.1 :

SignedData ::= SEQUENCE {
          version          1
          digestAlgorithms DigestAlgorithmIdentifiers,
          contentInfo      ContentInfo,
          certificates     [0] IMPLICIT ExtendedCertificatesAndCertificates OPTION,
          crls             [1] IMPLICIT CertificateRevocationLists OPTIONAL,
          signerInfos      SignerInfos }

Les champs de type SignedData ont les significations suivantes :

Ce groupe inclut de l'information sur chaque signataire.


ExtendedCertificatesAndCertificates ::= SET OF ExtendedCertificateOrCertificate

ExtendedCertificateOrCertificate ::= CHOICE {
              certificate          Certificate,
              extendedCertificate  [0] IMPLICIT ExtendedCertificate }

Certificate ::= SEQUENCE {
              version                 [0] Version,
              serialNumber            CertificateSerialNumber,
              signature               AlgorithmIdentifier,
              issuer                  Name,
              validity                Validity,
              subject                 Name,
              subjectPublicKeyInfo    SubjectPublicKeyInfo,
              issuerUniqueIdentifier  [1] IMPLICIT UniqueIdentifier OPTIONAL,
              -- Valeur NULL
              subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL
              -- Valeur NULL
              extensions              [3] Extensions OPTIONAL
              -- Si le champ est présent, la version doit être v3 }

Version ::= INTEGER { v1(0), v2(1), v3(2) }

AlgorithmIdentifier ::= SEQUENCE {
              Algorithm               OBJECT IDENTIFIER,
              Parameters              ANY DEFINED BY algorithm OPTIONAL }

SubjectPublicKeyInfo ::= SEQUENCE {
              Algorithm               AlgorithmIdentifier,
              SubjectPublicKey        BIT STRING }

ContentInfo imbriqué

Dans le cas dégénéré où il n'y a pas de signataire dans le contenu, la valeur ContentInfo actuellement « signée » n'est pas pertinente. On recommande dans ce cas que le type de contenu de la valeur ContentInfo actuellement « signée » soit le type Data et d'omettre le champ de contenu de la valeur ContentInfo (NULL).

ContentInfo ::= SEQUENCE {
           contentType     ContentType,
           content         [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

Les champs de type ContentInfo ont les significations suivantes :

3.5 Incidence sur le flux de messages

La signature de la demande de certification empêche une entité donnée de demander un certificat en utilisant la clé publique d'une autre partie. Une telle attaque permettrait à l'entité de prétendre être l'émettrice de tout message signé par l'autre partie. Cette attaque est significative seulement si l'entité ne connaît pas le message dont on effectue la signature et si la partie signée du message n'identifie pas le signataire. L'entité pourra quand même déchiffrer les messages à l'intention de l'autre partie, évidemment.

Une AC remplit la demande en vérifiant la signature numérique de l'entité et, si la signature est valable, produit un certificat X.509 à partir du nom distinctif et de la clé publique, ainsi qu'un nom d'émetteur, un numéro de série, une période de validité et un algorithme de signature de son choix.

Les AC :

3.6 Flux de messages

Les AC doivent être capables de comprendre et de traiter les corps de demande PKCS#10. Les clients doivent produire un corps de demande PKCS #10 lorsqu'ils utilisent le message de demande d'inscription simple. Le flux de messages est le même pour toutes les demandes qui donnent lieu à la production d'un certificat. Le client doit donc produire un message de confirmation.

L'échange de demande PKCS #10 comprend trois messages :

Demande PKCS #10

pkcs10Req:: client ------------------->> CA
{
            pvno                         1
            sender                       Nom de l'utilisateur
            recipient                    Nom de l'AC
            messageTime                  Heure actuelle
            protectionAlg                MSG_MAC_ALG
            senderKID                    Numéro de référence
            transactionID                Propre à l'implémentation (significatif pour le client)
            senderNonce                  Nombre pseudoaléatoire à 128 bits
            freeText                     Texte
            body                         CertificationRequest
            protection                   bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)

L'AC vérifie le message. S'il est valable, l'AC produit un nouveau certificat pour le client et envoie un message modifyRequest dans l'Annuaire pour émettre un nouveau certificat. L'AC répond en transmettant au client un message pkcs7Rep. La structure CertificationRequest de la norme PKCS # 10 est définie à la section.

Réponse PKCS #7

pkcs7Rep:: CA ------------------->> client
{
           pvno                     1
           sender                   Nom de l'AC
           recipient                Nom de l'utilisateur
           messageTime              Heure à laquelle l'AC a produit le message
           protectionAlg            MSG_MAC_ALG
           recipKID                 Numéro de référence
           transactionID            Valeur tirée du message pkcs10Req correspondant
           senderNonce              Valeur tirée du message pkcs10Req correspondant
           recipNonce               Nombre pseudoaléatoire à 128 bits
           freeText                 Texte
           body                     CertificationResponse
           certificate              Présent
           privateKey               Présent
           protection               bits calculés en utilisant l'algorithme MSG_MAC_ALG
           extraCerts               Certification de vérification de protocole de l'AC
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)
Le client vérifie le message. Il envoie ensuite un message pKIConfirm à l'AC. La structure CertificationResponse de la norme PKCS #7.

Confirmation

Cette structure de données est utilisée dans les protocoles à trois voies en guise de message final PKIMessage. Dans tous les cas, le contenu du corps est le même - de fait, il n'y a pas de contenu puisque l'élément PKIHeader inclus toute l'information requise.


pkiConfirm:: client ------------------->> CA
{
             pvno                         1
             sender                       Nom de l'utilisateur
             recipient                    Nom de l'AC
             transactionID                Valeur tirée du message pkcs10Req correspondant
             senderNonce                  Valeur tirée du message pkcs10Req correspondant
             recipNonce                   Valeur tirée du message pkcs7Rep correspondant
             protectionAlg                MSG_MAC_ALG
             senderKID                    Aux fins de vérification de la protection du message
             freeText                     Texte
             protection                   bits calculés en utilisant l'algorithme MSG_MAC_ALG
} MAC (clé fondée sur un code d'autorisation et utilisée pour créer le code MAC
pour la structure)

4. Glossaire

LRA Liste des autorités révoquées ASN.1 Abstract Syntax Notation 1 AC Autorité de certification LCR Liste des certificats révoqués DER Règles de codage distinctives DN Nom distinctif DSA Digital Signature Algorithm DSS Digital Signature Standard EF Entité finale GUI Interface utilisateur graphique IETF Internet Engineering Task Force IPSec Internet Protocol Security UIT-T Union internationale des télécommunications - Secteur de normalisation LDAP Lightweight Directory Access Protocol MD2,MD5 Message Digest 2, 5 OID Identificateur d'objet PEM Privacy Enhanced Mail ICP Infrastructure à clé publique PKIX Infrastructure à clé publique fondée sur la norme X.509 PSE Personal Security Environment AE Autorité d'enregistrement RSA Rivest, Shamir, Adelman (RSA algorithm) SHA-1 Secure Hash Algorithm 1 AH Autorité d'horodatage TC Tiers de confiance

5. Références