Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
07 juillet 2016

htmlpdflatexmanmd




rfc3161

rfc3161, rfc5816

PKIX Time-Stamp Protocol

   Un service d'horodatage supporte la preuve qu'une donnée existait à une date donnée. Un TSA peut être opéré par un Tiers de confiance (TTP - Trusted Third Party), bien que d'autres modèles opérationels peuvent être appropriés, par ex, une organisation peut exiger un TSA pour de l'horodatage interne.

   Les services de non-répudiation exigent la capacité d'établir l'existence d'une donnée avant une date spécifiée. Ce protocole peut être utilisé comme bloque de construction de tels services.

   Pour associer une donnée avec un point dans le temps, une autorité d'horodatage (TSA) peut être utilisé. Ce tiers de confiance fournis une preuve d'existence pour cette donnée particulière à une point dans le temps.

   Le rôle du TSA est de dater une donnée pour établir l'évidence indiquant qu'une donnée existait avant une date particulière. Cela peut être utilisé, par exemple, pour vérifier qu'une signature numérique a été appliquée à un message avant que le certificat correspondant n'ait été révoqué, permettant à une clé publique révoquée d'être utilisé pour vérifier la signature créé avant la date de révocation. C'est une opération PKI importante. Le TSA peut également être utilisé pour indiquer la date d'émission quand une deadline est critique, ou pour indiquer la date de transaction pour les entrées dans un log.

Le TSA

   Le TSA est un TTP qui créé des jetons d'horodatage pour indiquer qu'une donnée a existé à un point dans le temps particulier. Pour le reste du document, une "requête valide" signifie une requête que peut être décodée correctement.

Pre-requis du TSA

   Le TSA doit:

- Utiliser une source de temps fiable pour chaque jeton d'horodatage
- Inclure une date fiable pour chaque jeton d'horodatage
- Inclure un entier unique pour chaque jeton d'horodatage généré
- produire un jeton d'horodatage une fois reçu une requête valide, si possible
- Inclure dans chaque jeton d'horodatage un identifiant pour indiquer de manière unique la stratégie de sécurité sous laquelle le jeton a été créé.
- horodater seulement une représentation hashée des données
- examiner l'OID d'une fonction de hash résistante aux collisions et vérifier que la longueur du hash est consistante avec l'algorithme
- Ne pas example l'empreinte à horodater de toute autre manière
- Ne pas inclure d'identification de l'identité demandeur dans les jetons d'horodatage
- Signer chaque jeton d'horodatage en utilisant une clé générée exclusivement dans ce but et avoir cette propriété de clé indiquée dans le certificat correspondant.
- Inclure les informations additionnelles dans le jeton d'horodatage, si demandé en utilisant le champs extensions, seulement pour les extensions qui sont supportés par le TSA. Si ce n'est pas possible, le TSA doit répondre avec un message d'erreur.

Transactions TSA

   Comme premier message de ce mécanisme, l'entité demande un jeton d'horodatage via une requête (qui est ou inclus un TimeStampReq) au TSA. Comme second message, le TSA répond en envoyant une réponse (qui est ou inclus un TimeStampResp) à l'entité.

   Une fois reçu la réponse ( qui est ou inclus un TimeStampResp qui contient normalement un TimeStampToken (TST) ), l'entité doit vérifier le status retourné dans la réponse et en l'absence d'erreur il doit vérifier les divers champs contenus dans le TimeStampToken et la validité de la signature numérique du TimeStampToken. En particulier, il doit vérifier que l'horodatage correspond à ce qui était demandé. Le demandeur doit vérifier que le TimeStampToken contient l'identifiant de certificat correcte du TSA, l'empreinte des données correcte, et l'OID de l'algorithme de hashage correcte. Il doit ensuite vérifier le délai de la réponse en vérifiant soit la date incluse dans la réponse avec une source de temp locale fiable de référence, si disponible, ou la valeur du nonce (un grand nombre aléatoire avec une grande probabilité qu'il a été généré par le client seulement une seule fois) inclus dans la réponse avec la valeur inclus dans la demande. Si une de ces vérification échoue, le TimeStampToken doit être rejeté.

   Ensuite, le certificat du TSA peut avoir été révoqué, le status du certificat doivrait être vérifié pour s'assurer que le certificat est valide.

   Ensuite, l'application cliente devrait vérifie le champ policy pour déterminer si la stratégie sous laquelle le jeton a été émis est acceptable pour l'application.

Identification du TSA

   Le TSA doit signer chaque message avec une clé réservée spécifiquement dans ce but. Un TSA peut avoir des clé privées distincts, par ex, pour gérer différentes stratégie, différents algorithmes, différentes tailles de clé ou pour augmenter les performances. Le certificat correspondant doit contenir seulement une instance du champ d'utilisation de clé avec KeyPurposeIP ayant la valeur: id-kp-timeStamping. Cette extension doit être critique.

L'identifiant d'objet suivant identifie le KeyPurposeIP ayant la valeur id-kp-timeStamping
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
        identified-organization(3) dod(6)
        internet(1) security(5) mechanisms(5) pkix(7)
        kp (3) timestamping (8)}

Format des requêtes

Une requête time-stamping est comme suit:
TimeStampReq ::= SEQUENCE {
    version INTEGER { v1(1) },
    messageImprint MessageImprint,
        --Un OID d'algorithme de hash et la valeur du hash des donnée à horodater
    reqPolicy TSAPolicyId OPTIONAL,
    nonce INTEGER OPTIONAL,
    certReq BOOLEAN DEFAULT FALSE,
    extensions [0] IMPLICIT Extensions OPTIONAL }

   Le champ version (actuellement v1) décris la version de la demande d'horodatage.

Le champ messageImprint devrait contenir le hash des données à horodater. Le hash est représenté comme chaîne d'octets. Sa longueur doit correspondre à la longueur de la valeur du hash pour cet algorithme. (20 octets pour SHA1, 16 pour MD5).
MessageImprint ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    hashedMessage OCTET STRING }

   L'algorithme de hashage indiqué dans le champ hashAlgoritm devrait être un algorithme de hashage connu. Cela signifie qu'il doit être one-way et résistant aux collisions. Le TSA devrait vérifier si l'algorithme de hashage donné est connu pour être suffisant. Si le TSA ne reconnait pas l'algorithme de hashe ou sait qu'il est faible, le TSA devrait refuser de fournir le jeton d'horodatage en retournant un pkiStatusInfo de 'bad_alg'.

   Le champ reqPolicy, si inclus, indique la stratégie TSA sous laquelle le TimeStampTocke devrait être fournis. TSAPolicyId est définis comme suit: TSAPolicyId ::= OBJECT IDENTIFIER

   Le nonce, si inclus, permet au client de vérifier la date de la réponse quand aucune horloge locale n'est disponible. Le nonce est un grand nombre aléatoire avec une forte probabilité que le client l'a généré seulement une seule fois. Dans ce cas la même valeur nonce doit être incluse dans la réponse, sinon la réponse doit être rejetée.

   Si le champ certReq est présent et à true, le certificat du TSA qui est référencé par l'identifiant ESSCertID dans un attribut SigningCertificate ou ESSCertIDv2 dans la réponse doit être fournie par le TSA dans le champ certificates de la structure SignedData dans cette réponse. Ce champ peut également contenir d'autres certificats.

   Si le champ certReq est manquant ou s'est est présent est à false, le champ certificates ne doit pas être présent dans la réponse.

   Le champ extensions est un manière générique d'ajouter des informations additionnelles aux requêtes dans le future. Les extensions sont définies dans la rfc2459. Si une extension, qu'elle soit marquée critique ou non, est utilisée par un demandeur mais non reconnue par le TSA, le serveur ne doit pas émettre de jeton et doit retourner une erreur (unacceptedExtension)

   La requête d'horodatage ne doit pas identifier le demandeur, vu que cette information n'est pas validée par le TSA. Dans les situations où le TSA exige l'identité du demandeur, une identification/authentification alternative doit être mise en place.

Format de réponse

Une réponse d'horodatage est comme suit:
TimeStampResp ::= SEQUENCE {
    status PKIStatusInfo,
    timeStampToken TimeStampToken OPTIONAL }

Le status est basé sur la définition des status dans la rfc2510 comme suit:
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL }

Quand le status contient la valeur 0 ou 1, un TimeStampToken doit être présent. Quand le status contient une autre valeur, un TimeStampToken ne doit pas être présent. Une des valeurs suivantes doit être contenus dans le status:
PKIStatus ::= INTEGER {
    granted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4), // indique une révocation imminente
    revocationNotification (5) // indique une révocation

   Les serveurs conformes ne doivent pas produire d'autres valeur. Les clients conforme doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.

Quand le TimeStampToken n'est pas présent, failInfo indique la raison du rejet de le requête et peut être une des valeurs suivantes:
PKIFailureInfo ::= BIT STRING {
    badAlg (0), -- identifiant d'algorithme non supporté ou inconnu
    badRequest (2), -- transaction non permise ou non supportée
    badDataFormat (5), -- Mauvais format de données transmises
    timeNotAvailable (14), -- Source de temps du TSA non disponible
    unacceptedPolicy (15), -- La stratégie TSA demandée n'est pas supportée par le TSA
    unacceptedExtension (16), -- extension non supportée par le TSA
    addInfoNotAvailable (17), -- Les informations additionnelles demandées ne sont pas comprises ou non disponible
    systemFailure (25) -- La requête ne peut pas être gérée à cause d'une erreur système
}

   Ce sont les seules valeurs de PKIFailureInfo qui doivent être supportées.

   Les serveurs conformes ne doivent pas produire d'autres valeurs. Les clients conformes doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.

   Le champ statusString de PKIStatusInfo peut être utilisé pour inclure un texte de raison.

Un TimeStampToken est comme suit. Il est définis comme ContentInfo et doit encapsuler un type de contenu de données signée.
TimeStampToken ::= ContentInfo
    -- contentType is id-signedData ([CMS])
    -- content is SignedData ([CMS])

   Les champs de type EncapsulatedContentInfo de la construction SignedData ont la signification suivante:

eContentType est un identifiant d'objet qui spécifie uniquement le type de contenu. Pour un jeton d'horodatage il est définis comme suit:
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

   eContent est le contenu, un chaîne d'octet, un TSTInfo encodé DER.

Le jeton d'horodatage ne doit pas contenir de signature autre que la signature du TSA. L'identifiant de certificat (ESSCertID ou ESSCertIDv2) du certificat TSA doit être inclus comme attribut signerInfo dans l'attribut SigningCertificate.
TSTInfo ::= SEQUENCE {
    version INTEGER { v1(1) },
    policy TSAPolicyId,
    messageImprint MessageImprint,
        -- doit avoir la même valeur que le champ similaire dans TimeStampReq
    serialNumber INTEGER,
    genTime GeneralizedTime,
    accuracy Accuracy OPTIONAL,
    ordering BOOLEAN DEFAULT FALSE,
    nonce INTEGER OPTIONAL,
        -- Doit être présent si le champ similaire est présent dans TimeStampReq, et doit avoir la même valeur
    tsa [0] GeneralName OPTIONAL,
    extensions [1] IMPLICIT Extensions OPTIONAL }

   Le champ version (v1) décris la version du jeton d'horodatage. Les serveurs conformes doivent être capable de fournir des jetons version 1.

   Parmis les champs optionnels, seul nonce doit être supporté. Les demandeurs conforme doivent être capable de reconnaitre les jeton d'horodatage version 1 avec tous les champs optionnels présents, mais ne sont pas obligés de comprendre les sémantiques des extensions. si présent.

   Le champ policy doit indiquer la stratégie TSA sous laquelle la réponse a été produite. Si un champ similaire est présent dans TimeStampReq, il doit avoir la même valeur, sinon une erreur unacceptedPolicy doit être retournée. Cett stratégie peut inclure les types d'information suivantes (bien que cette liste n'est certainement pas exhaustive):

- Les condition sous lesquels le jeton peut être uilisé
- La disponibilité de log de jeton d'horodatage, pour permettre une vérification ultérieur de l'authenticité du jeton.

   Le messageImprint doit avoir la même valeur que le champ similaire dans le TimeStampReq, indiquant que la taille de la valeur du hash matche la taille attendue de l'algorithme de hashage identifié dans hashAlgorithm.

   Le champ serialNumber est un entier assigné par le TSA pour chaque TimeStampTocken. Il doit être unique pour chaque TimeStampToken émis par un TSA donné.

   genTime est la date à laquelle le jeton a été créé par le TSA. Il est exprimé en temp UTC pour réduire la confusion avec le timezone local. UTC est une échelle de temp, basée sur le secon (SI), comme définis et recommandé par le CCIR, et maintenu par le Bureau International des Poids et Mesures (BIPM). Un synonime est le temp "Zulu" qui est utilisé par l'aviation civile et représentée par la lettre Z.

accuracy représent la déviation de temp autour du temps UTC contenus dans GeneralizedTime.
Accuracy ::= SEQUENCE {
    seconds INTEGER OPTIONAL,
    millis [0] INTEGER (1..999) OPTIONAL,
    micros [1] INTEGER (1..999) OPTIONAL }

   Si un des éléments est manquant, la valeur est considéré comme 0. En ajoutant la valeur accuracy dans le GeneralizedTime, une limite supérieur du temp auquel le jeton d'horodatage a été créé par la TSA peut être obteni. De la même manière, en soustrayant l'accuracy au GeneralizedTime, une limite inférieur du temp auquel le jeton a été créé par le TSA peut être obtenu.

   Si le champ ordering est manquant, ou s'il est présent et mis à false, le champ genTime indique seulement le temp auquel le jeton a été créé par le TSA. Dans un tel cas, l'ordre des jetons d'horodatage émis par le même TSA ou différents TSA est seulement possible quand la différence entre le genTime du premier jeton et le genTime du second jeton est supérieur à la somme des accuracy du genTime pour chaque jeton.

   Si le champ ordering est présent et à true, tout jeton du même TSA peut toujours être ordonné basé sur le champ genTime, sans regarder l'accuracy GenTime.

   Le champ nonce doit être présent s'il est présent dans le TimeStampReq. Dans ce cas, il doit être recopié dans la structure TimeStampReq.

   Le but du champ tsa est de donner une indication pour identifier le nom du TSA. Si présent, il doit correspondre à un des nom de sujet inclus dans le certificat qui est utilisé pour vérifier le jeton. Cependant, l'identification de l'entité qui a signé la réponse se produit toujours via l'utilisation de l'identifiant de certificat (ESSCertID) dans l'attribut SigningCertificate ou ESSCertIDv2 dans l'attribut SigningCertificateV2 qui fait partie du signerInfo.

   Les extensions sont une manière générique d'ajouter des informations additionnelles dans le future.

Transports

   Il n'y a pas de mécanisme de transport obligatoire pour les messages TSA dans ce document. Les mécanismes décris ci-dessous sont optionnels, d'autres mécanisme pouvant être définis dans le future.

E-mail

Cette section spécifie un moyen de transporter des messages encodés ASN.1 pour l'échange de protocole via les mails. 2 objets MIME sont spécifiés comme suit:
Content-Type: application/timestamp-query
Content-Transfer-Encoding: base64
‹‹the ASN.1 DER-encoded Time-Stamp message, base64-encoded››

Content-Type: application/timestamp-reply
Content-Transfer-Encoding: base64
‹‹the ASN.1 DER-encoded Time-Stamp message, base64-encoded››

   Ces objets MIME peuvent être respectivement envoyés et reçus en utilisant les moteurs de traitement MIME qui fournissent un simple transport par mail des messages d'horodatage.

Pour les types MIME application/timestamp-query et application/timestamp-reply, les implémentations devraient inclure les paramètres optionnels "name" et "filename". Inclure un nom de fichier aide à préserver le type d'information quand les requêtes et réponses d'horodatage sont sauvées en tant que fichier. Quand ces paramètres sont inclus, un nom de fihier avec l'extension approprié devrait être sélectionné:
______MIME Type_____________________File Extension
application/timestamp-query____________.TSQ
application/timestamp-reply____________.TSR

Fichier

   Un fichier contenant un message timestamp doit contenir seulement l'encodé DER d'un message TSA. De tels fichiers peuvent être utilisé pour transporter les messages timestamp en utiisant ftp par exemple.

   Une requête timestamp devrait être contenue dans un fichier avec l'extension .tsq, et une réponse devrait être contenue dans un fichier avec l'extension .tsr

Socket

   Le protocole suivant basé sur TCP est utilisé pour transporter les messages TSA. Ce protocole est utilisable pour les cas où une entité initie une transaction et peut demander un résultat. Le protocole assume qu'un processus d'écoute dans un TSA peut accepter les messages TSA sur un port définis (318).

   Généralement un initiateur lie ce port et envoie le message TSA initiale. Le répondeur répond avec un message TSA et/ou avec un numéro de référence à utiliser ultérieurement pour demander la réponse.

   L'initiateur d'une transaction envoie un "direct TCP-based TSA message" au destinataire. Le destinataire répond avec un message similaire. Un "direct TCP-based TSA message" consiste de: length (32-bits), flag (8-bits), value (defined below)

Le champ longueur contient le nombre d'octets du reste du message. Toutse les valeurs 32bits dans ce protocole sont spécifiés pour être dans l'ordre d'octet réseaux
Message name flag value
tsaMsg '00'H DER-encoded TSA message -- message TSA
pollRep '01'H polling reference (32 bits),
                    time-to-check-back (32 bits)
                    -- Réponse quand aucun message TSA n'est prête. Utilise la valeur polling reference (et la valeur de date estimée) pour la demande ultérieur.
pollReq '02'H polling reference (32 bits)
                    -- demande d'une réponse TSA pour le message initial
negPollRep '03'H '00'H
                     pas d'autre réponses ultérieur (ex: transaction complète)
partialMsgRep '04'H next polling reference (32 bits),
                    time-to-check-back (32 bits),
                    DER-encoded TSA message
                    -- réponse partielle du message initial plus une nouvelle référence d'attente à utilise pour obtenir la prochaine partie de la réponse
finalMsgRep '05'H DER-encoded TSA message
                    -- réponse finale du message initial
errorMsgRep '06'H human readable error message
                    -- produit quand une erreur est détectée

   La séquence des messages qui se produit est:

a) L'entité envoie tsaMsg et reçoit un pollRep, negPollRep, partialMsgRep, ou finalMsgRep dans la réponse.
b) L'entité envoie un message pollReq et reçois negPollRep, partialMsgRep, finalMsgRep, ou errorMsgRep dans la réponse

HTTP

2 objets MIME sont spécifiés comme suit:
Content-Type: application/timestamp-query
    
    ‹‹the ASN.1 DER-encoded Time-Stamp Request message››
    
Content-Type: application/timestamp-reply
    
    ‹‹the ASN.1 DER-encoded Time-Stamp Response message››

   Ces 2 objets MIME peuvent être envoyés et reçus en utilisant un moteur de traitement HTTP sur des liens WWW et fournis un transport simple via navigateur internet. Une fois un requête valide reçue, le serveur doit répondre avec soit une réponse valide avec le type application/timestamp-response, ou avec une erreur HTTP.

Considérations de sécurité

   Tout le document est concerné par les considérations de sécurité. En concevant un service TSA, les considérations suivantes ont été identifiées comme ayant un impacte sur la validité ou la confiance dans le jeton d'horodatage.

   1. Quand un TSA ne doit plus être utilisé, mais la clé privée TSA n'a pas été compromise, le certificat de l'autorité doit être révoqué. Quand l'extension reasonCode relatif au certificat révoqué du TSA est présent dans les extensions d'entrée de CRL, il doit être mis soit à unspecified, affiliationChanged, superseded ou cessationOfOperation. Dans ce cas, les jetons signés avec la clé correspondante seront considérés comme invalides, mais les jetons générés avant la date de révocation resteront valides. Quand l'extension reasonCode n'est pas présent dans la CRL, tous les jetons qui ont été signés avec la clé correspondante doivent être considérés comme invalides. Pour cette raison, il est recommandé d'utiliser l'extension reasonCode.

   2. Quand la clé privée TSA a été compromise, le certificat correspondant doit être révoqué. Dans ce cas, l'extension reasonCode peut être présent et dans ce cas doit être à keyCompromise. Tout jeton signé par le TSA utilisant cette clé privée ne peuvent plus être validés. Pour cette raison, il est impératif que la clé privée du TSA soit conservé en lieu sûr et contrôlé pour minimiser la possibilité d'être compromise. Dans le cas où la clé privée est compromise, un audit de tous les jetons générés par le TSA peut fournir un moyen de discriminer les jetons. 2 jetons d'horodatage de 2 TSA différents est une autre manière d'adresser ce problème.

   3. La clé de signature TSA doit être suffisamment longue pour une durée de vie confortable. Même si c'est le cas, la clé a une durée de vie définie. Donc, tout jeton signé par le TSA devrait être horodatées de nouveau (si des copies authentique des anciennes CRL sont disponibles) ou notarisé (s'il elle ne le sont pas) à une date ultérieur pour renouveler la confiance qui existe dans la signature du TSA. Les jetons d'horodatage peuvent également être conservés avec un "Evidence Recording Authority" pour maintenir ce trust.

   4. Une application client utilisant seulement un nonce et sans horloge locale devrait être concerné par la quantité de temp qu'il est prêt à attendre la réponse. Une attaque MITM peut introduire un délai. Donc, un TimeStampResp qui prend trop de temp devrait être considéré comme suspect. Vu que chaque méthode de transport spécifié dans ce document a différentes caractéristiques de délai, la durée considérée acceptable dépend du transport utilisé, ainsi que les facteurs environnementaux.

   5. Si différentes entités obtiennent des jetons d'horodatage sur le même objet en utilisant le même algorithme de hashage, ou une simple entité obtient plusieurs jetons sur le même objet, les jetons générés incluent le même message; en résultat, un observateur avec accès à ces jetons peut en déduire que l'horodatage réfère aux même données.

   6. Le replays délibérés ou par inadvertance pour les demandes incorporant le même algorithme de hashage et de valeur peut se produire. Les replays par inadvertance se produisent quand plus d'une copie de la même requête est envoyée au TSA à cause de problèmes réseau. Les replays délibérés se produisent via MITM. Pour détecter ces situations, de nombreuses techniques peuvent être utilisé. Utiliser un nonce permet toujours de détecter les replay, et est recommandé. Il est également possible d'utiliser une horloge local, et une fenêtre de temps durant laquelle le demandeur mémorise tous les hash envoyés . En reçevant une réponse, le demandeur s'assure que l'heure de la réponse est dans la fenêtre et qu'il y a une seule occurence de la valeur de hash dans cette fenêtre de temps.

APPENDIX A - attributs Time-stamp utilisant CMS

   Une des utilisations majeur de l'horodatage est d'horodater une signature pour prouver qu'une signature numérique a été créée avant une date donnée. Le certificat correspondant est révoqué, cela permet à un vérificateur de savoir si la signature a été créé avant ou après la date de révocation.

   Un endroit sensible où stocker un timestamp est dans une structure CMS comme un attribut non-signé. Cette appendice définis un attribut Signature Time-stamp qui peut être utilisé pour horodater une signature numérique.

Les identifiant d'objets suivants identifient cet attribut:
id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

La valeur de cet attribut a le type ASN.1 SignatureTimeStampToken:
SignatureTimeStampToken ::= TimeStampToken

   La valeur du champ messageImprint dans TimeStampToken doit être un hash de la aleur du champ signature dans SignerInfo pour le signedData à horodater.

APPENDIX 1 - Placer une signature à un point dans le temps

   On présent un exemple d'une utilisation possible de ce service d'horodatage généraliste. Il place une signature à un point dans le temps, depuis lequel les informations de status du certificat appropri(ex, CRL) doit être vérifié. Cette application est prévue pour être utilisée en conjonction avec des preuves générées en utilisant un mécanisme de signature numérique.

   Les signature peuvent seulement être vérifiées en accord avec une stratégie de non-répudiation. Cette stratégie peut être implicite ou explicite (ex, indiquée dans la preuve fournie par le signataire). La stratégie de non-répudiation peut spécifier, entre-autre, la période permise par un signataire pour déclarer la compromission d'un clé de signature utilisée pour la génération des signatures numérique. Donc une signature ne peut pas garantir d'être valide jusqu'à la fin de cette période.

   Pour vérifier une signature numérique, la technique basique suivante peut être utilisée:

A) Les informations d'horodatage doivent être obtenus juste après la production de la signature

        1) La signature est présentée au TSA. Le TSA retourne un TimeStampToken (TST).
        2) Le demandeur du service doit vérifier que le TimeStampToken est correct.

B) La validité de la signature numérique peut ainsi être vérifiée de la manière suivante:

        1) Le jeton d'horodatage lui-même doit être vérifié et qu'il s'applique à la signature du signataire
        2) La date indiquée par le TSA dans le TimeStampToken doit être retrouvée.
        3) Le certificat utilisé par le signataire doit être identifié et récupéré
        4) La date indiquée par le TSA doit être dans la période de validité du certificat du signataire
        5) Les informations de révocation sur ce certificat, à la date de l'opération d'horodatage, doit être récupéré
        6) Si le certificat est révoqué, la date de révocation doit être ultérieur à la date indiquée par le TSA.

   Si toutes ces conditions sont réussies, la signature numérique doit être déclarée comme valide.

APPENDIX C - Module ASN.1 utilisant la syntaxe 1988


PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
    
DEFINITIONS IMPLICIT TAGS ::=
    
BEGIN
    
-- EXPORTS ALL --
    
IMPORTS
Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} ;
    
-- Locally defined OIDs --
    
-- eContentType for a time-stamp token
    
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
    
-- 2.4.1
    
TimeStampReq ::= SEQUENCE {
    version INTEGER { v1(1) },
    messageImprint MessageImprint,
        --a hash algorithm OID and the hash value of the data to be time-stamped
    reqPolicy TSAPolicyId OPTIONAL,
    nonce INTEGER OPTIONAL,
    certReq BOOLEAN DEFAULT FALSE,
    extensions [0] IMPLICIT Extensions OPTIONAL }
    
MessageImprint ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    hashedMessage OCTET STRING }
    
TSAPolicyId ::= OBJECT IDENTIFIER
    
-- 2.4.2
    
TimeStampResp ::= SEQUENCE {
    status PKIStatusInfo,
    timeStampToken TimeStampToken OPTIONAL }
    
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL }
    
PKIStatus ::= INTEGER {
    granted (0),
        -- when the PKIStatus contains the value zero a TimeStampToken, as requested, is present.
    grantedWithMods (1),
        -- when the PKIStatus contains the value one a TimeStampToken, with modifications, is present.
    rejection (2),
    waiting (3),
    revocationWarning (4),
        -- this message contains a warning that a revocation is imminent
        revocationNotification (5)
-- notification that a revocation has occurred }
    
PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badRequest (2),
    badDataFormat (5),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17)
    systemFailure (25)
    
TimeStampToken ::= ContentInfo
    
TSTInfo ::= SEQUENCE {
    version INTEGER { v1(1) },
    policy TSAPolicyId,
    messageImprint MessageImprint,
        -- MUST have the same value as the similar field in TimeStampReq
    serialNumber INTEGER,
        -- Time-Stamping users MUST be ready to accommodate integers up to 160 bits.
    genTime GeneralizedTime,
    accuracy Accuracy OPTIONAL,
    ordering BOOLEAN DEFAULT FALSE,
    nonce INTEGER OPTIONAL,
        -- MUST be present if the similar field was present in TimeStampReq. In that case it MUST have the same value.
    tsa [0] GeneralName OPTIONAL,
    extensions [1] IMPLICIT Extensions OPTIONAL }

Accuracy ::= SEQUENCE {
    seconds INTEGER OPTIONAL,
    millis [0] INTEGER (1..999) OPTIONAL,
    micros [1] INTEGER (1..999) OPTIONAL }

END
^
10 mai 2016

htmlpdflatexmanmd




openca - ocspd.conf

openca - ocspd.conf

Fichier de configuration pour openca-ocspd

   Le fichier de configuration est divisé en sections, et est conforme à la syntaxe spécifiée dans openssl-config.

Exemple


[ ocspd ]
default_ocspd = OCSPD_default
    
[ OCSPD_default ]
    
dir = /usr/local/etc/ocspd
db = $dir/index.txt
md = sha1
    
ca_certificate = $dir/certs/cacert.pem
ocspd_certificate = $dir/certs/ocspd_cert.pem
ocspd_key = $dir/private/ocspd_key.pem
pidfile = $dir/ocspd.pid
    
user = ocspd
group = daemon
bind = *
port = 2560
max_childs_num = 5
max_req_size = 8192
    
request = ocsp_req
response = ocsp_response
    
dbms = dbms_ldap # Example using the LDAP for CRL retrivial
    
#dbms = dbms_file # Example using file for CRL
    
engine = HSM # ENGINE section
    
####################################################################
[ ocsp_req ]
default_keyfile = key.pem
    
####################################################################
[ ocsp_response ]
dir = /usr/local/etc/ocspd
ocsp_add_response_certs = $dir/certs/chain_certs.pem
ocsp_add_response_keyid = yes
next_update_days = 0
next_update_mins = 5
    
####################################################################
[ dbms_ldap ]
    
# It is possible to use an URI to identify a CRL and/or the CA certificate, the general format is:
# [protocol]://[user[:pwd]@]server[:port]/[path]
#
# where:
# protocol - specifies the protocol to be used, supported are
# file, ldap, http
# user - is the user for auth (meaningful only if ldap or
# http is used)
# pwd - password used for auth (meaningful only if ldap
# or http is used)
# port - port to connect to (meaningful only if ldap or
# http is used)
# path - complete path to the object (meaningful only if
# http is used)
#
# You can have the CRLs/CA certificates on a simple file
# crl_url = file:///usr/local/etc/ocspd/crl.pem
#
# You can retrieve the CRLs/CA certificates from a web server
# crl_urt = http://server/ca/cacert.der
#
# You can store the CRL into an LDAP server, simply
# store it in certificateRevocationList;binary attribute
#
# There are different way, all legal, to specify the CRL
# URL address:
# crl_url = ldap://user:pwd@ldap.server.org:389
# crl_url = ldap://ldap.server.org:389
crl_url = ldap://localhost
    
# The CRL entry DN is the DN to look for when retrieving the
# date from the LDAP server. Put here the complete DN (usually
# the DN of the CA's certificate).
crl_entry_dn = "email=email@address, cn=Certification Auth, \
o=Organization, c=IT"
    
####################################################################
[ dbms_file ]
    
# You can have the CRL on a simple file in PEM format
crl_url = file:///usr/local/etc/ocspd/crl.pem
    
[ HSM ]
# Hardware accelerators support via the ENGINE interface
engine_id = MyAccelerator
0.engine_pre = login:1:10:11:myPassword
# 0.engine_post = logout:1:10:11

default_ocspd Dans cette section du fichier de configuration sont placés les options utilisées par le répondeur, certains sont disponibles en utilisant les options de la ligne de commande.
db Spécifie la db où tout est concervé. Actuellement, le seul format fichier supporté est celui de openssl.
md Spécifie le hash à utiliser. Défaut: sha1
ca_certificate Chemin vers de certificat de la CA
ocspd_certificate Chemin vers le certificat utilisé par le répondeur
ocspd_key Chemin de la clé privée du certificat utilisé par le répondeur
pidfile fichier du pid du processus
user UID du processus
group GID du processus
bind Adresse d'écoute
port Port d'écoute
threads_num Nombre de threads qui devraient être créés au démarrage. plus le nombre est élevé, plus il peut gérer les fort trafics.
chroot_dir chroot d'application dans le répertoire spécifié
max_req_size Taille maximum de requête reçue. Au delà la requête est détruite. Généralement les requêtes font environ 200/300 octets
request section non utilisé actuellement
response section Ici sont conservés les options pour la construction des réponses
dbms Options pour la crl
ocsp_add_response_certs Chemin d'un fichier contentant les certificats à ajouter à la réponse (généralement toute la chaîne de certification).
ocsp_add_response_keyid Spécifie si l'id de clé est ajouté dans la réponse
next_update_days Nombre de jours jusqu'à la prochaine mise à jours.
next_update_mins idem pour la partie minutes. La réponse est valide pour days+mins
ca_url URI où le certificat de la CA est localisée. (file:// http:// ou ldap://)
crl_url URI où la crl est localisée (file:// http:// ou ldap://)
crl_entry_dn avec ldap, spécifie le dn où rechercher l'attribut certificateRevocationList
engine_id Spécifie l'id de l'engine
engine_pre, engine_post Paramètres d'initialisation du périphérique
^
10 mai 2016

htmlpdflatexmanmd




openca - ocspd

openca - ocspd

service OCSP

   openca-ocspd est un répondeur OCSP conforme à la rfc2560. Il peut être utilisé pour vérifier le status d'un certificat en utilisant les clients OCSP.

OPTIONS

-d Détache le processus principal du processus appelant
-p n Spécifie le port d'écoute. Défaut: 2560
-b address Spécifie l'adresse IP d'écoute. Défaut:_*
-c file Fichier de configuration. Défaut: /usr/local/etc/ocspd.conf
-md digest Spécifie le hash à utiliser pour générer les réponses. Défaut: sha1
-k passwd Spécifie le mot de passe utilisé pour charger la clé privée
-i passin Source du mot de passe de la clé
-engine id Spécifie un engine
-r chroot_dir chroot l'application dans le répertoire spécifié
-v Affiche des détails sur les opération effectuées
^
09 mai 2016

htmlpdflatexmanmd




rfc7299

rfc7299

OID pour le groupe de travail PKIX

Quand le groupe de travail PKIX a démarré, un arc OID a été alloué par l'IANA. Ce document décris les identifiants assignés dans cet arc, et établis les stratégies d'allocation pour tout assignement dans cet arc. l'arc OID pkix est :
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

Arcs OID subordonnés

   25 arcs OID subordonnés ont été utilisé, de 0 à 23 et 48. De plus, il y a 7 arcs subordonnée. Ils ont été assignés comme suit:

Identifiants de module id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
Extensions de certificat PKIX id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
Type de qualifiant de stratégie id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
Identifiant de clé étendue id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
Type d'information CMP id-it OBJECT IDENTIFIER ::= { id-pkix 4 }
Enregistrement CRMF id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
Contrôles d'enregistrement CRMF id-regCtrl OBJECT IDENTIFIER ::= { id-pkix 5 1 }
Informations d'enregistrement CRMF id-regInfo OBJECT IDENTIFIER ::= { id-pkix 5 2 }
Algorithmes id-alg OBJECT IDENTIFIER ::= { id-pkix 6 }
Contrôles CMC id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
Requêtes et réponses CMC GLA id-cmc-glaRR OBJECT IDENTIFIER ::= { id-pkix 7 99 }
Autres formes de nom id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
Attribut personnel id-pda OBJECT IDENTIFIER ::= { id-pkix 9 }
Attribut de certificat d'attributs id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
Déclarations de certificat qualifié id-qcs OBJECT IDENTIFIER ::= { id-pkix 11 }
Types de contenu CMC id-cct OBJECT IDENTIFIER ::= { id-pkix 12 }
OID pour test uniquement id-TEST OBJECT IDENTIFIER ::= { id-pkix 13 }
Stratégies de certificat id-cp OBJECT IDENTIFIER ::= { id-pkix 14 }
Type d'erreur CMC id-cet OBJECT IDENTIFIER ::= { id-pkix 15 }
Types d'information de révocation id-ri OBJECT IDENTIFIER ::= { id-pkix 16 }
Types de retour SCVP id-swb OBJECT IDENTIFIER ::= { id-pkix 18 }
Stratégies de validation SCVP id-svp OBJECT IDENTIFIER ::= { id-pkix 19 }
Erreurs de stratégie de validation de nom SCVP id-nvae OBJECT IDENTIFIER ::= { id-pkix 19 2 }
Erreurs de stratégie de validation de base SCVP id-bvae OBJECT IDENTIFIER ::= { id-pkix 19 3 }
Erreurs de stratégie de validation de nom distinct SCVP id-dnvae OBJECT IDENTIFIER ::= { id-pkix 19 4 }
Autres identifiants logotype id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
Langages de stratégie de certificat proxy id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
Rêgles de correspondance id-mr OBJECT IDENTIFIER ::= { id-pkix 22 }
Sémantiques d'identifiant de clé du sujet id-skis OBJECT IDENTIFIER ::= { id-pkix 23 }
Descripteurs d'accès id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
OCSP id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix 48 1 }

   L'IANA a mis à jours une table d'enregistrement et créé 33 tables additionnelles. Les mises à jours dans les nouvelles tables sont faites en accord avec la spécification définie dans la rfc5226.

1.3.6.1.5.5.7

Decimal Description References
------- ------------------------------------ ----------
0_______Module identifiers_____________________[RFC7299]
1_______PKIX certificate extensions____________[RFC7299]
2_______Policy qualifier types_________________[RFC7299]
3_______Extended key purpose identifiers_______[RFC7299]
4_______CMP information types__________________[RFC7299]
5_______CRMF registration______________________[RFC7299]
6_______Algorithms_____________________________[RFC7299]
7_______CMC controls___________________________[RFC7299]
8_______Other name forms_______________________[RFC7299]
9_______Personal data attribute________________[RFC7299]
10______Attribute certificate attributes_______[RFC7299]
11______Qualified certificate statements_______[RFC7299]
12______CMC content types______________________[RFC7299]
13______OIDs for TESTING ONLY__________________[RFC7299]
14______Certificate policies___________________[RFC7299]
15______CMC error types________________________[RFC7299]
16______Revocation information types___________[RFC7299]
17______SCVP check type________________________[RFC7299]
18______SCVP want back types___________________[RFC7299]
19______SCVP validation policies_______________[RFC7299]
20______Other logotype identifiers_____________[RFC7299]
21______Proxy certificate policy languages_____[RFC7299]
22______Matching rules_________________________[RFC7299]
23______Subject key identifier semantics_______[RFC7299]
48______Access descriptors_____________________[RFC7299]

1.3.6.1.5.5.7.0

Decimal Description References
------- ------------------------------- ---------------------
1________id-pkix1-explicit-88_____________[RFC2459]
2________id-pkix1-implicit-88_____________[RFC2459]
3________id-pkix1-explicit-93_____________[RFC2459]
4________id-pkix1-implicit-93_____________[RFC2459]
5________id-mod-crmf______________________[RFC2511]
6________id-mod-cmc_______________________[RFC2797]
7________id-mod-kea-profile-88____________[RFC2528]
8________id-mod-kea-profile-93____________[RFC2528]
9________id-mod-cmp_______________________[RFC2510]
10_______id-mod-qualified-cert-88_________[RFC3039]
11_______id-mod-qualified-cert-93_________[RFC3039]
12_______id-mod-attribute-cert____________[RFC3281]
13_______id-mod-tsp_______________________[RFC3161]
14_______id-mod-ocsp______________________[RFC3029]
15_______id-mod-dvcs______________________[RFC3029]
16_______id-mod-cmp2000___________________[RFC4210]
17_______id-mod-pkix1-algorithms__________[RFC3279]
18_______id-mod-pkix1-explicit____________[RFC3280]
19_______id-mod-pkix1-implicit____________[RFC3280]
20_______id-mod-user-group________________Reserved and Obsolete
21_______id-mod-scvp______________________[RFC5055]
22_______id-mod-logotype__________________[RFC3709]
23_______id-mod-cmc2002___________________[RFC5272]
24_______id-mod-wlan-extns________________[RFC3770]
25_______id-mod-proxy-cert-extns__________[RFC3820]
26_______id-mod-ac-policies_______________[RFC4476]
27_______id-mod-warranty-extn_____________[RFC4059]
28_______id-mod-perm-id-88________________[RFC4043]
29_______id-mod-perm-id-93________________[RFC4043]
30_______id-mod-ip-addr-and-as-ident______[RFC3779]
31_______id-mod-qualified-cert____________[RFC3739]
32_______id-mod-crmf2003__________________Reserved and Obsolete
33_______id-mod-pkix1-rsa-pkalgs__________[RFC4055]
34_______id-mod-cert-bundle_______________[RFC4306]
35_______id-mod-qualified-cert-97_________[RFC3739]
36_______id-mod-crmf2005__________________[RFC4210]
37_______id-mod-wlan-extns2005____________[RFC4334]
38_______id-mod-sim2005___________________[RFC4683]
39_______id-mod-dns-srv-name-88___________[RFC4985]
40_______id-mod-dns-srv-name-93___________[RFC4985]
41_______id-mod-cmsContentConstr-88_______[RFC6010]
42_______id-mod-cmsContentConstr-93_______[RFC6010]
43_______id-mod-pkixCommon________________Reserved and Obsolete
44_______id-mod-pkixOtherCerts____________[RFC5697]
45_______id-mod-pkix1-algorithms2008______[RFC5480]
46_______id-mod-clearanceConstraints______[RFC5913]
47_______id-mod-attribute-cert-02_________[RFC5912]
48_______id-mod-ocsp-02___________________[RFC5912]
49_______id-mod-v1AttrCert-02_____________[RFC5912]
50_______id-mod-cmp2000-02________________[RFC5912]
51_______id-mod-pkix1-explicit-02_________[RFC5912]
52_______id-mod-scvp-02___________________[RFC5912]
53_______id-mod-cmc2002-02________________[RFC5912]
54_______id-mod-pkix1-rsa-pkalgs-02_______[RFC5912]
55_______id-mod-crmf2005-02_______________[RFC5912]
56_______id-mod-pkix1-algorithms2008-02___[RFC5912]
57_______id-mod-pkixCommon-02_____________[RFC5912]
58_______id-mod-algorithmInformation-02___[RFC5912]
59_______id-mod-pkix1-implicit-02_________[RFC5912]
60_______id-mod-pkix1-x400address-02______[RFC5912]
61_______id-mod-attribute-cert-v2_________[RFC5755]
62_______id-mod-sip-domain-extns2007______[RFC5924]
63_______id-mod-cms-otherRIs-2009-88______[RFC5940]
64_______id-mod-cms-otherRIs-2009-93______[RFC5940]
65_______id-mod-ecprivatekey______________[RFC5915]
66_______id-mod-ocsp-agility-2009-93______[RFC6277]
67_______id-mod-ocsp-agility-2009-88______[RFC6277]
68_______id-mod-logotype-certimage________[RFC6170]
69_______id-mod-pkcs10-2009_______________[RFC5912]
70_______id-mod-dns-resource-record_______[Abley]
71_______id-mod-send-cert-extns___________[RFC6494]
72_______id-mod-ip-addr-and-as-ident-2____[RFC6268]
73_______id-mod-wlan-extns-2______________[RFC6268]
74_______id-mod-hmac______________________[RFC6268]
75_______id-mod-enrollMsgSyntax-2011-88___[RFC6402] [Err3860]
76_______id-mod-enrollMsgSyntax-2011-08___[RFC6402]
77_______id-mod-pubKeySMIMECaps-88________[RFC6664]
78_______id-mod-pubKeySMIMECaps-08________[RFC6664]
79_______id-mod-dhSign-2012-88____________[RFC6955]
80_______id-mod-dhSign-2012-08____________[RFC6955]
81_______id-mod-ocsp-2013-88______________[RFC6960]
82_______id-mod-ocsp-2013-08______________[RFC6960]
83_______id-mod-TEST-certPolicies_________[RFC7229]
84_______id-mod-bgpsec-eku________________[BGPSEC]

1.3.6.1.5.5.7.1

Decimal Description References
------- ------------------------------ ---------------------
_______1________id-pe-authorityInfoAccess_______[RFC2459]
_______2________id-pe-biometricInfo_____________[RFC3039]
_______3________id-pe-qcStatements______________[RFC3039]
_______4________id-pe-ac-auditIdentity__________[RFC3281]
_______5________id-pe-ac-targeting______________Reserved and Obsolete
_______6________id-pe-aaControls________________[RFC3281]
_______7________id-pe-ipAddrBlocks______________[RFC3779]
_______8________id-pe-autonomousSysIds__________[RFC3779]
_______9________id-pe-sbgp-routerIdentifier_____Reserved and Obsolete
_______10_______id-pe-ac-proxying_______________[RFC3281]
_______11_______id-pe-subjectInfoAccess_________[RFC3280]
_______12_______id-pe-logotype__________________[RFC3709]
_______13_______id-pe-wlanSSID__________________[RFC4334]
_______14_______id-pe-proxyCertInfo_____________[RFC3820]
_______15_______id-pe-acPolicies________________[RFC4476]
_______16_______id-pe-warranty__________________[RFC4059]
_______17_______id-pe-sim_______________________Reserved and Obsolete
_______18_______id-pe-cmsContentConstraints_____[RFC6010]
_______19_______id-pe-otherCerts________________[RFC5697]
_______20_______id-pe-wrappedApexContinKey______[RFC5934]
_______21_______id-pe-clearanceConstraints______[RFC5913]
_______22_______id-pe-skiSemantics______________Reserved and Obsolete
_______23_______id-pe-nsa_______________________[RFC7169]

1.3.6.1.5.5.7.2

Decimal Description References
------- ------------------------------ ---------------------
1________id-qt-cps_______________________[RFC2459]
2________id-qt-unotice___________________[RFC2459]
3________id-qt-textNotice________________Reserved and Obsolete
4________id-qt-acps______________________[RFC4476]
5________id-qt-acunotice_________________[RFC4476]

1.3.6.1.5.5.7.3

Decimal Description References
------- ------------------------------ ---------------------
1________id-kp-serverAuth________________[RFC2459]
2________id-kp-clientAuth________________[RFC2459]
3________id-kp-codeSigning_______________[RFC2459]
4________id-kp-emailProtection___________[RFC2459]
5________id-kp-ipsecEndSystem____________Reserved and Obsolete
6________id-kp-ipsecTunnel_______________Reserved and Obsolete
7________id-kp-ipsecUser_________________Reserved and Obsolete
8________id-kp-timeStamping______________[RFC2459]
9________id-kp-OCSPSigning_______________[RFC2560]
10_______id-kp-dvcs______________________[RFC3029]
11_______id-kp-sbgpCertAAServerAuth______Reserved and Obsolete
12_______id-kp-scvp-responder____________Reserved and Obsolete
13_______id-kp-eapOverPPP________________[RFC4334]
14_______id-kp-eapOverLAN________________[RFC4334]
15_______id-kp-scvpServer________________[RFC5055]
16_______id-kp-scvpClient________________[RFC5055]
17_______id-kp-ipsecIKE__________________[RFC4945]
18_______id-kp-capwapAC__________________[RFC5415]
19_______id-kp-capwapWTP_________________[RFC5415]
20_______id-kp-sipDomain_________________[RFC5924]
21_______id-kp-secureShellClient_________[RFC6187]
22_______id-kp-secureShellServer_________[RFC6187]
23_______id-kp-sendRouter________________[RFC6494]
24_______id-kp-sendProxiedRouter_________[RFC6494]
25_______id-kp-sendOwner_________________[RFC6494]
26_______id-kp-sendProxiedOwner__________[RFC6494]
27_______id-kp-cmcCA_____________________[RFC6402]
28_______id-kp-cmcRA_____________________[RFC6402]
29_______id-kp-cmcArchive________________[RFC6402]
30_______id-kp-bgpsec-router_____________[BGPSEC]

1.3.6.1.5.5.7.4

Decimal Description References
------- ------------------------------ ---------------------
1________id-it-caProtEncCert_____________[RFC2510]
2________id-it-signKeyPairTypes__________[RFC2510]
3________id-it-encKeyPairTypes___________[RFC2510]
4________id-it-preferredSymmAlg__________[RFC2510]
5________id-it-caKeyUpdateInfo___________[RFC2510]
6________id-it-currentCRL________________[RFC2510]
7________id-it-unsupportedOIDs___________[RFC4210]
8________id-it-subscriptionRequest_______Reserved and Obsolete
9________id-it-subscriptionResponse______Reserved and Obsolete
10_______id-it-keyPairParamReq___________[RFC4210]
11_______id-it-keyPairParamRep___________[RFC4210]
12_______id-it-revPassphrase_____________[RFC4210]
13_______id-it-implicitConfirm___________[RFC4210]
14_______id-it-confirmWaitTime___________[RFC4210]
15_______id-it-origPKIMessage____________[RFC4210]
16_______id-it-suppLangTags______________[RFC4210]

1.3.6.1.5.5.7.5

Decimal Description References
------- ------------------------------ ---------------------
1________id-regCtrl______________________[RFC2511]
2________id-regInfo______________________[RFC2511]
3________id-regEPEPSI____________________[RFC4683]

1.3.6.1.5.5.7.5.1

Decimal Description References
------- ------------------------------ ---------------------
1________id-regCtrl-regToken_____________[RFC2511]
2________id-regCtrl-authenticator________[RFC2511]
3________id-regCtrl-pkiPublicationInfo___[RFC2511]
4________id-regCtrl-pkiArchiveOptions____[RFC2511]
5________id-regCtrl-oldCertID____________[RFC2511]
6________id-regCtrl-protocolEncrKey______[RFC2511]
7________id-regCtrl-altCertTemplate______[RFC4210]
8________id-regCtrl-wtlsTemplate_________Reserved and Obsolete
9________id-regCtrl-regTokenUTF8_________Reserved and Obsolete
10_______id-regCtrl-authenticatorUTF8____Reserved and Obsolete

1.3.6.1.5.5.7.5.2

Decimal Description References
------- ------------------------------ ---------------------
1________id-regInfo-utf8Pairs____________[RFC2511]
2________id-regInfo-certReq______________[RFC2511]

1.3.6.1.5.5.7.6

Decimal Description References
------- ------------------------------ ---------------------
1________id-alg-des40________________________________Reserved and Obsolete
2________id-alg-noSignature__________________________[RFC2797]
3________id-alg-dh-sig-hmac-sha1_____________________[RFC2875]
4________id-alg-dhPop-sha1___________________________[RFC2875]
5________id-alg-dhPop-sha224_________________________[RFC6955]
6________id-alg-dhPop-sha256_________________________[RFC6955]
7________id-alg-dhPop-sha384_________________________[RFC6955]
8________id-alg-dhPop-sha512_________________________[RFC6955]
15_______id-alg-dhPop-static-sha224-hmac-sha224______[RFC6955]
16_______id-alg-dhPop-static-sha256-hmac-sha256______[RFC6955]
17_______id-alg-dhPop-static-sha384-hmac-sha384______[RFC6955]
18_______id-alg-dhPop-static-sha512-hmac-sha512______[RFC6955]
25_______id-alg-ecdhPop-static-sha224-hmac-sha224____[RFC6955]
26_______id-alg-ecdhPop-static-sha256-hmac-sha256____[RFC6955]
27_______id-alg-ecdhPop-static-sha384-hmac-sha384____[RFC6955]
28_______id-alg-ecdhPop-static-sha512-hmac-sha512____[RFC6955]
    
Note: id-alg-dhPop-sha1 est également appelé id-alg-dh-pop.
Note: id-alg-dh-sig-hmac-sha1 est également appelé id-alg-dhPop-static-sha1-hmac-sha1 et id-dhPop-static-hmac-sha1.

1.3.6.1.5.5.7.7

Decimal Description References
------- ------------------------------ ---------------------
1________id-cmc-statusInfo_______________[RFC2797]
2________id-cmc-identification___________[RFC2797]
3________id-cmc-identityProof____________[RFC2797]
4________id-cmc-dataReturn_______________[RFC2797]
5________id-cmc-transactionId____________[RFC2797]
6________id-cmc-senderNonce______________[RFC2797]
7________id-cmc-recipientNonce___________[RFC2797]
8________id-cmc-addExtensions____________[RFC2797]
9________id-cmc-encryptedPOP_____________[RFC2797]
10_______id-cmc-decryptedPOP_____________[RFC2797]
11_______id-cmc-lraPOPWitness____________[RFC2797]
15_______id-cmc-getCert__________________[RFC2797]
16_______id-cmc-getCRL___________________[RFC2797]
17_______id-cmc-revokeRequest____________[RFC2797]
18_______id-cmc-regInfo__________________[RFC2797]
19_______id-cmc-responseInfo_____________[RFC2797]
21_______id-cmc-queryPending_____________[RFC2797]
22_______id-cmc-popLinkRandom____________[RFC2797]
23_______id-cmc-popLinkWitness___________[RFC2797]
24_______id-cmc-confirmCertAcceptance____[RFC2797]
25_______id-cmc-statusInfoV2_____________[RFC5272]
26_______id-cmc-trustedAnchors___________[RFC5272]
27_______id-cmc-authData_________________[RFC5272]
28_______id-cmc-batchRequests____________[RFC5272]
29_______id-cmc-batchResponses___________[RFC5272]
30_______id-cmc-publishCert______________[RFC5272]
31_______id-cmc-modCertTemplate__________[RFC5272]
32_______id-cmc-controlProcessed_________[RFC5272]
33_______id-cmc-popLinkWitnessV2_________[RFC5272]
34_______id-cmc-identityProofV2__________[RFC5272]
35_______id-cmc-raIdentityWitness________[RFC6402]
36_______id-cmc-changeSubjectName________[RFC6402]
37_______id-cmc-responseBody_____________[RFC6402]
99_______id-cmc-glaRR____________________[RFC5275]
    
Note: id-cmc-statusInfo est également appelé id-cmc-cMCStatusInfo.

1.3.6.1.5.5.7.7.99

Decimal Description References
------- ------------------------------ ---------------------
1________id-cmc-gla-skdAlgRequest________[RFC5275]
2________id-cmc-gla-skdAlgResponse_______[RFC5275]

1.3.6.1.5.5.7.8

Decimal Description References
------- ------------------------------ ---------------------
1________id-on-personalData______________Reserved and Obsolete
2________id-on-userGroup_________________Reserved and Obsolete
3________id-on-permanentIdentifier_______[RFC4043]
4________id-on-hardwareModuleName________[RFC4108]
5________id-on-xmppAddr__________________[RFC3920]
6________id-on-SIM_______________________[RFC4683]
7________id-on-dnsSRV____________________[RFC4985]

1.3.6.1.5.5.7.9

Decimal Description References
------- ------------------------------ ---------------------
1________id-pda-dateOfBirth______________[RFC3039]
2________id-pda-placeOfBirth_____________[RFC3039]
3________id-pda-gender___________________[RFC3039]
4________id-pda-countryOfCitizenship_____[RFC3039]
5________id-pda-countryOfResidence_______[RFC3039]

1.3.6.1.5.5.7.10

Decimal Description References
------- ------------------------------ ---------------------
1________id-aca-authenticationInfo_______[RFC3281]
2________id-aca-accessIdentity___________[RFC3281]
3________id-aca-chargingIdentity_________[RFC3281]
4________id-aca-group____________________[RFC3281]
5________id-aca-role_____________________Reserved and Obsolete
6________id-aca-encAttrs_________________[RFC3281]
7________id-aca-wlanSSID_________________[RFC4334]

1.3.6.1.5.5.7.11

Decimal Description References
------- ------------------------------ ---------------------
1________id-qcs-pkixQCSyntax-v1__________[RFC3039]
2________id-qcs-pkixQCSyntax-v2__________[RFC3739]

1.3.6.1.5.5.7.12

Decimal Description References
------- ------------------------------ ---------------------
1________id-cct-crs______________________Reserved and Obsolete
2________id-cct-PKIData__________________[RFC2797]
3________id-cct-PKIResponse______________[RFC2797]

1.3.6.1.5.5.7.13

Decimal Description References
------- ------------------------------ ---------------------
1________id-TEST-certPolicyOne___________[RFC7229]
2________id-TEST-certPolicyTwo___________[RFC7229]
3________id-TEST-certPolicyThree_________[RFC7229]
4________id-TEST-certPolicyFour__________[RFC7229]
5________id-TEST-certPolicyFive__________[RFC7229]
6________id-TEST-certPolicySix___________[RFC7229]
7________id-TEST-certPolicySeven_________[RFC7229]
8________id-TEST-certPolicyEight_________[RFC7229]

1.3.6.1.5.5.7.14

Decimal Description References
------- ------------------------------ ---------------------
1________id-cp-sbgpCertificatePolicy_____Reserved and Obsolete
2________id-cp-ipAddr-asNumber___________[RFC6484]

1.3.6.1.5.5.7.15

Decimal Description References
------- ------------------------------ ---------------------
1________id-cet-skdFailInfo______________[RFC5275]

1.3.6.1.5.5.7.16

Decimal Description References
------- ------------------------------ ---------------------
1________id-ri-crl_______________________[RFC5940]
2________id-ri-ocsp-response_____________[RFC5940]
3________id-ri-delta-crl_________________[RFC5940]
4________id-ri-scvp______________________[RFC5940]

1.3.6.1.5.5.7.17

Decimal Description References
------- ------------------------------------------------------ ---------------------
1________id-stc-build-pkc-path___________________________________[RFC5055]
2________id-stc-build-valid-pkc-path_____________________________[RFC5055]
3________id-stc-build-status-checked-pkc-path____________________[RFC5055]
4________id-stc-build-aa-path____________________________________[RFC5055]
5________id-stc-build-valid-aa-path______________________________[RFC5055]
6________id-stc-build-status-checked-aa-path_____________________[RFC5055]
7________id-stc-status-check-ac-and-build-status-checked-aa-path_[RFC5055]

1.3.6.1.5.5.7.18

Decimal Description References
------- ------------------------------ ---------------------
1________id-swb-pkc-best-cert-path_______[RFC5055]
2________id-swb-pkc-revocation-info______[RFC5055]
3________id-swb-pkc-cert-status__________Reserved and Obsolete
4________id-swb-pkc-public-key-info______[RFC5055]
5________id-swb-aa-cert-path_____________[RFC5055]
6________id-swb-aa-revocation-info_______[RFC5055]
7________id-swb-ac-revocation-info_______[RFC5055]
8________id-swb-ac-cert-status___________Reserved and Obsolete
9________id-swb-relayed-responses________[RFC5055]
10_______id-swb-pkc-cert_________________[RFC5055]
11_______id-swb-ac-cert__________________[RFC5055]
12_______id-swb-pkc-all-cert-paths_______[RFC5055]
13_______id-swb-pkc-ee-revocation-info___[RFC5055]
14_______id-swb-pkc-CAs-revocation-info__[RFC5055]
15_______id-swb-partial-cert-path________[RFC5276]
16_______id-swb-ers-pkc-cert_____________[RFC5276]
17_______id-swb-ers-best-cert-path_______[RFC5276]
18_______id-swb-ers-partial-cert-path____[RFC5276]
19_______id-swb-ers-revocation-info______[RFC5276]
20_______id-swb-ers-all__________________[RFC5276]

1.3.6.1.5.5.7.19

Decimal Description References
------- ------------------------------ ----------
1________id-svp-defaultValPolicy_________[RFC5055]
2________id-svp-nameValAlg_______________[RFC5055]
3________id-svp-basicValAlg______________[RFC5055]
4________id-svp-dnValAlg_________________[RFC5055]

1.3.6.1.5.5.7.19.2

Decimal Description References
------- ------------------------------ ----------
1________id-nvae-name-mismatch___________[RFC5055]
2________id-nvae-no-name_________________[RFC5055]
3________id-nvae-unknown-alg_____________[RFC5055]
4________id-nvae-bad-name________________[RFC5055]
5________id-nvae-bad-name-type___________[RFC5055]
6________id-nvae-mixed-names_____________[RFC5055]

1.3.6.1.5.5.7.19.3

Decimal Description References
------- ------------------------------ ---------------------
1________id-bvae-expired_________________[RFC5055]
2________id-bvae-not-yet-valid___________[RFC5055]
3________id-bvae-wrongTrustAnchor________[RFC5055]
4________id-bvae-noValidCertPath_________[RFC5055]
5________id-bvae-revoked_________________[RFC5055]
9________id-bvae-invalidKeyPurpose_______[RFC5055]
10_______id-bvae-invalidKeyUsage_________[RFC5055]
11_______id-bvae-invalidCertPolicy_______[RFC5055]
12_______id-bvae-invalidName_____________Reserved and Obsolete
13_______id-bvae-invalidEntity___________Reserved and Obsolete
14_______id-bvae-invalidPathDepth________Reserved and Obsolete

1.3.6.1.5.5.7.20

Decimal Description Reference
------- ------------------------------ ---------
1________id-logo-loyalty_________________[RFC3709]
2________id-logo-background______________[RFC3709]
3________id-logo-certImage_______________[RFC6170]

1.3.6.1.5.5.7.21

Decimal Description Reference
------- ------------------------------ ---------
0________id-ppl-anyLanguage______________[RFC3820]
1________id-ppl-inheritAll_______________[RFC3820]
2________id-ppl-independent______________[RFC3820]

1.3.6.1.5.5.7.22

Decimal Description References
------- ------------------------------ ---------------------
1________id-mr-pkix-alphanum-ids_________Reserved and Obsolete

1.3.6.1.5.5.7.23

Decimal Description References
------- ------------------------------ ---------------------
1________id-skis-keyHash_________________Reserved and Obsolete
2________id-skis-4BitKeyHash_____________Reserved and Obsolete
3________id-skis-keyInfoHash_____________Reserved and Obsolete

1.3.6.1.5.5.7.48

Decimal Description References
------- ------------------------------ ---------------------
1________id-ad-ocsp______________________[RFC2459]
2________id-ad-caIssuers_________________[RFC2459]
3________id-ad-timestamping______________[RFC3161]
4________id-ad-dvcs______________________[RFC3029]
5________id-ad-caRepository______________[RFC3280]
6________id-ad-http-certs________________[RFC4387]
7________id-ad-http-crls_________________[RFC4387]
8________id-ad-xkms______________________Reserved and Obsolete
9________id-ad-signedObjectRepository____Reserved and Obsolete
10_______id-ad-rpkiManifest______________[RFC6487]
11_______id-ad-signedObject______________[RFC6487]
12_______id-ad-cmc_______________________[RFC6402]

1.3.6.1.5.5.7.48.1

Decimal Description References
------- ------------------------------ ----------
1________id-pkix-ocsp-basic______________[RFC2560]
2________id-pkix-ocsp-nonce______________[RFC2560]
3________id-pkix-ocsp-crl________________[RFC2560]
4________id-pkix-ocsp-response___________[RFC2560]
5________id-pkix-ocsp-nocheck____________[RFC2560]
6________id-pkix-ocsp-archive-cutoff_____[RFC2560]
7________id-pkix-ocsp-service-locator____[RFC2560]
8________id-pkix-ocsp-pref-sig-algs______[RFC6277]
9________id-pkix-ocsp-extended-revoke____[RFC6960]

^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - dhparam

OpenSSL - dhparam

Génération et manipulation de paramètre DH

OPTIONS

-inform DER|PEM Format du fichier d'entrée
-outform DER|PEM Format du fichier de sortie
-in filename Fichier d'entrée
-out filename Fichier de sortie
-dsaparam Si spécifié, les paramètres DSA sont lus ou créé au lieu de paramètres DH; ils sont convertis au format DH. Sinon, les premiers 'fort' seront utilisé pour la génération de paramètres DH.
-check Vérifie si les paramètres sont valides
-2, -5 Générateur à utiliser. Si présent, le fichier d'entrée est ignoré et les paramètres sont générés. Défaut: 2
-rand file(s) Fichiers contenant des données aléatoires utilisée pour le générateur de nombre aléatoire, ou un socket EGD.
numbits Spécifie le nombre de bit à utiliser. Doit être la dernière option. Défaut: 2048
-noout Inhibe la sortie de la version encodée des paramètres
-text Affiche les paramètres DH au format lisible
-C Convertis les paramètres en code C. Les paramètres peuvent ainsi être chargés en appelant get_dhNNNN()
-engine id dhparam va tenter d'obtenir une référence fonctionnelle du moteur spécifié.

Notes

   Le programme dhparam combine les fonctionnalités des programmes dh et gendh dans les versions précédentes de OpenSSL. Les programmes dh et gendh sont retenus pour d'autres utilisations dans le future.

Les paramètres DH au format PEM utilisent les en-tête et pied de page suivant:
-----BEGIN DH PARAMETERS-----
-----END DH PARAMETERS-----

   Openssl supporte actuellement l'ancien PKCS#3 DH, pas le nouveau X9.42 DH.
^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - pkcs8

OpenSSL - pkcs8

Outil de conversion de clé privée au format pkcs#8

   Cette commande traite les clé privées au format pkcs#8. Elle peut gérer le format PrivateKeyInfo et EncryptedPrivateKeyInfo avec divers algorithmes PKCS#5 (1.5 et 2.0) et PKCS#12.

OPTIONS

-topk8 Normallement une clé privée PKCS#8 est attendue en entrée et un format de clé privée traditionnel est écris. Cette option inverse la situation
-inform DER|PEM Spécifie le format d'entrée
-outform DER|PEM Spécifie le format de sortie
-passing arg Source du mot de passe du fichier d'entrée
-out filename Fichier de sortie
-passout arg source du mot de passe du fichier de sortie
-iter count En créant un nouveau conteneur PKCS#8, utilise le nombre d'itérations donné sur le mot de passe pour dériver la clé de chiffrement.
-nocrypt Les clé PKCS#8 générées sont normallement des structures EncryptedPrivateKeyInfo. Cette option créé des structure PrivateKeyInfo.
-2 alg Active l'utilisation des algorithmes PKCS#5 v2.0. Normalement les clés privées PKCS#8 sont chiffrées avec un mot de passe basé sur l'algorithme de chiffrement pbeWithMD5AndDES-CBC qui utilise DES 56-bits. PKCS#5 v2.0 permet d'utiliser des algorithmes tel que 3DES 168bits, ou RC2 128bits.
-v2prf alg Définis l'algorithme PRF à utiliser avec PKCS#5 v2.0. Une valeur typique est hmacWithSHA256
-v1 alg Définis l'algorithme PKCS#5 v1.5 ou PKCS#12 à utiliser.
-nooct Génère des clé privées RSA dans un format cassé que certains logiciels utilisent
-embed Génère des clé DSA dans un format cassé.
-nsdb Génère des clé DSA dans un format cassé compatible avec les base de clé privée Netscape.
-engine id pkcs8 va tenter d'obtenir une référence fonctionnelle du moteur spécifié.
-scrypt Utilise l'algorithme scrypt pour le chiffrement de la clé privée en utilisant les paramètres par défaut. Actuellement N=16384, r=8 et p=1 et AES en mode CBC avec une clé 256 bits. Ces paramètres peuvent être modifiés avec -scrypt_N, -scrypt_r, -scrypt_p et -v2

Notes

Le format chiffré des fichiers PKCS#8 encodés PEM utilisent les en-tête et fin suivant:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

La version non-chiffrée:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

   Les clé privées chiffrées en utilisant PKCS#5 v2.0 et un compteur d'itération élevé sont plus sécurisés que ceux chiffrés en utilisant les formats compatible SSLeay traditionnels. Le chiffrement par défaut est seulement de 56bits parce que c'est le chiffrement le plus courant dans les implémentations supportant PKCS#8.

   Certains logiciels peuvent utiliser des algorithmes de chiffrement basé sur mot de passe PKCS#12 avec des clés privées au format PKCS#8: ils sont gérés automatiquement mais il n'y a pas d'option pour les produire.

   Il est possible d'écrire des clé privée encodées DER au format PKCS#8 parce que les détails de chiffrement sont inclus au niveau ASN1 alors que le format traditionnel les inclus au niveau PEM.

Algorithmes PKCS#5 v1.5 et PKCS#12

   Divers algorithmes peuvent être utilisés avec l'option -v1, incluant PKCS#5 v1.5 et PKCS#12:

PBE-MD2-DES PBE-MD5-DES Ces algorithmes sont inclus dans la spécification PKCS#5 v1.5. Ils offrent une protection 56-bits vu qu'ils utilisent DES
PBE-SHA1-RC2-64 PBE-MD2-RC2-64 PBE-MD5-RC2-64 PBE-SHA1-DES Ces algorithmes ne sont pas mentionnés dans la spécification PKCS#5 v1.5 mais utilisent le même algorithme de dérivation de clé et sont supportés par certains logiciels. Ils sont mentionnés dans PKCS#5 v2.0. Ils utilisent soit rs2 64bits, ou DES 56bits
PBE-SHA1-RC4-128 PBE-SHA1-RC4-40 PBE-SHA1-3DES PBE-SHA1-2DES PBE-SHA1-RC2-128 PBE-SHA1-RC2-40 Ces algorithems utilisent l'algorithme de chiffrement de mot de passe PKCS#12 et utilisent 3DES ou rc2 128bits.

Exemples

Convertir une forme privée traditionnelle en PKCS#5 v2.0 avec 3DES
openssl pkcs8 -in key.pem -topk8 -v2 des3 -out enckey.pem
Convertir un forme privée traditionnelle en PKCS#5 v2.0 avec AES 256 en mode CBC et hmacWithSHA256 PRF
openssl pkcs8 -in key.pem -topk8 -v2 aes-256-cbc -v2prf hmacWithSHA256 -out enckey.pem
Convertir une clé privée en PKCS#8 utilisant PKCS#5 1.5 (DES)
openssl pkcs8 -in key.pem -topk8 -out enckey.pem
Convertir un clé privée en PKCS#8 en utilisant un algorithme compatible PKCS#5 1.5 (DES)
openssl pkcs8 -in key.pem -topk8 -out enckey.pem -v1 PBE-SHA1-3DES
Lire une clé privée PKCS#8 DER non-chiffré
openssl pkcs8 -inform DER -nocrypt -in key.der -out key.pem
Convertir une clé privée depuis un format PKCS#8 dans un format traditionnel
openssl pkcs8 -in pk8.pem -out key.pem
Convertir une clé privée au format PKCS#8, la chiffrer avec AES-256 et un million d'itération
openssl pkcs8 -in raw.pem -topk8 -v2 aes-256-cbc -iter 1000000 -out pk8.pem

Standards

   Le format des clé privée DSA PKCS#8 (et d'autres) ne sont pas bien documentés: c'est caché dans PKCS#11 v2.01, section 11.9. Openssl se conforme à ce standard.
^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - engine

OpenSSL - engine

Trouver et charger les engines

   La commande engine est utilisée pour voir le status et les capacités des engines spécifiés. Les engines peuvent être spécifiés avant ou après tous les autres flags de la ligne de commande.

OPTIONS

-v -vv -vvv -vvvv -v liste les commandes de contrôle temps-réel, -vv ajoute une description pour chaque commande, -vvv ajoute les flags d'entrée, et -vvvv ajoute les flags d'entrée internes
-c Liste les capacités de chaque engine
-t Teste si chaque engine spécifié est disponible, et affiche la réponse
-tt Affiche une erreur pour un engine non-disponible
-pre command=item -post command Configuration en ligne de commande des engines. -pre est donné à l'engine avec qu'il soit chargé et -post est donné une fois chargé.

Exemple

Pour lister toutes les commandes disponibles d'un engine dynamique
openssl engine -t -tt -vvvv dynamic
Pour lister les capacités de l'engine rsax
openssl engine -c
^
08 mai 2016

htmlpdflatexmanmd




OpenSSL - config

OpenSSL - config

Fichers de configuration de la librairie CONF

   La librairie CONF openssl peut être utilisée pour lire les fichiers de configuration. Elle est utilisée pour le fichier de configuration maître openssl.cnf et dans d'autres endroits comme dans les fichiers SPKAC et les fichiers d'extensions de certificat pour l'utilitaire x509. Les application openssl peuvent également utiliser la librairie CONF pour leur propre utilisation.

   Un fichier de configuration est divisé en nombre de sections. Chaque section commence avec une ligne [ section_name ] et se termine quand une nouvelle section commence.

   La première section d'un fichier de configuration est spécial et est réferré à la section par défaut qui est généralement non nommée. Quand un nom est recherché il est d'abord recherché dans une section nommée, puis dans la section par défaut.

   L'environnement est mappé en une section appelée ENV. Chaque section consiste d'un nombre de paire nom=valeur.

   La valeur peut être étendue en utilisant la forme $var ou ${var}, qui substitue la valeur de la variable dans la section courante. Il est également possible de substituer une valeur d'une autre section en utilisant la syntaxe $section::name ou ${section::name}. En utilisant la forme $ENV::name les variables d'environnement peuvent être substituées. Il est également possible d'assigner des valeurs aux variables d'environnement en utilisant le nom ENV::name, cela fonctionne si le programme recherche des variables d'environnement en utilisant la librairie CONF au lieu d'appeler getenv() directement.

Configuration de la librairie openssl

   Les application peuvent configurer automatiquement certains aspects d'openssl en utilisant le fichier de configuration maître, ou optionnellement un fichier de configuration alternatif. L'utilitaire openssl inclus cette fonctionnalité; toute sous-commande utilise le fichier de configuration maître sauf si une option est utilisée dans la sous commande pour utiliser un fichier de configuration alternatif.

   Pour activer la configuration de librairie la section par défaut doit contenir la ligne appropriée qui pointe vers la section de configuration principale. Le nom par défaut est openssl_conf qui est utilisé par l'utilitaire openssl. D'autres applications peuvent utiliser un nom alternatif

La section de configuration devrait consister en un jeu de nom=valeur qui contient des informations spécifique au module. Le nom représente le nom du module de configuration et la valeur est spécifique au module. Par exemple:
openssl_conf = openssl_init

[openssl_init]
oid_section = new_oids
engines = engine_section
    
[new_oids]
... new oids here ...
    
[engine_section]
... engine stuff here ...

Module de configuration d'objet ASN1

Ce module a le nom oid_section. La valeur est le nom de la section contenant les paires de valeur d'OID. Bien que certains utilitaires openssl ont leur propre section d'objet ASN1, toutes ne l'ont pas. En utilisant le module de configuration d'objet ASN1 tout l'utilitaire openssl peut voir les nouveaux objets. Par exemple:
[new_oids]
some_new_oid = 1.2.3.4
some_other_oid = 1.2.3.5

Il est également possible de définir la valeur avec un nom long, suivi par une virgule et l'OID:
shortName = some object long name, 1.2.3.4

Module de configuration engine

   Le module de configuration ENGINE a le nom des engines. La valeur pointe vers une section contenant les informations de configuration du moteur.

Chaque section spécifique est utilisée pour définir les algorithmes par défaut, le chargement dynamique, d'initialisation et les contrôles envoyés. par exemple:
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section
# Configure ENGINE named "bar"
bar = bar_section
    
[foo_section]
... foo ENGINE specific commands ...

[bar_section]
... "bar" ENGINE specific commands ...

La commande engine_id est utilisée pour donner le nom du moteur. par exemple:
[engine_section]
# This would normally handle an ENGINE named "foo"
foo = foo_section
    
[foo_section]
# Override default name and use "myfoo" instead.
engine_id = myfoo

   La commande dynamic_path charge et ajoute un engine. C'est équivalent au contrôle SO_PATH avec la partie argument suivie par LIST_ADD avec la valeur 2 et LOAD à l'engine dynamic.

   La commande init détermine l'initialisation de l'engine. À 0 l'engine n'est pas initialisé. La commande default_algorithms définis les algorithmes par défaut qu'un engin fournis en utilisant les fonctions ENGINE_set_default_string().

Si le nom match aucune des commande ci-dessus, il sont considérés comme des commandes ctrl qui sont envoyés à l'engine. La valeur de la commande est l'argument de la commande ctrl. Si la v+aleur est une chaîne vide aucune valeur n'est envoyée à la commande. par exemple:
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section
    
[foo_section]
# Load engine from DSO
dynamic_path = /some/path/fooengine.so
# A foo specific ctrl.
some_ctrl = some_value
# Another ctrl that doesn't take a value.
other_ctrl = EMPTY
# Supply all default algorithms
default_algorithms = ALL

Module de configuration EVP

Ce module a le nom alg_section qui pointe vers une section contenant les commandes algorithme. Actuellement la seule commande algorithme supportée est fips_mode dont la valeur devrait être un booléen. par exemple:
alg_section = evp_settings
    
[evp_settings]
fips_mode = on

Module de configuration ssl

Ce module a le nom ssl_conf qui pointe vers une section contenant les configurations ssl. Chaque ligne dans la section contient le nom de la configuration et la section. Chaque section consiste de paires commande-valeur pour SSL_CONF. Chaque paire sera passée à SSL_CTX ou la structure SSL en cas d'appel SSL_CTX_config() ou SSL_config() avec le nom de configuration approprié. Noter que tout caractère avant le point initial dans la section est ignoré donc la même commande peut être utilisée plusieurs fois:
ssl_conf = ssl_sect
    
[ssl_sect]
server = server_section
    
[server_section]
RSA.Certificate = server-rsa.pem
ECDSA.Certificate = server-ecdsa.pem
Ciphers = ALL:!RC4

Notes

   Si un fichier de configuration tente d'étendre une variable qui n'existe pas alors une erreur est flaggée et le fichier n'est pas chargé. Cela peut se produire si une variable d'environnement n'existe pas.

   Cela peut fonctionner en incluant une section par défaut pour fournir une valeur par défaut: si la recherche d'environnement échoue, la valeur par défaut sera utilisée. Pour que cela fonctionne correctement la valeur par défaut doit être définie très tôt dans le fichier de configuration.

Si la même variable existe dans la même section, seule la dernière est prise en compte. Sous certaines circonstances comme avec les DN le même champ peut être présent plusieurs fois:
1.OU = "My first OU"
2.OU = "My Second OU"

Exemples

Exemple de fichier de configuratio utilisant des fonctionnalités décrite plus haut:
HOME=/temp
RANDFILE= ${ENV::HOME}/.rnd
configdir=$ENV::HOME/config
    
[ section_one ]
# We are now in section one.
# Quotes permit leading and trailing whitespace
any = " any variable name "
    
other = A string that can \
cover several lines \
by including \\ characters
    
message = Hello World\n
    
[ section_two ]
greeting = $section_one::message

L'exemple suivant montre come étendre les variables d'environnement. Supposont que l'on veut une variable tmpfile référrant à un fichier temporaire. Le répertoire où il est placé peut être déterminé par la variable d'environnement TEMP ou TMP, mais elle peut ne pas être définie. En incluant les noms des variables d'environnement sans que celle-ci n'existe créé une erreur en chargeant le fichier de configuration. En utilisant la section par défaut pour les 2 valeurs:
# si TMP n'existe pas
TMP=/tmp
# Si TMP existe
TEMP=$ENV::TMP
tmpfile=${ENV::TEMP}/tmp.filename

Exemple pour entrer en mode fips:
openssl_conf = openssl_conf_section
    
[openssl_conf_section]
alg_section = evp_sect
    
[evp_sect]
fips_mode = yes

Configuration plus complexe:
openssl_conf = openssl_conf_section
    
[openssl_conf_section]
alg_section = evp_sect
oid_section = new_oids
    
[evp_sect]
fips_mode = no
    
[new_oids]
# New OID, just short name
newoid1 = 1.2.3.4.1
# New OID shortname and long name
newoid2 = New OID 2 long name, 1.2.3.4.2

   Les exemples ci-dessus peuvent être utilisées avec toute application utilisant la librairie si openssl_conf est modifié pour correspondre au nom de l'application.

Par exemple, si le second fichie d'exemple ci-dessus est sauvé dans example.cnf, la ligne de commande:
OPENSSL_CONF=example.cnf openssl asn1parse -genstr OID:1.2.3.4.1
va afficher
0:d=0 hl=2 l= 4 prim: OBJECT :newoid1

BUGS

   Il n'y a actuellement aucun moyen d'utiliser des caractères en utilisant la notation octal \nnn. Les chaînes sont toutes terminer par un caractère null, donc les nulls ne peuvent pas faire partie de la valeur. Les fichiers sont chargés en une seule passe. Cela signifie qu'une expansion de variable ne fonctionne que si les variables sont référencées très tôt dans le fichier.
^
06 mai 2016

htmlpdflatexmanmd




ETSI TS 101 862 (2006 01)

ETSI TS 101 862 (2006 01)

Profile de certificat qualifié

   La directive du parlement européen et du conseil dans le cadre communautaire pour les signatures électroniques (1999/93/EC) définis des exigences pour un type de certificat spécifique appelé "Qualified Certificates". Ces certificats ont une importance spécifique pour l'acceptation de signatures électroniques via la partie suivante de l'article 5 (effets légal des signatures électroniques):

   Les états membre doivent s'assurer que les signatures électroniques avancées qui sont basés sur un certificat qualifié et qui sont créés par un périphérique de création de signature sécurisé:

a) satisfont les exigences légales d'une signature en relation à une donnée sous forme électronique de la même manière qu'une signature manuscrite satisfait ces exigences pour une données sous forme papier; et
b) Sont admissible comme preuve dans les procédures judiciaires

   La directive 1999/93/EC définis un certificat qualifié dans l'article 2:

  "Qualified Certificate" signifie un certificat qui répond aux exigences prévue à l'annexe I et est fournis par un fournisseur de service de certification qui répond aux exigences prévues dans l'annexe II.

Scope

   Le présent document définis un profile pour les certificats qualifiés, basé sur les définitions techniques dans la rfc3739, qui peut être utilisé par des émetteurs de certificats qualifiés comformément aux annexes I et II de la directive de signatures électronique européenne 1999/93/EC

   Ce profile de certificat qualifié et le profile de certificat qualifié de l'IETF (rfc3739) adressent les certificats qualifié dans différents contextes et utilisent donc le terme Certificat Qualifié avec des significations légèrement différentes. Le profile IETF utilise ce terme dans un contexte universelle indépendamment des exigences légales. Le profile de ce document utilise ce terme pour décrire un certificat qualifié tel que définis par la directive 1999/93/EC.

Profile de certificat

   Ce profile est basé sur le profile de la rfc3739, qui est basé sur la rfc3280 et X.509v3.

Champ Issuer

   Le nom de l'emetteur contenu dans le champ issuer (comme définis dans la clause 3.1.1 dans la rfc3739) doit contenir un nom de pays dans l'attribut countryName. Le pays spécifié doit être le pays dans lequel l'emetteur du certificat est établis.

Déclarations de certificat qualifié

   Ce profile définis des déclarations individuels à utiliser avec l'extension qCStatements, définis dans la rfc3739.

   Quand cette extension est marquée critique, cela signifie que toute déclaration inclue dans l'extension sont considérés critique. Des déclaration suivantes sonft définis dans ce profile:

- Déclaration affirmant que les certificats sont émis comme certificats qualifiés
- Déclaration concernant les limites sur la valeur de transaction pour lequel le certificat peut être émis.
- Déclaration indiquant la durée de période de rétention durant laquelle les informations d'enregistrement sont archivés
- Déclaration affirmant que la clé privée associée avec la clé publique dans le certificat réside dans un périphérique de création de signature sécurisé

   Déclaration affirmant que les certificats sont émis comme certificats qualifiés

La déclaration définis dans cette clause contient un identifiant de la déclaration créé par la CA, statuant que ce certificat est émis comme certificat qualifié en accord avec l'annexe I et II de la directive 1999/93/EC, tel qu'implémenté dans la loi du pays où la CA est établie:
esi4-qcStatement-1 QC-STATEMENT ::= { IDENTIFIED BY id-etsi-qcs-QcCompliance }
-- Cette déclaration est une déclaration par l'émetteur que ce certificat est émis comme certificat qualifié en accord avec l'annexe I et II de la Directive 1999/93/EC du parlement européen et du conseil du 13 Décembre 1999 dans un cadre communautaire pour les signatures électronique, tel qu'implémenté dans la loi du pays spécifié dans le champ issuer de ce certificat.
id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 }

   Déclaration concernant les limites sur la valeur de transaction pour lequel le certificat peut être émis

   Les limites dans la valeur de transactions, pour lequel le certificat peut être utilisé, peut être indiqué en utilisant la déclaration définie dans cette clause. Les codes sont définis dans ISO 4217. Cette déclaration optionnelle contient:

- Un identifiant pour cette déclaration
- Une valeur monétaire exprimant la limite dans la valeur de transactions


esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED BY id-etsi-qcs-QcLimitValue }
-- Cette déclaration est une déclaration par l'emetteur qui impose une limitation dans la valeur de transaction pour laquelle ce certificat peut être utilisé pour la quantité spécifiée (MonetaryValue), en accord avec la directive 1999/93/EC du parlement européen et du conseil du 13 Décembre 1999 dans un cadre communautaire pour les signatures électronique, tel qu'implémenté dans la loi du pays spécifié dans le champ issuer de ce certificat.
QcEuLimitValue ::= MonetaryValue
    
MonetaryValue::= SEQUENCE {
    currency Iso4217CurrencyCode,
    amount INTEGER,
    exponent INTEGER}
    -- value = amount addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo 10^exponent
Iso4217CurrencyCode ::= CHOICE {
    alphabetic PrintableString (SIZE (3)), -- Recommended
    numeric INTEGER (1..999) }
    -- Alphabetic or numeric currency code as defined in ISO 4217
    -- It is recommended that the Alphabetic form is used
id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 }

   Déclaration indiquant la durée de période de rétention

   La dépendance des certificats qualifiés peuvent dépendre de l'existence d'informations externes retenus par la CA. Un aspect significatif est que la directive 1999/93/EC permet des formes de nom dans les certificats, tel que les pseudonyms, qui peuvent exiger l'assistance de la CA pour une autorité d'enregistrement de nom, pour identifier la personne physique associée à l'identité en cat de dispute. Cette déclaration optionnelle contient:

- Un identifiant de cette déclaration
- Une période de rétention pour les informations matérielles pertinentes pour l'utilisation et la confiance du certificat, exprimé en nombre d'années après da date d'expiration du certificat.



esi4-qcStatement-3 QC-STATEMENT ::= { SYNTAX QcEuRetentionPeriod IDENTIFIED BY id-etsi-qcs-QcRetentionPeriod }
-- Cette déclaration est une déclaration par l'émetteur garantis que pour un certificat où cette déclaration apparaît cette information matérielle pertinente pour l'utilisation et la confiance du certificat seront archivés et peuvent être disponibles au delà de la fin de la période de validité du certificat pour le nombre d'années indiqué dans cette déclaration.
QcEuRetentionPeriod ::= INTEGER
    
id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIFIER ::= { id-etsi-qcs 3 }

   Déclaration affirmant que la clé privée associée avec la clé publique dans le certificat réside dans un SSCD

Les autoritéd de certification affirmant émettre des certificats où la clé privée liée à la clé publique certifiée résidant dans un SSCD peuvent utiliser cette déclaration optionnelle. Cette déclaration contient un identifiant de cette déclaration, créé par la CA, statuant que la clé privée associée avec la clé publique dans le certificat est stockée dans un SSCD en accord avec l'annexe III de la directive 1999/93/EC, tel qu'implémenté dans la loi du pays où la CA est établie.
esi4-qcStatement-4 QC-STATEMENT ::= { IDENTIFIED BY id-etsi-qcs-QcSSCD }
id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 }

Indication de certificat qualifié

   Les 2 techniques suivantes peuvent être utilisées pour déclarer qu'un certificat est émis comme certificat qualifié:

1) en identifiant une stratégie de certificat dans les extensions de stratégie de certificat, comme définis dans la clause 4.2.1.5 de la rfc3280, exprimant clairement que l'émetteur a émis intentionnellement le certificat comme certificat qualifié et que l'émetteur affirme être conforme avec les annexes I et II de la directive; ou
2) en incluant une extension de déclaration de certificat qualifié avec une déclaration si4-qcStatement-1 tel que définis dans la clause 5.2.1 de ce profile.

   Les certificats qualifiés conformes avec le présent document devraient inclure une stratégie en accord avec 1). Les certificats qualifiés conformes avec le présent document émis jusqu'au 30 juin 2005 devraient contenir une déclaration en accord avec 2). Ceux émis après cette date doivent contenir une déclaration en accord avec 2). Les certificats qualifiés conformes avec le présent document doivent dans tous les cas utiliser au moins une des techniques ci-dessus.

Annexe I de la directive

Pour chaque exigence dans la directive 1999/93/EC:
L'implémentation en accord avec ce profile et les standards sous-jacents

(a) une indication que le certificat est émis comme certificat qualifié:
inclusion de la stratégie de certificat définissant cette propriété et/ou une déclaration explicite définissant cette propriété tel que définis dans la clause 5.3
(b) L'identification du fournisseur de service de certification et l'état dans lequel il est établis:
L'information stockée dans le champ Issuer tel que définis dans la clause 3.1.1 de la rfc3739
(c) Le nom du signataire ou un pseudonyme, qui doit être identifié:
Tel que définis dans la clause 3.1.2 de la rfc3739
(d) Fournir un attribut spécifique du signataire si nécessaire, en fonction du but pour lequel le certificat est prévu:
Tel que définis dans les clauses 3.1.2 et 3.2.1 de la rfc3739
(e) Données de vérification de signature qui correspond à la données de création de signature sous le contrôle du signataire:
La clé publique avec les informations associées listées dans l'annexe I et II
(f) Une indication du début et de la fin de la période de validité du certificat:
La période de validité conforme aux recommandations X.509 et la rfc3280
(g) le code de l'identité du certificat:
Le numéro de série du certificat conforme aux recommandations X.509 et la rfc3280
(h) La signature électronique avancée du fournisseur de service de certification l'ayant émis:
La signature numérique de l'émetteur conforme aux recommandations X.509 et la rfc3280
(i) Les limitation du périmètre d'utilisation du certificat, si applicable:
Fournis dans l'extension de stratégies de certificat, l'extension d'utilisation de clé, et l'extension d'utilisation de clé étendue conforme aux recommandations X.509 et la rfc3280
(j) Les limites de valeur de transaction pour lesquelles le certificat peut être utilisé, si applicable:
En accord avec la clause 5.2.2

Annexe II de la directive

   L'annexe II contient les exigences pour les fournisseurs de services de certification émettant des certificats qualifiés, qui généralement n'impactent pas le format de certificat. Certaines fonctions spécifiues des certificats qualifiés, comme listé ci-dessous, peuvent cependant être utilisés pour supporter ces exigences:

Exigences dans l'annexe II de la directive 1999/93/EC:
Mécanisme supporté

l'exigences b) inclue une exigence d'un service de révocation immédiat et sécurisé:
L'extension de point de distribution de crl et l'accès aux informations de l'autorité conforme à la rfc3280 peuvent contenir les informations utilisées pour fournir et identifier ces services
L'exigence i) inclus une exigence sur la rétension des informations pour une période de temps appropriés:
La clause 5.2.3 définis une déclaration qui peut être utilisée pour communiquer la période de rétension aux tiers de confiance
L'exigence k) status que la partie pertinente des termes et conditions au regard de l'utilisation du certificat doit être disponible à la demande de tiers de confiance validant le certificat:
Une stratégie de certificat dans l'extension de stratégie de certificat peut contenir un qualifiant de type CPSurl conforme à la rfc3280, pointant vers l'emplacement où cette information peut être obtenue.
^
18 août 2015

htmlpdflatexmanmd




rfc5019

rfc5019

Profile OCSP pour les environnements à haut volume

   OCSP spécifie un mécanisme utilisé pour déterminer le statut des certificats numériques, au lieu d'utiliser les CRL. Depuis sa définition en 1999, il a été déployé dans de nombreux environnements et prouvé son utilité.

   À ce jour, de nombreux déploiements on été utilisé pour s'assurer les informations de statut de certificats de manière sécurisé et en temps pour les transactions électroniques ou hautement sensibles, tels que les environnements financiers. Un tel environnement exige un répondeur OCSP en temps réel. De plus, ces déploiements ont opérés dans des environnements où l'utilisation de la bande passante n'est pas un problème, et fonctionnement sur des systèmes client et serveur où la charge de traitement n'est pas une contrainte.

   Vu que l'utilisation d'une PKI continue de grandir et d'aller dans divers environnements, on n'a donc besoin d'un mécanisme de statut de certificat efficace. Bien qu'OCSP a été définis et déployé dans de nombreuses petites et moyennes PKI qui opèrent sur des systèmes puissants et sur des réseaux câblés, il y a une limite sur l'agrandissement des déploiements. Les environnements mobiles, où la bande passante peut être une des principales contraintes, il exige une attention particulière de l'utilisation d'OCSP pour minimiser l'utilisation de la bande passante et la complexité de traitement côté client.

   Les PKI continuent d'être déployés dans des environnements où des millions voir des centaines de millions de certificats ont été émis. Dans beaucoup de ces environnements, un aussi grand nombre d'utilisateurs on besoins de s'assurer que le certificat qu'ils souhaitent utiliser n'a pas été révoqué. Il est important que OCSP soit utilisé de manière à s'assurer que la charge des répondeurs OCSP et que l'infrastructure réseaux soient utilisés au minimum.

   Ce document adresse les problèmes d'évolution inhérents en utilisant OCSP dans des environnements PKI décrits ci-dessus en définissant un profile de message et en clarifiant le comportement du client et du répondeur OCSP qui va permettre de:

1) pré-produire et distribuer des réponse OCSP
2) Réduire la taille de message OCSP pour réduire la bande passante
3) Le caching des messages de réponse dans le réseaux et dans le client

   Il est prévu que les exigences définies dans ce profile soit adopté par les clients et les répondeurs OCSP opérant dans des environnements PKI à très grand volume ou les environnements PKI qui exigent une solution légère pour minimiser la bande passante de le traitement côté client. Vu que OCSP n'a pas de moyen de signaler les capacités du répondeur dans le protocole, les clients doivent différencier les réponses OCSP produites par les répondeurs conforme avec ce profile et ceux qui n'ont pas besoin de s'appuyer sur des mécanismes externe pour déterminer quand une réponse opère en accord avec ce profile et, quand les exigences de ce profile s'appliquent. Dans le cas où des mécanismes tiers ne sont pas disponible entre un client OCSP 2560 et un répondeur qui opère dans un mode décrit dans cette spécification.

Profile de demande OCSP

Structure OCSPRequest

   OCSPRequest conforme a ce profile doit inclure seulement une Request dans la structure OCSPRequest.RequestList

   Les clients ne doivent pas utiliser SHA1 comme algorithme de hash pour les valeurs CertID.issuerNameHash et CertID.issuerKeyHash.

   Les clients ne doivent pas inclure la structure singleRequestExtensions

   Les clients ne devraient pas inclure la structure requestExtensions. Si une structure requestExtensions est inclue, ce profile recommande qu'il ne contienne seulement que l'extension nonce (id-pkix-ocsp-nonce).

OCSPRequests signées

   Les clients ne doivent pas envoyer d'OCSPRequests signés. Les répondeurs peuvent ignorer la signature dans les requêtes OCSPRequests.

   Si OCSPRequest est signé, le client devrait spécifier son nom dans le champ OCSPRequest.requestorName, sinon, les clients ne devraient pas inclure le champ requestorName dans OCSPRequest. Les serveurs OCSP doivent être préparés à recevoir des requêtes OCSP non-signés qui contiennent le champ requestorName, mais doivent réaliser que la valeur fournie n'est pas authentifiée.

Profile de réponse OCSP

Structure OCSPResponse

   Les répondeurs doivent générer un BasicOCSPResponse comme identifié par l'OID BasicOCSPResponse. Les OCSPResponses conformes à ce profile devraient inclure seulement un SingleResponse dans la structure ResponseData.responses, mais peuvent inclure des éléments SingleResponse additionnels si nécessaire pour améliorer les performances de pré-génération de réponse ou l'efficacité des caches.

   Le répondeur ne devrait pas inclure responseExtensions. Comme spécifié dans OCSP, les clients doivent ignorer les responsesExtensions non-critiques dans la réponse.

   Dans le cas où un répondeur n'a pas la possibilité de répondre à une demande OCSP contenant une option non supportée par le serveur, il devrait retourner la réponse la plus complète qu'il peut. Par exemple, dans le cas où un répondeur ne supporte que les réponses pré-produites et n'a pas la possibilité de répondre à une demande OCSP contenant a nonce, il devrait retourner une réponse qui n'inclut pas un nonce.

   Les clients devraient tenter de traiter une réponse même si la réponse n'inclue pas un nonce.

   Les répondeurs qui n'ont pas la capacité de répondre aux requêtes OCSP qui contiennent une option non-supportée telle que nonce peuvent renvoyer la requête à un répondeur OCSP qui en a la capacité.

   Le répondeur peut inclure la structure d'extensions singleResponse.singleResponse.

OCSPResponses signés

   Les clients doivent valider la signature de l'OCSPResponse retourné. Si la réponse est signée par un délégué de l'autorité de certification émettrice, un certificat de répondeur valide doit être référencé dans la structure BasicOCSPResponse.certs.

   Il est recommandé que le certificat du répondeur OCSP contienne l'extension id-pkix-ocsp-nocheck, comme définis dans OCSP, pour indiquer au client qu'il ne doit pas vérifier le statut du certificat. De plus, il est recommandé que ni une extension authorityInfoAccess ni une extension cRLDistributionPoints ne soit inclus dans le certificat du répondeur OCSP. En accord avec ça, le certificat de signature du répondeur devrait être relativement de courte durée et renouvelé régulièrement.

   Les clients doivent être capable d'identifier les certificats de répondeur OCSP en utilisant les chois ResponseData.ResponderID byName et byKey. Les répondeur devraient utiliser byKey pour réduire ensuite la taille de la réponse dans les scénarios où la réduction de la bander passante est un problème.

Valeurs OCSPResponseStatus

   Tant que l'infrastructure OCSP a des enregistrements autoritatifs pour un certificat particulier, un OCSPResponseStatus "Success" sera retourné. Quand l'accès aux enregistrements autoritatifs pour un certificat particulier n'est pas disponible, le répondeur doit retourner un OCSPResponseStatus "unautorized". Ce profile étend la rfc2560 de "unauthorized" comme suit:

           La réponse "unauthorized" est retournée dans le cas où le client n'est pas autorisé à faire cette demande à ce serveur ou quand le serveur n'est pas capable de répondre de manière autoritative.

   Par exemple, les répondeurs OCSP qui n'ont pas accès aux enregistrements autoritatifs pour un certificat, tel que ceux qui génèrent et distribuent les réponses OCSP à l'avance et donc n'ont pas la capacité de répondre correctement avec une réponse "success" ni "unknown", vont répondre avec un OCSPResponseStatus "unauthorized". Également, pour s'assurer que la base d'information de révocation ne grandis pas indéfiniment dans le temps, le répondeur peut supprimer les enregistrements des certificats expirés. Les demandes des clients pour les certificat dont l'enregistrement a été supprimé vont résulter dans un OCSPResponseStatus "unauthorized".

thisUpdate, nextUpdate, et producedAt

   En pré-produisant les messages OCSPResponse, le répondeur doit définir les temps thisUpdate, nextUpdate et producedAt comme suit:

thisUpdate La date à laquelle le statut indiqué est connu comme étant correcte
nextUpdate La date à laquelle ou avant laquelle de nouvelles informations seront disponibles sur le statut des certificats. Les répondeur doivent toujours inclure cette valeur pour aider dans le caching des réponses.
producedAt La date à laquelle la réponse OCSP a été signée

   Note: Dans de nombreux cas la valeur de thisUpdate et producedAt seront les même.

   Pour ce profile, les valeurs GeneralizedTime encodé ASN.1 pour thisUpdate, nextUpdate et producedAt doivent être exprimés en GMT et doivent inclure les secondes, même quand le nombre de secondes est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

Comportement du client

Découverte du répondeur OCSP

   Les clients doivent supporter l'extension authorityInfoAccess comme définis dans PKIX et doivent reconnaître la méthode d'accès id-ad-ocsp. Cela permet d'informer les clients sur la manière de contacter le service OCSP.

   Dans le cas où un client vérifie le statut d'un certificat qui contient une extension authorityInformationAccess pointant vers un répondeur OCSP et une extension cRLDistributionPoints pointant vers une CRL, le client devrait tenter de contacter le répondeur OCSP en premier. Les clients peuvent tenter de récupérer la CRL si aucune OCSPResponse n'est reçu du répondeur.

Envoyer une demande OCSP

   Pour éviter le trafic réseaux inutile, les applications doivent vérifier la signature d'une donnée signée avant de demander à un client OCSP de vérifier le statut des certificats utilisé pour vérifier la donnée. Si la signature est invalide ou l'application n'est pas capable de la vérifier, une vérification OCSP ne doit pas être tentée.

   Similairement, une application doit valider la signature dans les certificats dans une chaîne, avant de demander à un client OCSP de vérifier le statut d'un certificat. Si la signature du certificat est invalide ou que l'application n'est pas capable de le vérifier, une vérification OCSP ne doit pas être faite. Les clients ne devraient pas faire de demande de statut des certificats expirés.

S'assure qu'un OCSPResponse est récent

   Pour s'assurer qu'un client n'accepte pas de réponse expirée qui indique un statut 'good' il y a une réponse plus récente qui spécifie un statut 'revoked', un client doit s'assurer que les réponses qu'ils reçoivent sont récentes.

   En général, 2 mécanismes sont disponibles aux clients pour s'assurer qu'une réponse est récente. La première utilise nonces, et la seconde est basée sur la date. Pour que les mécanismes basés sur les dates fonctionnent, les clients et les répondeurs doivent avoir accès à une source de temps précise.

   Parce que ce profile spécifie que les clients ne devraient pas inclure une structure requestExtensions dans OCSPRequests, les clients doivent être capable de déterminer que OCSPResponse est récent basé sur une source de temps précise. Les clients qui optent pour inclure un nonce dans le demande ne doivent pas rejeter une OCSPResponse correspondante seulement sur la base de la non-existance du nonce attendu, mais doivent valider l'OCSPResponse basé sur le temps.

   Les clients qui n'incluent pas un nonce dans la requête doivent ignorer tout nonce qui peut être présent dans la réponse.

   Les clients doivent vérifier l'existence du champ nextUpdate et doivent s'assurer de la date courante, exprimée en temps GMT, qui doit être entre le thisUpdate et le nextUpdate. Si le champ nextUpdate est absent, le client doit rejeter la réponse.

   Si le champs nextUpdate est présent, le client doit s'assurer qu'il n'est pas antérieur la date courante. Si la date courante dans le client est ultérieur au temps spécifié dans le champ nextUpdate, le client doit rejeter la réponse. Les clients peuvent autoriser la configuration d'une petite période de tolérance pour accepter des réponses après nextUpdate pour gérer les différences mineurs d'horloge relative aux répondeurs et aux caches. Cette période de tolérance devrait être choisis sur la précision de la technologie de synchronisation de temps disponible dans l'environnement de l'application appelante. Par exemple, les paires internet avec connexion à faibles latences s'attendent à une synchronisation du temps NTP avec une précision élevée; les environnements à haute latence ou quand un NTP n'est pas disponible peuvent avoir besoin d'une tolérance plus élevée.

Profile de transport

   Le répondeur OCSP doit supporter les requêtes et réponses sur HTTP. En envoyant les requêtes qui sont inférieur ou égal à 255 octets au total (après encodage) incluant le schéma et les délimiteurs (http://), le nom du serveur et la structure OCSPRequest encodé en base 64, les clients doivent utiliser la méthode GET (pour permettre le caching de réponse OCSP). Les requêtes OCSP supérieurs à 255 octets devraient être envoyés en utilisant la méthode POST. Dans tous les cas, les clients doivent suivre les descriptions définis dans la norme OCSP en construisant leurs messages.

En construisant un message GET, les clients OCSP doivent encoder en base 64 la structure OCSPRequest et l'ajouter à l'URI spécifiée dans l'extension authorityInfoAccess. Les clients ne doivent pas inclure les caractères CR ou LF dans la chaîne encodée base 64. Les clients doivent encoder l'url proprement, par exemple:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D

En réponse aux OCSPRequests formatés proprement qui sont capable d'être mis en cache (par exemple, les réponses qui contiennent une valeur nextUpdate), le répondeur va inclure la valeur binaire de l'encodé DER de l'OCSPResponse précédé par l'en-tête HTTP suivant:
content-type: application/ocsp-response
content-length: ‹OCSP response length›
last-modified: ‹producedAt [HTTP] date›
ETag: "‹strong validator›"
expires: ‹nextUpdate [HTTP] date›
cache-control: max-age=‹n›, public, no-transform, must-revalidate
date: ‹current [HTTP] date›

Recommandations de mise en cache

   La capacité de mise en cache des réponses OCSP via le réseaux est un facteur important dans les déploiements à haut volume. Cette section discute de comportement de la mise en cache des clients OCSP et des proxy HTTP et les étapes qui devraient être faites pour minimiser le nombre de fois que les clients OCSP utilisent le réseaux. De plus, le concept de réponses OCSP incluses dans les échanges de protocole ( stapling ou piggybacking), tel que définis dans TLS, sont également discutés.

Mise en cache par le client

   Pour minimiser l'utilisation de la bande passante, les clients doivent mettre en cache localement les réponses OCSP autoritatives (ex: une réponse avec une signature qui a été validée avec succès et qui indique un OCSPResponseStatus 'successful').

   Beaucoup de clients OCSP vont envoyer des OCSPRequests à ou près du temps nextUpdate (quand une réponse mise en cache expire). Pour éviter des pointes importantes dans la charge des répondeurs qui peuvent se produire quand de nombreux clients rafraîchissent les réponses en cache pour un certificat populaire, les répondeurs peuvent indiquer quand le client devrait chercher une réponse OCSP mise à jours en utilisant la directive cache-control:max-age. Pour s'assurer que les clients reçoivent une réponse mises à jours, les répondeurs OCSP doivent rafraîchir la réponse OCSP avant le temps max-age.

Proxy HTTP

   Le répondeur devrait définir l'en-tête HTTP dans la réponse OCSP de manière à permettre une utilisation intelligente des serveurs proxy intermédiaire. Voir la norme HTTP pour la définition de ces en-têtes et le format correcte.

HTTP Header___Description
date La date et l'heure à laquelle le serveur OCSP a généré la réponse HTTP.
last-modified Cette valeur spécifie la date et l'heure à laquelle le répondeur OCSP à modifié la réponse. Cette date sera la même que thisUpdate dans la requête elle-même.
expires Spécifie la durée de à laquelle la réponse est considérée comme récente. Cette date est la même que nextUpdate dans la réponse OCSP.
ETag Une chaîne qui identifie une version particulière de la donnée associée. Ce profile recommande que la valeur ETag soit une représentation hexa ASCII du hash SHA1 de la structure OCSPResponse
cache-control Contient des directives de mise en cache:

        * max-age=‹n› où n est la valeur de temps ultérieur à thisUpdate mais inférieur à nextUpdate.
        * public rend la réponse non cachable
        * no-transform Spécifie qu'une proxy cache ne peut pas changer le type, longueur, ou encodage du contenu de l'objet.
        * must-revalidate empêche les caches de retourner des réponses périmées intentionnellement

   Les répondeurs OCSP ne doivent pas inclure d'en-tête "Pragma: no-cache", "Cache-Control: no-cache", ou "Cache-Control: no-store" dans les réponses OCSP autoritatives. Les répondeurs OCSP devraient inclure un ou plusieurs de ces en-têtes dans les réponses non-autoritatives.

Par exemple, supposons une réponse OCSP ayant les horodatages suivant:
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMT

Et que les clients demandent la réponse le 2 may 2005 01:00:00 GMT. Dans ce scénario, la réponse HTTP peut ressembler à ceci:
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
‹...›

   Les clients OCSP ne doivent pas inclure d'en-tête no-cache dans les demandes, sauf si le client rencontre une réponse expirée qui peut être le résultat d'une donnée périmée d'un proxy cache. Dans cette situation, les clients devraient renvoyer le demande en spécifiant que les proxy devraient être bypassés en incluant un en-tête HTP approprié dans la demande (ex. Pragma: no-cache ou Cache-Control: no-cache).

Mise en cache des serveurs

   Dans certains scénarios, il est avantageux d'inclure les information de réponse OCSP dans le protocole utilisé entre le client et le serveur. En incluant les réponses OCSP de cette manière a quelques effet désirable.

   D'abord, il permet la mise en cache des réponses OCSP dans le serveur diminuant ainsi le nombre de requêtes au répondeur.

   Ensuite, il permet la validation de certificat dans le cas où le client n'est pas connecté à un réseaux et donc élimine le besoin pour les clients d'établir une nouvelle session HTTP avec le répondeur.

   Il réduit le nombre d'aller-retours que le client a besoin pour compléter un handshake

   Enfin, il simplifie l'implémentation OCSP côté client en permettant une situation où le client n'a seulement besoin de la capacité de parser et reconnaître les réponses OCSP.

   Cette fonctionnalité a été spécifiée comme extension du protocole TLS, mais peut être appliqué à tout protocole client-serveur.

   Ce profile recommande que les clients et les serveurs TLS implémentent le mécanisme d'extension de demande de statut de certificat pour TLS.

   D'autres informations sur les problèmes de mise en cache peuvent être obtenus depuis la rfc3143.

Considérations de sécurité

   Les considérations suivantes s'appliquent en plus des considérations de sécurité spécifié dans la norme OCSP.

Attaques Replay

   Puisque l'utilisation de nonce dans ce profile est optionnel, il y a possibilité qu'une réponse OCSP périmée puisse être rejouée, causant le client à accepter une réponse 'good' quand en fait il a été révoké. Pour réduire cette attaque, les clients doivent avoir accès à une source de temps précise et s'assurer que les réponses OCSP qu'ils reçoivent sont suffisamment récentes.

   Les clients qui n'ont pas de source de temps précise sont vulnérables. Par exemple, un client avec une horloge suffisamment rapide peut rejeter une réponse OCSP récente et accepter une réponses valide qui est expirée pour des certificat qui sont en fait révoqués.

   De future versions du protocole OCSP peuvent fournir une manière pour le client de savoir si le serveur supporte nonce ou non. Si un client peut déterminer que le serveur supporte nonce, il doit rejeter une réponse qui ne contient pas le nonce attendu. Sinon, les client qui optent pour inclure un nonce dans la demande ne devraient pas rejeter l'OCSPResponse correspondant uniquement sur la base de la non-existance du nonce, mais doivent également valider OCSPResponse sur la base du temps.

Attaques Man-In-The-Middle

   Pour réduire les risques associés avec ce type d'attaque, le client doit valider correctement la signature de la réponse. L'utilisation de réponses signées dans OCSP sert à authentifier l'identité du répondeur OCSP et de vérifier qu'il est autorisé à signer les réponses de la CA.

Attaques pas usurpation d'identité

   L'utilisation de réponses signées dans le serveur OCSP sert à authentifier l'identité du répondeur OCSP. Comme détaillé dans OCSP, les clients doivent valider correctement la signature de la réponse OCSP et la signature du certificat du signataire OCSP pour s'assurer que le répondeur est autorisé.

Attaques pas deni de service

   Les répondeurs OCSP devraient prendre des mesures pour empêcher ou réduire les attaques par déni de service. Vu que ce profile spécifie l'utilisation de OCSPRequests non-signés, l'accès au répondeur peut être donné implicitement par toute personne qui souhaite envoyer une demande à un répondeur, et ainsi la capacité de monter des attaques par déni de service via des demandes en rafales. Par exemple, un répondeur peut limiter le taux de demande entrante pour une adresse IP particulière si un comportement douteux est détecté.

Modification des en-têtes HTTP

   Les valeurs incluses dans les en-têtes HTTP ne sont pas protégées cryptographiquement; elles peuvent être manipulées par un attaquant. Les clients devraient utiliser ces valeurs pour la mise en cache seulement après s'assurer que les valeurs sont présentes dans le OCSPResponse signé. Les clients ne devraient pas valider les réponses au-delà de la date nextUpdate.

Authentification et autorisation des demandes

   La suggestion d'utiliser des demandes non-signée dans cet environnement supprime une option qui permet au répondeur de déterminer l'authenticité de la requête entrante. Donc, l'accès au répondeur peut être implicitement donné à toute personne qui peut envoyer une demande à un répondeur. Les environnement où l'autorisation explicite pour accéder au répondeur OCSP est nécessaire peuvent utiliser d'autres mécanismes pour authentifier les demandeurs, ou restreindre le service.
^
14 août 2015

htmlpdflatexmanmd




rfc6960

rfc6960

Online Certificate Status Protocol - OCSP

   Ce document spécifie un protocole utile pour déterminer le statut courant d'un certificat numérique sans nécessiter de CRL. Des mécanismes additionnels adressant les exigences opérationnelles PKIX sont spécifiés dans des documents séparés.

   À la place de, ou en supplément de, vérifier avec une CRL périodique, il peut être nécessaire d'obtenir des informations rapide du status de révocation des certificats. Le protocole de statut de certificat en ligne (OCSP) permet aux applications de déterminer l'état d'un certificat identifié. OCSP peut être utilisé pour satisfaire certaines exigences opérationnelles en fournissant des informations de révocation plus récente qu'il est possible avec les CRL et peut également être utilisé pour obtenir des informations de statut additionnels. Un client OCSP émet une demande de statut à un répondeur OCSP et suspend l'acceptation des certificats en question jusqu'à ce que le répondeur fournir une réponse.

   Ce protocole spécifie les données qui doivent être échangées entre une application vérifiant le statut d'un ou plusieurs certificat le serveur fournissant le statut correspondant.

Requête

   Une demande OCSP contient les données suivantes:

- Une version de protocole
- Une demande de service
- Un identifiant du certificat cible
- Des extensions optionnelles, qui peuvent être traitées par le répondeur OCSP

   Une fois le demande reçue, un répondeur OCSP détermine si:

1. Le message est bien formé
2. Le répondeur est configuré pour fournir le service demandé
3. La demande contient les informations nécessaire.

   Si une de ces conditions n'est pas rencontrée, le répondeur OCSP produit un message d'erreur; sinon, il retourne une réponse définitive.

Réponse

   Les réponses OCSP peuvent être de différents types. Une réponse OCSP consiste d'un type de réponse et les octets de la réponse. Il y a un type de base de réponse OCSP qui doit être supporté par tous les serveur et clients OCSP. Le reste de cette section concerne seulement ce type de réponse de base.

   Tous les messages de réponse définitives doivent être signés numériquement. La clé utilisée pour signer la réponse doit appartenir à un parmi:

- La CA qui a émis le certificat en question
- Un répondeur trusté dont la clé publique est validé par le demandeur
- Un Répondeur désigné par la CA (Répondeur autorisé) qui maintient un certificat spécialement marqué émis directement par la CA, indiquant que le répondeur peut émettre des réponses OCSP pour cette CA.

   Un message de réponse définitive est composée de:

- La version de la syntaxe de la réponse
- L'identifiant du répondeur
- L'horodatage de la génération de la réponse
- Les réponses pour chaque certificat dans la demande
- Des extensions optionnelles
- L'OID de l'algorithme de signature
- La signature calculée par un hash de la réponse

   La réponse pour chaque certificat dans la demande consiste de:

- L'identifiant de certificat cible
- La valeur du statut du certificat
- L'interval de validité de la réponse
- Des extensions optionnelles.

   Cette spécification définis les indicateurs de la réponse définitive à utiliser dans la valeur de statut de certificat:

- good
- revoked
- unknown

   L'état "good" indique une réponse positive. Au minimum, cette réponse positive indique qu'aucun certificat avec le numéro de série demandé dans son interval de validité n'est révoqué. Cet état ne signifie pas nécessairement que le certificat a été émis ou que l'heure à laquelle la réponse a été produite est dans un intervalle de validité du certificat. Les extensions de réponse peuvent être utilisés pour transporter des informations additionnelles sur l'affirmation faite par le répondeur au regard du statut du certificat, tels que la déclaration positive sur l'émission, la validité, etc.

   L'état 'revoked' indique que le certificat a été révoqué, soit temporairement (certificateHold) soit de manière permanente. Cet état peut également être retourné si la CA associée n'a pas d'enregistrement de certificat émis avec le numéro de série du certificat dans la demande, en utilisant la clé courante ou précédente (référé à un certificat 'non-émis' dans ce document).

   L'état 'unknown' indique que le répondeur ne connaît pas le certificat demandé, généralement parce que le demandeur indique un émetteur non connus qui ne sert par ce répondeur.

   NOTE: Le statut 'revoked' indique qu'un certificat avec le numéro de série demandé devrait être rejeté, alors que le statut 'unknown' indique que le statut ne peut pas être déterminé par ce répondeur, permettant ainsi au client de décider s'il veut tenter une autre source d'information de statut (tel qu'une CRL). Cela rend la réponse 'revoked' prévue pour les certificats non-émis où l'intention du répondeur est de forcer le client à rejeter le certificat au lieu de tenter une autre source. Le statut 'revoked' est optionnel pour les certificats non-émis pour pouvoir maintenir la compatibilité avec les déploiements rfc2560. Par exemple, le répondeur peut ne pas avoir connaissance si un numéro de série demandé a été assigné à un certificat émis, ou le répondeur peut fournir des réponses pré-produites en accord avec la rfc5019 et, pour cette raison, il n'est pas capable de fournir une réponse signée pour tous les numéro de série non-émis.

   Quand un répondeur envoie une réponse 'revoked' à une demande de statut pour un certificat non-émis, le répondeur doit inclure l'extension de réponse de définition révoqué étendue dans la réponse, indiquant que le répondeur OCSP supporte la définition étendue de l'état 'revoked' pour couvrir également les certificats non-émis. En plus, le SingleResponse lié à ce certificat non-émis:

- Doit spécifique la raison de révocation certificateHold
- Doit spécifier le revocationTime au 1 Janvier 1970
- Ne doit pas inclure une extension de référence de CRL ou une extension d'entrée de CRL.

Exceptions

   En cas d'erreurs, le répondeur OCSP peut retourner un message d'erreur. Ces messages ne sont pas signés. Les erreurs peuvent être d'un des types suivant:

- malformedRequest
- internalError
- tryLater
- sigRequired
- unauthorized

   Un serveur produit la réponse 'malformedRequest' si la requête reçue n'est pas conforme à la syntaxe OCSP.

   La réponse 'internalError' indique que le répondeur OCSP a atteins un état inconsistant. La demande devrait être retentée potentiellement avec un autre répondeur.

   Dans le cas ou le répondeur OCSP est opérationnel mais incapable de retourner un status pour le certificat demandé, la réponse 'tryLater' peut être utilisée pour indiquer que le service existe mais est temporairement en incapacité de répondre.

   La réponse 'sigRequired' est retournée dans le cas où le serveur exige que le client signe la demande pour pouvoir construire la réponse.

   La réponse 'unauthorized' est retournée dans les cas où le client n'est pas autorisé à faire cette demande à ce serveur ou le serveur n'est pas capable de répondre autoritativement.

Sémantiques thisUpdate, nextUpdate, et produceAt

   Les réponses définies dans ce document peuvent contenir 4 dates -- thisUpdate, nextUpdate, producedAt, et revocationTime. La sémantique de ces champs est:

thisUpdate La date la plus récente à laquelle le statut est connu du répondeur pour être correct.
nextUpdate La date à laquelle ou avant laquelle de nouvelles informations seront disponibles
producedAt La date à laquelle le répondeur a signé cette réponse
revocationTime La date à laquelle le certificat a été révoqué.

Pré-production de réponse

   Les répondeurs OCSP peuvent pré-produire des réponses signées spécifiant le statut des certificats à une date spécifiée. La date à laquelle le statut est connu pour être correct doit être refléter dans le champ thisUpdate de la réponse. La date à ou avant laquelle la nouvelle information sera disponible est reflété dans le champ nextUpdate, alors que la date à laquelle la réponse a été produite apparaît dans le champ producedAt de la réponse.

Délégation de l'autorité de signature OCSP

   La clé qui signe les informations de statut de certificat n'a pas besoin d'être la même que celle qui a signé le certificat. Un émetteur de certificat peut explicitement déléguer l'autorité de signature OCSP en émettant un certificat contenant une valeur unique pour l'extension d'utilisation de clé étendue dans le certificat du signataire OCSP. Ce certificat doit être émis directement au répondeur par la CA.

Clé CA compromise

   Si un répondeur OCSP sait qu'une clé privé de CA particulière a été compromise, il peut retourner l'état 'revoked' pour tous les certificats émis par cette CA.

Contenu du certificat

   Pour transporter aux clients OCSP un point d'accès aux informations, les CA doivent fournir la capacité d'inclure l'extension d'information d'accès de l'autorité dans les certificats qui peuvent être vérifiés en utilisant OCSP. Alternativement, l'accessLocation pour le fournisseur OCSP peut être configuré localement dans le client OCSP.

   Les CA qui supportent un service OCSP, soit maintenus localement ou fournis par un répondeur autorisé, doivent fournir un URI accessLocation et l'OID id-ad-ocsp pour l'accessMethod dans la séquence AccessDescription.

   La valeur du champ accessLocation dans le certificat du sujet définis le transport (ex: HTTP) utilisé pour accéder au répondeur OCSP et peut contenir d'autres informations dépendantes du transport (ex: une URL).

Exigence pour l'acceptation de réponse signée

   Avant d'accepter une réponse signée pour un certificat particulier comme valid, les clients OCSP doivent confirmer que:

1. Le certificat identifié dans la réponse reçue correspond au certificat qui a été identifié dans la demande correspondant
2 La signature dans la réponse est valide
3. L'identité du signataire correspond au destinataire prévu de la demande
4. Le signataire est actuellement autorisé à fournir une réponse pour le certificat en question
5. La date à laquelle le statut a été indiqué est correct est suffisamment récente
6. Si disponible, la date à laquelle ou avant laquelle de nouvelles informations seront disponible est supérieurs à la date courante.

Détails du protocole

   La syntaxe ASN.1 importe les termes définis dans la rfrc5280. Pour le calcul de la signature, la donnée à signer est encodée en utilisant DER. Le tagging explicite ASN.1 est utilisé comme défaut sauf si le contraire est mentionné. Les termes importés d'ailleurs sont Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, et CRLReasons.

Syntaxe de la demande

   Cette section spécifie la spécification ASN.1 pour une demande de confirmation. Le formatage actuel du message peut varier, en fonction du mécanisme de transport utilisé (HTTP, SMTP, LDAP, etc).

La structure ASN.1 correspondant à OCSPRequest est:
OCSPRequest ::= SEQUENCE {
    tbsRequest TBSRequest,
    optionalSignature [0] EXPLICIT Signature OPTIONAL }
    
TBSRequest ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    requestorName [1] EXPLICIT GeneralName OPTIONAL,
    requestList SEQUENCE OF Request,
    requestExtensions [2] EXPLICIT Extensions OPTIONAL }
    Signature ::= SEQUENCE {
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}
    
Version ::= INTEGER { v1(0) }
    
Request ::= SEQUENCE {
    reqCert CertID,
    singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
    
CertID ::= SEQUENCE {
     AlgorithmIdentifier,
    issuerNameHash OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash OCTET STRING, -- Hash of issuer's public key
    serialNumber CertificateSerialNumber }

- tbsRequest est la demande OCSP optionnellement signée
- optionalSignature contient l'identifiant d'algorithme et ses paramètres associés dans signatureAlgorithm; la valeur de la signature dans signature; et optionnellement les certificat que le serveur a besoin pour vérifier la signature.
- version indique la version du protocole, qui est v1 (0) pour ce document.
- requestorName est optionnel est indique le nom du demandeur OCSP
- requestList contient une ou plusieurs demande de statut de certificat.
- requestExtensions est optionnel et inclus des extensions applicable aux demandes trouvées dans reqCert.
- reqCert contient l'identifiant d'un certificat cible
- singleRequestExtensions est optionnel et inclus des extensions applicable à cette demande de statut de certificat.
- hashAlgorithm est l'algorithme de hashage utilisé pour générer les valeurs issuerNameHash et issuerKeyHash.
- serialNumber est le numéro de série du certificat pour lequel le statut est demandé

Notes sur les demandes OCSP

   La principale raison d'utiliser la hash de la clé publique de la CA en plus du hash de nom de la CA pour identifier l'émetteur est qu'il est possible qui 2 CA choisissent d'utiliser le même nom. 2 CA ne vont jamais, cependant, avoir la même clé publique sauf si les CA on choisis d'utiliser la même clé explicitement, ou si une des clés de CA est compromise.

   Le support pour une extension spécifique est optionnel. Le flag de criticité ne devrait pas être utilisé. Les extensions non-reconnus doivent être ignorés, sauf si la criticité est définie.

   Le demandeur peut choisir de signer la demande OCSP. Dans ce cas, la signature est calculée sur la structure tbsRequest. Si la demande est signée, le demandeur doit spécifier son nom dans le champ requestorName. Également, pour les demandes signées, le demandeur peut inclure les certificats qui aident le répondeur OCSP à vérifier la signature de demandeur dans le champ certs de Signature.

Syntaxe de la réponse

   Cette section spécifie la spécification ASN.1 pour une réponse de confirmation. Le formatage actuel du message peut varier, en fonction du mécanisme de transport.

Une réponse OCSP consiste au minimum d'un champ responseStatus indiquand le traitement du statut de la demande. Si la valeur de responseStatus est une des conditions d'erreur, le champ responseBytes n'est pas mis.
OCSPResponse ::= SEQUENCE {
    responseStatus OCSPResponseStatus,
    responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
    
OCSPResponseStatus ::= ENUMERATED {
    successful (0), -- Response has valid confirmations
    malformedRequest (1), -- Illegal confirmation request
    internalError (2), -- Internal error in issuer
    tryLater (3), -- Try again later
            -- (4) is not used
    sigRequired (5), -- Must sign the request
    unauthorized (6) -- Request unauthorized
}

La valeur pour responseBytes consiste d'un identifiant d'objet et d'une syntaxe response identifiée par cet OID encodé comme chaîne d'octets.
ResponseBytes ::= SEQUENCE {
    responseType OBJECT IDENTIFIER,
    response OCTET STRING }

Pour un répondeur OCSP basique, responseType sera id-pkix-ocsp-basic
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

   Les répondeurs OCSP doivent être capable de produire des réponses de type id-pkix-ocsp-basic. Les clients OCSP doivent être capable de recevoir et traiter les réponse de type id-pkix-ocsp-basic.

La valeur pour la réponse doit être un encodé DER de BasicOCSPResponse
BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData ResponseData,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

La valeur pour la signature doit être calcurée sur le hash de l'encodé DER de ResponseData. Le répondeur peut inclure des certificats dans le champs certs pour aider le client OCSP à vérifier le signature du répondeur. Si aucun certificat n'est inclus, alors certs devrait être absent.
ResponseData ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    responderID ResponderID,
    producedAt GeneralizedTime,
    responses SEQUENCE OF SingleResponse,
    responseExtensions [1] EXPLICIT Extensions OPTIONAL }
    
    ResponderID ::= CHOICE {
    byName [1] Name,
    byKey [2] KeyHash }
    
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields)
    
SingleResponse ::= SEQUENCE {
    certID CertID,
    certStatus CertStatus,
    thisUpdate GeneralizedTime,
    nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
    singleExtensions [1] EXPLICIT Extensions OPTIONAL }
    
CertStatus ::= CHOICE {
    good [0] IMPLICIT NULL,
    revoked [1] IMPLICIT RevokedInfo,
    unknown [2] IMPLICIT UnknownInfo }
    
RevokedInfo ::= SEQUENCE {
    revocationTime GeneralizedTime,
    revocationReason [0] EXPLICIT CRLReason OPTIONAL }
    
UnknownInfo ::= NULL

Notes sur les réponses OCSP

   Les réponses peuvent contenir 4 dates -- thisUpdate, nextupdate, producedAt, et revocationTime. Les sémantiques de ces champs sont définis plus haut. Le format pour GeneralizedTime est définis dans la rfc5280.

   Les champs thisUpdate et nextUpdate définissent un intervalle de validité recommandé. Cet intervalle corresponds à l'interval {thisUpdate, nextUpdate} dans les CRL. Les réponses dont la valeur nextUpdate est avant l'heure système local devraient être considérés comme non sûr. Les réponses dont thisUpdate est ultérieur à la date système local devraient être considérés comme non-sûr.

   Si nextUpdate n'est pas mis, le répondeur indique que de nouvelles informations sont disponible tout le temps.

Répondeurs autorisés

   La clé qui signe les informations de statut d'un certificat n'a pas besoin d'être la même clé que celle qui a signé le certificat. Il est nécessaire, cependant, de s'assurer que l'entité qui signe ces informations est autorisée à le faire. Ainsi, un émetteur de certificat doit faire une des opérations suivantes:

- Signer les réponses OCSP lui-même
- Désigner explicitement cette autorité à une autre entité.

   La délégation de signature OCSP doit être désignée en incluant id-kp-OCSPSigning dans l'extension d'utilisation de clé étendue inclue dans le certificat du répondeur OCSP. Ce certificat doit être émis directement par la CA qui est identifiée dans la requête.

   La CA devrait utiliser la même clé pour émettre un certificat de délégation que celle utilisée pour signer le certificat à vérifier. Les systèmes s'appuyant sur les réponses OCSP doivent reconnaître un certificat de délégation comme étant émis par la CA qui a émis le certificat en question seulement si le certificat de délégation et le certificat à vérifier ont été signés par la même clé.

Note: Pour des raisons de compatibilité avec la rfc2560, il n'est pas interdit d'émettre un certificat pour un répondeur autorisé en utilisant une clé différente que la clé utilisée pour émettre le certificat à vérifier. Cependant, une telle pratique est fortement découragée, vu que les clients ne sont pas obligés de reconnaître un répondeur avec un tel certificat comme répondeur autorisé.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Les systèmes ou applications qui reposent sur les réponses OCSP doivent être capable de détecter et forcer l'utilisation de la valeur id-kp-OCSPSigning comme décris plus haut. Ils peuvent fournir un moyen de configurer localement une ou plusieurs autorités de signature OCSP et d-e spécifier un jeu de CA pour lesquelles chaque autorité de signature est validée. Ils doivent rejeter la réponse si le certificat exige de valider la signature dans la réponse qui ne rencontre pas un des critères suivants:

1. Correspond à une configuration locale de l'autorité de signature OCSP pour le certificat en question
2. Est le certificat de la CA qui a émis le certificat en question
3. Inclus une valeur id-kp-OCSPSigning dans l'extension d'utilisation de clé étendue et est émis par la CA qui a émis le certificat en question comme statué plus haut.

   D'autre critères d'acceptation ou de rejet peuvent d'appliquer à la réponse ou au certificat utilisé pour valider la signature dans la réponse.

Vérification de révocation d'un répondeur autorisé

   Vu qu'un répondeur OCSP autorisé fournis des informations de statut pour une ou plusieurs CA, les clients OCSP doivent savoir comment vérifier que le certificat d'un répondeur autorisé n'a pas été révoqué. Les CA peuvent choisir de répondre à ce problème d'une des 3 manières suivantes:

- Une CA peut spécifier qu'un client OCSP peut truster un répondeur pour la durée de vie du certificat du répondeur. La CA le fait en incluant l'extension id-pkix-ocsp-nocheck. Cette extension devrait être non-critique. La valeur de l'extension doit être null. Les CA émettant un tel certificat doivent réaliser qu'une clé de répondeur compromise est aussi sérieux que la compromission de la clé de la CA. utilisée pour signer les CRL, au moins pour la période de validité de ce certificat. Les CA peuvent choisir d'émettre ce type de certificat avec une durée de vie très courte et le renouveler fréquemment.
- Une CA peut spécifier comment le certificat du répondeur est vérifié pour la révocation. Cela peut être fait en utilisant les points de distribution de CRL si la vérification devrait être faite en utilisant les CRL, ou en utilisant les accès d'information de l'autorité si la vérification devrait être faite d'une autre manière.
- Une CA peut choisir de ne pas spécifier de méthode de vérification de révocation pour le certificat du répondeur, auquel cas il sera du ressort de la stratégie de sécurité locale du client OCSP de décider si ce certificat devrait être vérifié pour la révocation ou non.

Réponse de base

   Le type de réponse de base contient:

- La version de la syntaxe de réponse, qui doit être v1 (0) pour ce document
- Soit le nom du répondeur ou un hash de la clé publique du répondeur dans ResponderID.
- La date à laquelle la réponse a été générée.
- Les réponses pour chaque certificats dans une requête
- Des extensions optionnelles
- Une signature calculée via un hash de la réponse
- L'OID de l'algorithme de signature.

   Le but de l'information ResponderID est de permettre aux clients de trouver le certificat utilisé pour signer une réponse OCSP signée. Cependant, l'information doit correspondre au certificat qui a été utilisé pour signer la réponse. Le répondeur peut inclure des certificats dans le champ certs de BasicOCSPResponse qui aide le client OCSP à vérifier la signature du répondeur.

- Un identifiant du certificat pour lequel les informations de statut de révocation sont fournies
- Le statut de révocation du certificat (good, revoked, ou unknown); si révoqué, il indique la date à laquelle le certificat a été révoqué et, optionnellement, la raison de la révocation.
- L'intervalle de validité de la réponse
- Des extensions optionnelles.

   La réponse doit inclure un SingleResponse pour chaque certificat dans la demande. La réponse ne devrait pas inclure d'élément SingleResponse additionnels, mais, par exemple, les répondeurs OCSP qui pré-génèrent les réponses peuvent inclure des éléments SingleResponse additionnels si nécessaire pour améliorer les performances de pré-génération des réponses ou l'efficacité des cache.

Algorithmes cryptographiques obligatoires et optionnels

   Les clients qui requièrent les services OCSP doivent être capable de traiter les réponses signées en utilisant RSA avec SHA-256 (OID sh256WithRSAEntryption - rfc4055). Les clients devraient être également capable de traiter les réponses signées en utilisant RSA avec SHA-1 et DSA avec SHA-1. Les client peuvent supporter d'autres algorithmes.

Extensions

   Cette section définis des extensions standards, basées sur le modèle d'extension employé dans le certificats X.509v3. Le support pour toutes les extensions est optionnel pour les clients et les répondeurs. Pour chaque extension, la définition indique sa syntaxe, le traitement effectué par le répondeur, et les extensions qui sont incluses dans la réponse correspondante.

Nonce

Le nonce lie cryptographiquement une demande et une réponse pour empêcher les attaques replay. Le nonce est inclus comme une des requestExtensions dans les demandes, et est inclus dans les réponses comme une des responseExtensions. Dans la demande et la réponse, nonce sera identifié par l'identifiant d'objets id-pkix-ocsp-nonce, alors que extnValue est la valeur de nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
    
Nonce ::= OCTET STRING

CRL References

Il peut être désirable pour un répondeur OCSP d'indiquer la CRL dans laquelle un certificat revoqué ou onHold est trouvé. Cela peut être utile quand OCSP est utilisé entre des dépôts, et également comme mécanisme d'audit. La CRL peut être spécifiée par une URL, un numéro de CRL, ou une date de création de la crl. Ces extensions sont spécifiés comme singleExtensions. L'identifiant pour cette extension est ip-pkix-ocsp-crl, et la valeur est CrlID.
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
    
CrlID ::= SEQUENCE {
    crlUrl [0] EXPLICIT IA5String OPTIONAL,
    crlNum [1] EXPLICIT INTEGER OPTIONAL,
    crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }

   Pour le choix crlUrl, l'IA5String va spécifier l'URL à laquelle la CRL est disponible. Pour crlNum, l'INTEGER spécifique la valeur de l'extension crlNumber. Pour crlTime, le GeneralizedTime indique la date à laquelle la crl a été émise.

Type de réponse acceptable

Un client OCSP peut souhaiter spéifier le type de réponse qu'il comprend. Pour cela, il devrait utiliser une extension avec l'OID id-pkix-ocsp-response et la valeur AcceptableResponses. Cette extensio est inclue comme une des requestExtensions dans les demandes. Les OID inclus dans AcceptableResponses sont les OID des types de réponse que ce client peut accepter.
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
    
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   Comme noté plus haut, les répondeurs OCSP doivent être capable de répondre avec les réponses de type ip-pkix-ocsp-basic. Les clients OCSP doivent être capable de reçevoir et de traiter ce type de réponse également.

Archive Cutoff

   Un répondeur OCSP peut choisir de retenir les informations de révocation au-delà de l'expiration du certificat. La date obtenue en soustrayant cet intervalle de rétention de producedAt dans une réponse est définie comme la date "archive cutoff" du certificat.

   Les applications qui utilisent OCSP utilisent la date d'archive cutoff pour contribuer à une preuve qu'une signature numérique était ( ou n'était pas ) fiable à la date à laquelle elle a été produite même si sa signature a expiré depuis longtemps.

Les serveurs OCSP qui fournissent le support pour un tel historique devraient inclure l'extension Archive cutoff dans les réponses. Si inclus, cette valeur devrait être fournie comme extension singleExtensions idenitifié par id-pkix-ocsp-archive-cutoff et de syntaxe GeneralizedTime.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
    
ArchiveCutoff ::= GeneralizedTime

   Pour illustrer, si un serveur opère avec une stratégie de rétention de 7 ans et le statut a été produit au temp t1, alors la valeur ArchiveCutoff dans la réponse sera ( t1 -7 ans ).

Extensions d'entrée CRL

   Toutes les extensions spécifiées comme extensions d'entrée de CRL sont également supportés comme singleExtensions.

Service Locator

Un serveur OCSP peut être opéré dans un mode par lequel le serveur reçoit une demande et la route vers le serveur OCSP qui est connu pour avoir autorité pour le certificat identifié. L'extension de demande serviceLocator est définie dans ce but. Cette extension est inclue comme singleRequestExtensions dans le demandes
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
    
ServiceLocator ::= SEQUENCE {
    issuer Name,
    locator AuthorityInfoAccessSyntax OPTIONAL }

   Les valeurs pour ces champs sont obtenus depuis leur champs correspondants dans le certificat du sujet.

Algorithmes de signature préférés

   Vu que les algorithmes autre que ceux qui sont mandatoire sont permis, et vu qu'un client n'a pas de mécanisme pour indiquer ses préférences d'algorithme, il y a toujours un risque qu'un serveur choisisse un algorithme non obligatoire pour générer une réponse que le client ne supporte pas.

   Bien qu'un répondeur OCSP peut appliquer des règles pour la sélection d'algorithme, par exemple, en utilisant l'algorithme de signature employé par la CA pour signer les CRL et certificats, de telles règles peut échouer dans des situations communes:

- L'algorithme utilisé pour signer les CRL et les certificats ne peuvent pas être consistent avec la paire de clé utilisée par le répondeur OCSP pour signer les réponses.
- Une demande pour un certificat inconnu ne fournis pas de base pour qu'un répondeur sélectionne parmis plusieurs algorithmes.

   Le dernier critère ne peut pas être résolu via les information disponible en utilisant le protocole rfc2560 sans modifier le protocole.

   De plus, un répondeur OCSP peut souhaiter employer des algorithmes de signature différents de celui utilisé par la CA pour signer les certificats et les CRL pour 2 raisons:

- Le répondeur peut employer un algorithme qui est moins gourmand en calcul que pour la signature des certificats.
- Une implémentation peut souhaiter se prémunir de la possibilité d'un algorithme de signature compromis en employant 2 algorithmes de signature séparés.

   Cette section décrit une extension qui permet à un client d'indiquer le jeu d'argorithmes de signature préféré, et les règles pour la sélection de l'algorithme de signature qui maximise la probabilité de succès dans le cas où aucun algorithme préféré n'est spécifié.

Syntaxe d'extension

Un client peut déclarer un jeu d'algorithmes préféré dans une demande en incluant une extension d'algorithme de signature préféré dans requestExtensions de OCSPRequest:
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
    
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
    
PreferredSignatureAlgorithm ::= SEQUENCE {
    sigIdentifier AlgorithmIdentifier,
    pubKeyAlgIdentifier SMIMECapability OPTIONAL
}

   La syntaxe de AlgorithmIdentifier est définis dans la rfc5280. La syntaxe de SMIMECapability est définie dans la rfc5751.

   sigIdentifier spécifie l'algorithme de signature que le client préfère, par exemple, algorithm=ecdsa-with-sha256. Les paramètres sont absent pour la plupart des algorithmes de signatures communs.

   pubKeyAlgIdentifier spécifie l'identifiat d'algorithme de clé publique que le client préfère dans le certificat du serveur utilisé pour valider la réponse OCSP, par exemple, algorithm=id-ecPublicKey et parameters=secp256r1.

   pubKeyAlgIdentifier est optionnel et fournis un moyen de spécifier les paramètres nécessaires pour distinguer entre les différents usages d'un algorithme particulier, par exemple, il peut être utilisé par le client pour spécifier que courbe il supporte pour un algorithme à courbe elliptique.

   Le client doit supporter chacun des algorithmes de signature préférés spécifiés, et le client doit spécifier les algorithmes dans l'ordre de préférence.

Sélection de l'algorithme de signature

   La rfc2560 ne spécifie pas de mécanisme pour décider de l'algorithme de signature à utiliser dans une réponse OCSP. Cela ne fournis pas de niveau suffisant de certitude quant à l'algorithme choisi pour faciliter l'interopérabilité.

Réponse dynamique

   Un répondeur peut maximiser le potentiel pour assurer l'interopérabilité en sélectionnant un algorithme de signature supporté en utilisant l'ordre de préférence suivant. tant que l'algorithme sélectionné rencontre toutes les exigences de sécurité du répondeur OCSP, où le premier mécanisme sélectionné à la plus haute précédence:

1. Sélectionne un algorithme spécifié comme algorithme de signature préféré dans le demande du client
2. Sélectionne l'algorithme de signature utilisé pour signer une liste de révocation de certificat émis par l'émetteur du certificat en fournissant les informations de statut pour le certificat spécifié par CertID
3. Sélectionne l'algorithme de signature utilisé pour signer le OCSPRequest
4. Sélectionne un algorithme de signature qui a été déclaré comme algorithme de signature par défaut pour le service de signature en utilisant un mécanisme externe.
5. Sélectionne un algorithme obligatoire ou recommandé spécifié pour la version d'OCSP utilisé.

   Un répondeur devrait toujours appliquer le mécanisme de sélection ayant le plus faible numéro qui résulte dans la sélection d'un algorithme connu et supporté qui répond aux critères du répondeur pour la force de l'algorithme cryptographique.

Réponse statique

   Dans un but d'efficacité, un répondeur OCSP est autorisé à générer des réponses statiques à l'avance. Le cas ne permet pas au répondeur d'utiliser la demande du client durant la génération de la réponse; cependant, le répondeur devrait utiliser les données de la demande du client durant la sélection de la réponse pré-générée à retourner. Les répondeurs peuvent utiliser les demandes historiques du client comme partie de la décision de l'algorithme à utiliser pour signer les réponses pré-générées.

Définition de révocation étendue

   Cette extension indique que le répondeur supporte la définition étendue du statut "révoqué" pour inclure également les certificats non-émis. Un des buts premier est de permettre des audits pour déterminer le type d'opération du répondeur. Les clients n'ont pas à regarder cette extension pour déterminer le statut des certificats dans la réponse.

   Cette extension doit être incluse dans la réponse OCSP quand cette réponse contient un statut "révoqué" pour un certificat non-émis. Cette extension peut être présente dans d'autres réponses pour signaler que le répondeur implémente la définition révoqué étendue. Quand inclus, cette extension doit être placée dans responseExtensions, et ne doit pas apparaître dans singleExtensions.

Cette extension est identifiée par l'identifiant d'objet id-pkix-ocsp-extended-revoke
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

   La valeur de l'extension doit être null. Cette extension ne doit pas être marquée critique.

Considérations de sécurité

   Pour que ce service soit effectif, les systèmes utilisant les certificat doivent se connecter au fournisseur de service de statut du certificat. Dans le cas où une telle connexion ne peut être obtenue, ces systèmes peuvent implémenter le traitement de CRL.

   Une vulnérabilité à un DOS est évident. La production d'une signature cryptographique affecte significativement le temps de cycle de génération de signature. Les erreurs de réponses non-signées ouvrent le protocole à une autre attaque DOS, où l'attaquant envoie des réponses non-signées.

   L'utilisation de réponses pré-calculées permet de rejouer des attaques dans lequel une ancienne bonne réponse est rejouée avant sa date d'expiration mais après que le certificat ait été révoqué. Les déploiements d'OCSP devraient évaluer le bénéfice des réponses pré-calculées avec la probabilité d'une attaque replay et le coùt associé avec son exécution.

   Les requêtes ne contiennent pas le répondeurs auquels ils sont redirigés. Cela permet à un attaquant pour rejouer une demande à d'autres répondeurs OCSP

   La dépendance à l'égard de la mise en cache HTTP dans certains scénarios peut résulter en des résultats inattendus si les serveurs intermédiaires sont incorrectement configurés ou ont des fautes de gestion de cache. Les implémenteurs doivent s'assurer que les mécanismes de cache HTTP sont pris en compte en déployant OCSP sur HTTP.

   En répondant avec un état 'revoked' à un certificat qui n'a jamais été émis peut permettre à une personne d'obtenir une réponse de révocation pour une certificat qui n'a jamais été émis, mais qui sera bientôt émis, si le numéro de certificat du certificat qui sera émis peut être prédis ou deviné par le demandeur. Une telle prédiction est facile pour une CA qui émet des certificats en utilisant l'assignement de numéro de série séquentiel. Ce risque est géré dans la spécification en exigant des implémentations conformes à l'utilisation du code de raison certificateHold, qui évite de révoquer des numéros de série. Pour les CA qui supportent les réponses "revoked" pour les certificats non-émis, une manière d'éviter ce problème est d'assigner des numéros de série aléatoirement avec une forte entropy.

Algorithmes de signature préféré

   Le mécanisme utilisé pour choisir l'algorithme de signature de réponse doit être considéré comme suffisamment sécure contre les attaques pas cryptanalyse pour l'application prévue.

   Dans beaucoup d'applications, l'algorithme de signature au moins aussi sécurisé que l'algorithme utilisé pour signer le certificat original est suffisant. Cependant, ce critère ne peut pas être retenu dans des applications d'archivage à long terme, dans lequel le statut d'un certificat est demandé pour date dans le passé, longtemps après que l'algorithme de signature a cessé d'être considéré comme sûr.

Utilisation d'algorithmes non sécure

   Il n'est pas toujours possible pour un répondeur de générer une réponse que le client s'attend à comprendre et qui correspond aux standards contemporains pour la sécurité cryptographique. Dans de tels cas, un opération de répondeur OCSP doit jouer entre le risque d'employer une solution de sécurité compromise et le coùt d'une mise à jours, incluant le risque que l'alternative choisis par les utilisateurs finaux offre moins de sécurité ou aucune sécurité.

   Dans les applications d'archivage, il est possible qu'un répondeur OCSP ait une demande de répondre de la validité d'un certificat dans le passé. Un tel certificat peut employer une méthode de signature qui n'est plus considéré comme sécurisée. Dans de telles circonstances, le répondeur ne doit pas générer une signature en utilisant un mécanisme de signature qui n'est pas considérée comme suffisamment sûre.

   Un client doit accepter un algorithme de signature dans une réponse qui est spécifiée comme un algorithme de signature préféré dans la demande. Un client ne doit pas spécifier d'algorithme de signature préféré qu'il ne supporte pas ou ne considère pas comme suffisamment sûre.

Attaques MITM

   Le mécanisme pour supporter l'indication client des algorithmes de signature préférés n'est pas protégé contre les attaques par dégradation MITM. Cette contrainte n'est pas considéré comme un problème de sécurité significatif, vu que le répondeur OCSP ne doit pas signer les réponses en utilisant des algorithmes faibles même si demandé par le client. En plus, le client peut rejeter les réponses qui ne rencontrent pas ses critères.

Attaques DOS

   Les mécanismes d'algorithme définis dans ce document introduit une surface d'attaque légèrement meilleur pour les attaques DOS où la demande client est altérée pour exiger des algorithmes qui ne sont pas supportés par le serveur. Les considérations DOS discutées dans la rfc4732 sont pris en compte pour ce document.

Appendice A. OCSP sur HTTP

   Cette section décrit le formattage qui sera fait à la demande et la réponse pour supporter HTTP.

Demande

   Les demandes OCSP basées sur HTTP peut utiliser soit la méthode GET soit POST pour envoyer leurs demandes. Pour permettre le caching HTTP, des petites demandes (qui après encodage font moins de 255 octets) peut être envoyés en utilisant la méthode GET. Si le caching HTTP n'est pas important ou si la demande est supérieur à 255 octets, la demande devrait être envoyé via POST. Où la confidentialité est une exigence, les transactions OCSP en utilisant HTTP peut être protégés en utilisant SSL/TLS ou d'autre protocoles.

Une demande OCSP en utilisant la méthode GET est construite comme suit:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}

   Où {url} peut être dérivé de la valeur de l'extension d'information d'accès à l'autorité dans le certificat à vérifier, ou d'autres configurations locales du client OCSP.

   Une demande OCSP en utilisant la méthode POST est construite comme suit: le header Content-Type a la valeur "application/ocsp-request", alors que le body du message est une valeur binaire de l'encodage DER du OCSPRequest.

Réponse

   Une réponse OCSP basé sur HTTP est composée des en-tête HTTP appropriés, suivis par la valeur binaire de l'encodé DER du OCSPResponse. Le header Content-Type a la valeur "application/ocsp-response". Le header Content-Length devrait spécifier la longueur de la réponse. D'autres en-tête HTTP peut être présents et peuvent être ignorés s'ils ne sont pas compris par le demandeur.
^
05 août 2015

htmlpdflatexmanmd




rfc6024

rfc6024

Exigences de gestion d'ancre de confiance

   Une ancre de confiance représente une entité autoritative via une clé publique et des données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisée pour contraindre les types d'informations pour lesquelles l'ancre de confiance a autorité. Un tiers de confiance utilise les ancres de confiance pour déterminer si un objet signé numériquement est valide en vérifiant une signature numérique en utilisant la clé publique de l'ancre de confiance, et en forçant les contraintes exprimées dans les données associées pour l'ancre de confiance. Ce document décris certains problèmes associées avec le manque de mécanisme de gestion d'ancre de confiance et définis les exigences pour les formats de données et les protocoles conçus pour adresser ces problèmes.

   Les signatures numériques sont utilisées dans de nombreuses applications. Pour que les signatures numériques fournissent l'intégrité et d'authentification, la clé publique utilisée pour vérifier la signature numérique doit être "trustée", par exemple, accepté par un tiers de confiance comme utilisation appropriée dans le contexte donné. Une clé publique utilisée pour vérifier une signature doit être configurée comme une ancre de confiance ou contenue dans un certificat qui peut être vérifiée par une chemin de certification se terminant à l'ancre de confiance. Une ancre de confiance est une clé publique et ses données associées utilisée par un tiers de confiance pour valider une signature sur un objet signé où l'objet est soit:

- Un certificat à clé publique qui commence un chemin de certification terminé par un certificat de signature ou un certificat de chiffrement.
- Un objet, autre qu'un certificat à clé publique ou liste de révocation de certificat, qui ne peut pas être validé via l'utilisation d'un chemin de certification.

   Les ancres de confiance ont seulement une signification locale, par exemple, chaque tiers de confiance (RP) est configuré avec un jeu d'ancres de confiance, soit par le RP ou par l'entité qui gère les TA dans le contexte dans lequel le RP opère. Les données associées définissent le périmètre d'une ancre de confiance en imposant des contraintes sur les signatures qui peuvent être vérifiés en utilisant l'ancre de confiance. Par exemple, si une ancre de confiance est utilisée pour vérifier les signatures dans le certificats X.509, ces contrainte peuvent inclure une combinaison d'espace de noms, de stratégie de certificat, ou de types d'application/utilisation.

   Une utilisation des signatures numérique est la vérification des signatures dans les packages de firmware chargés dans les modules hardware, tels que les modules cryptographiques, boitiers de cables, routeurs, etc. Vu que de tels périphériques sont souvent gérés à distance, les périphériques doivent être capable d'authentifier la source d'interaction de gestion et peuvent utiliser les ancres de confiance pour effectuer cette interaction. Cependant, les ancres de confiance nécessitent également une gestion. D'autres applications nécessitant une gestion d'ancre de confiance incluent les navigateurs web ( qui utilisent les ancres de confiance en authentifiant les serveurs web) et les clients mail ( qui utilisent les ancres de confiance en validant les email signés et en authentifiant les bénéficiaires des mails chiffrés ).

   Toutes les applications qui valident les signatures numériques valide les moyens de gérer un ou plusieurs jeux d'ancre de confiance. Chaque jeu d'ancre de confiance est référé dans ce document à un magasin d'ancres de confiance. Souvent, la manière de gérer les magasins d'ancre de confiance est spécifique à l'application et compte sur des moyens tiers pour établir et maintenir la fiabilité. Une application peut utiliser plusieurs magasins d'ancre de confiance, et un magasin d'ancre de confiance peut être utilisé par plusieurs applications. Chaque magasin d'ancre de confiance est gérée par au moins un gestionnaire TA; un gestionnaire TA peut gérer plusieurs magasins TA.

   Les exigences statuées dans ce document ont été préparés avant la publication des rfc5914 et rfc5934. Le document n'a pas été publié à ce moment pour permettre des changement dans les exigences durant le développement des spécification technique associées. Les exigences décrites ci-dessous sont celles qui ont été considérées durant le développement des rfrc5914 et rfc5934.

   Cette section fournis une introduction et définis la terminologie de base. La section suivante décris les problèmes avec les méthodes de gestion d'ancre de confiance actuelles. Les sections suivantes décrivent les exigences et considérations de sécurité pour une solution de gestion d'ancre de confiance.

Terminologie

   Les termes suivants sont définis pour pouvoir fournir un vocabulaire pour les exigences décrites pour la gestion des ancres de confiance.

Trust Anchor Une ancre de confiance représente une entité autoritative via une clé publique et ses données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisées pour contraindre les types d'information pour lesquels l'ancre de confiance est autoritative. Un tiers de confiance utilise les ancres de confiance pour déterminer si un objet signé numériquement est valide en vérifiant une signature numérique utilisant la clé publique de l'ancre de confiance, et en forçant les contraintes exprimées dans les données associées pour l'ancre de confiance.
Trust Anchor Manager Un gestionnaire d'ancre de confiance est une entité responsable de la gestion du contenu d'un magasin d'ancre de confiance. Tout au long de ce document, chaque gestionnaire d'ancre de confiance est assumé être représenté comme, ou délégué par une ancre de confiance distincte.
Trust Anchor Store Un magasin d'ancre de confiance est un jeu d'une ou plusieurs ancres de confiance stockés dans un périphérique. Un magasin d'ancre de confiance peut être géré par un ou plusieurs gestionnaire d'ancre de confiance. Un périphérique peut avoir plus d'un magasin d'ancre de confiance, chaque pouvant être utilisé par une ou plusieurs applications.

Énoncé des problèmes

   Les ancres de confiance sont utilisées pour supporter de nombreux scénarios d'application. Beaucoup de navigateurs internet et le clients mail utilisent les ancres de confiance lors de l'authentification de sessions TLS, en vérifiant les mails signés, et en générant des mails chiffrés en validant un chemin de certification avec le certificat du serveur, le certificat de l'émetteur d'un mail, ou le certificat du destinataire d'un mail. De nombreuses distributions de logiciels sont signées numériquement pour permettre l'authentification des sources du logiciel avant l'installation. Les ancres de confiance qui supportent ces application sont typiquement installés comme partie de l'OS ou application, installés durant un système de gestion de configuration de l'entreprise, ou installé directement par un OU ou une utilisateur.

   Les ancres de confiance sont généralement stockés dans des magasins d'ancre de confiance spécifique à l'application ou spécifique à l'OS. Souvent, une simple machine peut avoir de nombreux magasins d'ancre de confiance qui ne peuvent pas être synchronisés. Examiner le contenu d'un magasin d'ancre de confiance particulier implique généralement l'utilisation d'un outil propriétaire qui interagi avec un type particulier de magasin.

   La présence d'une ancre de confiance dans un magasin particulier véhicule souvent l'autorisation implicite de valider les signatures pour tous les contextes pour lequel le magasin est accédé. Par exemple, la clé publique d'une autorité d'horodatage peut être installée dans un magasin pour valider les signatures dans les horodatages. Cependant, si le magasin contenant ce TA est utilisé par plusieurs applications qui servent différents bit, la même clé pourrait être utilisée de manière inappropriée pour valider d'autres types d'objets tels que les certificats ou les réponses OCSP. Avant la publication de la rfc5914, il n'y avait pas de mécanisme standard pour limiter le périmètre d'une ancre de confiance. Une pratique commune pour adresser ce problème est de placer différents TA dans différents magasins et de limiter le jeu d'application qui accèdent à un magasin TA donné.

   La relation de confiance entre les PKI sont négociées par des autorité de stratégie. Les négociations exigent fréquemment un temps significatif pour s'assurer que toutes exigences des parties participantes sont satisfaites. Ces exigences sont exprimées, dans une certaine mesure, dans les certificats à clé publique via les contraintes de stratégie, les contraintes de noms, etc. Pour pouvoir forcer ces exigences, les magasins d'ancre de confiance doivent être gérés en accord avec les intensions d'autorité de stratégie. Sinon, les contraintes définies dans un cross-certificat pourrait être contournées en reconnaissant le sujet du cross-certificat comme ancre de confiance, qui permettrait d'implémenter des traitement de chemin qui évitent le cross-certificat.

   Les ancres de confiance sont souvent représentés comme des certificats autos-signés, qui ne fournissent généralement aucun moyen d'établir la validité de l'information contenu dans le certificat. La confiance dans l'intégrité d'une ancre de confiance est généralement établie via un moyen externe, souvent en vérifiant l'empreinte du certificat auto-signé avec une source autoritative. Les Opérations de routine d'ancre de confiance nécessitent généralement de telles vérifications externe, si la livraison de la clé d'une ancre de confiance est supportée par CMP. Idéalement, seul le jeu initial d'ancres de confiance qui sont installés dans un magasin de confiance particulier nécessitent une vérification tiers proportionnée avec les exigences de sécurité des applications en utilisant le magasin.

   Malgré d'utilisation répandue des ancres de confiance, il n'y a ni standard pour la découverte du jeu d'ancres de confiance installés dans un magasin particulier ni de moyen standard de gérer ces ancres de confiance. Le reste de ce document décris les exigences pour une solution à ce problème avec certaines considérations de sécurité.

Exigences

   Cette section décris les exigences pour un protocole de gestion d'ancre de confiance. Les exigences sont fournies pour le contenu d'une ancre aussi bien que les opération de gestion des magasins.

Indépendance de transport

   Une solution générale pour la gestion des ancres de confiance doit être indépendant du transport pour pouvoir s'appliquer à divers environnements de communication. Il doit fonctionner dans des environnements orientés session et store-and-forward aussi bien que dans les modèles push and pull. Pour répondre à tous ces modèles de manière uniforme, l'intégrité sans connexion et l'authentification de l'origine des données pour les transaction TA doivent être fournis au niveau applicatif. La confidentialité peut être fournie pour de telles transactions.

Raisonnement

   Tous les périphériques qui utilisent les ancres de confiance ne sont pas disponible pour des opérations de gestion online; certains périphériques peut nécessiter une interaction manuelle pour la gestion des ancres de confiance. L'authentification de l'origine des données et l'intégrité sont requis pour s'assurer que la transaction n'a pas été modifiée en route. Seul l'intégrité sans connexion est requise, pour compatibilité avec les contextes store-and-forward.

pré-requis fonctionnels

   Au minimum, un protocole utilisé pour la gestion d'ancre de confiance doit permettre à un gestionnaire d'ancre de confiance d'effectuer les opérations suivantes:

- Déterminer quels ancres de confiance sont installées dans un magasin particulier
- Ajouter une ou plusieurs ancres de confiance à un magasin
- Supprimer une ou plusieurs ancres de confiance d'un magasin
- Remplacer tout un magasin

   Un protocole le gestion d'ancre de confiance doit fournir un support pour ces opérations basiques; cependant, toutes les implémentations ne supportent pas chaque options. Par exemple, certaines implémentations peuvent supporter seulement le remplacement des magasins.

   Ces exigences décrivent les opérations requises pour gérer le contenu d'un magasin d'ancre de confiance. Une opération d'édition a été omise pour des raisons de simplicité, avec des suppressions consécutives et opérations d'ajouts utilisés dans ce but. Une simple opération d'ajout ou suppression peut agir sur plus d'une ancre de confiance pour éviter les aller-retours inutiles et sont fournis pour éviter le besoins de toujours remplacer tout un magasin. Le remplacement d'un magasin peut être utile comme une opération alternative aux opérations d'ajouts et suppression.

Gestion des cibles

   Une protocole pour la gestion TA doit permettre à une transaction TA d'être dirigée vers:

- Tous les magasins TA dont le manager est responsable
- Une liste énumérée d'un ou plusieurs groupes nommés de magasins
- un magasin d'ancre de confiance individuel

   Les connexions entre les PKI peuvent être accomplies en utilisant différents moyens. La cross-certification unilatérale ou bilatérale peut être effectuée, ou une communauté peut simplement élire pour accepter explicitement une ancre de confiance depuis une autre communauté. Généralement, ces décisions se font dans l'entreprise. Dans certains scénarios, il peut être utile d'établir ces connexions pour une petite communauté dans une entreprise. Les mécanismes des grandes entreprises, tel que les cross-certificats sont mal adaptés à cet effet vu que la révocation du certificat affecte l'ensemble de l'entreprise.

   Un protocole de gestion d'ancre de confiance peut adresser ce problème en supportant l'installation limitée des ancres de confiance (ex, l'installation des TA dans des sous-jeux de communauté d'utilisateurs de l'entreprise), et en supportant l'expression des contraintes dans l'utilisation des ancres de confiance par des tiers de confiance. L'installation limitée nécessite la capacité d'identifier les membre de la communauté qui sont destinés à s'appuyer sur une ancre de confiance particulière, et la capacité de vérifier et reporter le contenu des magasins. Les contraintes d'ancre de confiance peuvent être utilisés pour représenter les limitations qui peuvent être exprimées dans un cross-certificat, et l'installation limitée assure que la reconnaissance de l'ancre de confiance ne comprend par nécessairement toute une entreprise.

   Les configuration d'ancre de confiance peuvent être uniforme dans une entreprise, ou peuvent être unique à une simple application ou un petit jeu d'applications. De nombreux périphériques et certaines application utilisent plusieurs magasins. En fournissant un moyen d'adresser un magasin spécifique ou une collection de magasins, un protocole de gestion d'ancre de confiance peut permettre une gestion efficace de tous les magasins sous le contrôle d'un gestionnaire d'ancre de confiance.

Délégation de l'autorité du gestionnaire TA

   Un protocole de gestion d'ancre de confiance doit permettre un transfert sécurité du contrôle d'un magasin d'ancre de confiance d'une manager à un autre. Il devrait également permettre la délégation pour les opérations spécifiques sans nécessiter de délégation de toutes les capacités de gestion d'ancres de confiance.

   Le renouvellement de clé du gestionnaire d'ancre de confiance est un type de transfert qui doit être supporté. Dans ce cas, la nouvelle clé sera assignée aux mèmes privilèges que l'ancienne clé.

   La création des ancres de confiance pour des buts spécifiques, tels que la signature de firmware, est un autre exemple de délégation. Par exemple, un gestionnaire d'ancre de confiance peut déléguer seulement d'autorité de signer des firmware à une entité, mais interdit d'autres délégations de ce privilège, ou le gestionnaire d'ancre de confiance peut autorisé la délégation à d'autres autorités de signature de firmwares délégués à d'autres entités.

Support rfc 5280

   Un protocole de gestion d'ancre de confiance doit permettre la gestion des ancres de confiance qui seront utilisé pour valider les chemins de certification et les CRL en accord avec les rfc5280 et rfc5055. Un format d'ancre de confiance doit permettre la représentation de contraintes qui influencent la validation de chemin de certification ou l'établissement de périmètre d'utilisation de la clé publique de l'ancre de confiance. Des exemples de telles contraintes sont les contraintes de noms, les stratégies de certificat, et l'utilisation de clé.

   La validation de chemin de certification est une des applications d'ancre de confiance les plus communes. Les règles pour utiliser les ancres de confiance pour la validation de chemin sont établis dans la rfc5280. La rfc5055 décris l'utilisation des ancres de confiance pour la validation de chemin déléguée. Les ancres de confiance utilisée pour valider les chemins de certification sont responsable de la livraison, possiblement via une délégation, des informations de statut de révocation des certificats qu'il émet; c'est souvent accomplis en signant une CRL.

Autres supports

   Un protocole de gestion d'ancre de confiance doit permettre la gestion des ancres de confiance qui peuvent être utilisé pour d'autres buts que la validation de chemin de certification, incluant les ancres de confiance qui ne peuvent pas être utilisé pour la validation de chemin de certification. Il devrait être possible d'autoriser une ancre de confiance à déléguer l'autorité (à d'autres TA ou propriétaires de certificat) et d'empêcher une ancre de confiance d'être délégué.

   Les ancres de confiance sont utilisées pour valider une variété d'objets signés, pas seulement les certificats à clé publique et les CRL. Par exemple, une ancre de confiance peut être utilisée pour vérifier les packages de firmware (rfc5108), les réponses OCSP (rfrc2560), les réponses SCVP (rfc5055), ou les horodatages (rfc3161). Les TA qui sont autorisées pour l'utilisation de certains de ces types d'opérations ne peuvent pas être autorisés pour vérifier les certificats à clé publique ou les CRL. Donc, il est important d'être capable d'imposer des contraintes sur la manière dont un TA donné est employé.

Format d'ancre de confiance

   Au minimum, un protocole de gestion d'ancre de confiance doit supporter la gestion des ancres de confiances représentés comme certificats auto-signés et les ancres de confiance représentés comme un nom distinct, informations de clé publique, et, optionnellement, les données associées. La définition d'une ancre de confiance doit inclure une clé publique, un algorithme de clé publique, et, si nécessaire, les paramètres de la clé publique. Quand la clé publique est utilisée pour valider les chemins de certification ou les CRL, un nom distinct doit également être inclus (rfc5280). Un format d'ancre de confiance doit permettre la spécification d'un identifiant de clé publique pour permettre à d'autres applications d'ancre de confiance, par exemple, la vérification des données signées en utilisant la structure SignedData (CMS - rfc5652). Un format d'ancre de confiance devrait également permettre la représentation des contraintes qui peuvent être appliquées pour restreindre l'utilisation d'une ancre de confiance.

   Avant la publication de la rfc5914, il n'y avait pas de format d'ancres de confiance. Les certificats X.509 auto-signés sont généralement utilisés, mais la rfc5280 ne mandate par la représentation d'ancre de confiance particulier. Elle exige seulement que les information de clé publique de l'ancre de confiance et le nom distinct soit disponible durant la validation du chemin de certification. CMS est largement utilisé pour protéger divers types de contenu en utilisant les signatures numériques, incluant le contenu qui peut être vérifié directement en utilisant une ancre de confiance, tels que les packages de firmware. Les contraintes peuvent inclure une périodes de validité, des contraintes sur la validation de chemin de certification, etc.

Authentification

   Une entité reçevant une donnée de gestion d'ancre de confiance doit être capable d'authentifier l'identité du partie en fournissant les informations et doit être capable de confirmer que le partie est autorisé à fournir ces informations.

   Un gestionnaire d'ancre de confiance doit être capable d'authentifier quel magasin d'ancre correspond à un listing du contenu du magasin et être capable de confirmer que le contenu du listing n'a pas été altéré.

   L'authentification de l'origine des données et l'intégrité sont requis pour supporter les opération de gestion à distance, même quand les transaction de gestion des TA sont effectuées via des communications store-and-forward.

Réduire la dépendance des mécanimes tiers

   En effectuant des opérations d'ajout, un protocole de gestion d'ancre de confiance devrait permettre de vérifier automatiquement l'intégrité des TA par un tiers de confiance sans s'appuyer sur des mécanismes tiers.

   Traditionnellement, une ancre de confiance est distribuée via un mécanisme tiers avec vérification manuelle de l'intégrité avant l'installation. L'installation est généralement effectuée par quelqu'un avec suffisamment de privilèges administratifs dans le système recevant l'ancre de confiance. La fiabilité des mécanismes de confiance tiers est un problème avec les approches de gestion des ancre de confiance actuelles, et la réduction du besoin de mécanismes tiers est une motivation principale pour le développement de mécanismes de gestion d'ancre de confiance. Idéalement, les mécanismes tiers sont requis seulement durant l'initialisation du magasin.

Détection des répétitions

   Un protocole de gestion d'ancre de confiance doit permettre aux participants engagés dans l'échange du protocole de gestion de détecter les attaques replay. Un mécanisme de détection de replay qui n'introduit pas d'exigence pour une source sûre de temps doit être disponible. Les mécanismes qui ne nécessitent pas de source sûre de temps peuvent être disponibles.

   La détection de replay des transactions de gestion d'ancre de confiance est requise pour supporter les opérations de gestion distantes. Le replay d'anciennes transaction pourraient résulter en la réintroduction d'ancres de confiance compromises. Certains périphériques qui utilisent les ancres de confiance n'ont pas accès à une source de temps sûre, donc un mécanisme de détection de replay qui nécessite une source de temps sûre est insuffisant.

Compromission ou récupération après sinistre

   Un protocole de gestion d'ancre de confiance doit permettre la récupération lors de la compromission ou la perte de la clé privée d'une ancre de confiance, incluant la clé privée autorisée à service de gestion d'ancre de confiance, sans nécessiter la ré-initialisation du magasin.

   La compromission ou la perte d'une clé privée correspondant à une ancre de confiance peut avoir des conséquences négatives significatives. Actuellement, dans certains cas, la ré-initialisation de tous les magasin affectés est requise pour récupérer lors d'une perte ou d'une compromission d'une clé d'ancre de confiance. À cause du coût associés avec la ré-initialisation, un protocole de gestion d'ancre de confiance devrait supporter les options de récupération qui ne nécessitent pas de ré-initialisation du magasin.

Considérations de sécurité

   La clé publique utilisé pour authentifier une transaction de gestion TA peut avoir été placée dans le client comme résultat d'une première transaction de gestion TA ou durant une configuration initiale. Dans de nombreux scénarios, au moins une clé publique autorisé pour la gestion d'ancre de confiance doit être placée dans chaque magasin d'ancre de confiance. Cette clé publique peut être transporté et vérifiée en utilisant des moyens tiers. Dans tous les scénarios, sans regarder le mécanisme d'authentification, au moins un gestionnaire d'ancre de confiance doit être établis pour chaque magasin d'ancre de confiance durant la configuration initiale du magasin.

   La compromission d'une clé privée d'une ancre de confiance peut résulter en de nombreux problèmes de sécurité, incluant l'émission de sécurité compromis ou des ancres de confiance volé.

   L'utilisation de contraintes basées sur l'ancre de confiance nécessite une grande attention en définissant les ancres de confiance. Des erreurs de la part d'un gestionnaire pourrait résulter des déni de service ou des conséquences de sécurité sérieuses. Par exemple, si une contrainte de nom pour une ancre de confiance qui sert de racine d'une PKI inclus une faute de frappe, il en résulte un déni de service pour les propriétaires de certificats. Si un gestionnaire d'ancre de confiance délègue par inadvertance tous ses privilège et les délégations suppriment le gestionnaire d'ancre de confiance des magasins d'ancre de confiance sous son contrôle, la récupération peut nécessiter la ré-initialisation de tous les magasins d'ancre de confiance affectés.

   La rfc5280 nécessite que la validation de chemin de certificat soit initialisée avec un nom du sujet TA et une clé publique, mais n'exige pas le traitement d'autres information, tels quel les contraintes de nom. L'inclusion de contraintes dans les ancres de confiance est optionnelle. Quand des contraintes sont explicitement incluse par un gestionnaire d'ancre de confiance en utilisant un protocole de gestion d'ancre de confiance, on s'attend à ce que l'algorithme de validation de chemin de certification utilise ces contraintes. Les propriétaires d'application doivent confirmer l'implémentation de traitement de chemin supportant le traitement des contraintes basées sur TA, si requis.

   De nombreuses considération de sécurité de la rfc5280 sont également applicable à la gestion des ancres de confiance.
^
05 août 2015

htmlpdflatexmanmd




rfc5937

rfc5937

Utilisation des contraintes d'ancre de confiance durant le traitement de chemin de certification

   Ce document décris comment utiliser les informations utilisée avec une clé publique d'ancre de confiance lors de la validation de chemin de certification. Cette information peut être utilisée pour contraindre l'utilisation d'une ancre de confiance. Typiquement, les contraintes sont utilisées pour limiter les stratégies de certificat et les noms qui peuvent apparaître dans les chemins de certification validés en utilisant une ancre de confiance.

   Les ancres de confiance sons largement utilisés pour vérifier les signatures numérique et la validation de chemin de certification (rfc5280). Il sont requis pour la validation de chemin de certification. La spécification du format de l'ancre de confiance (rfc5914) définis un moyen pour limiter le périmètre dans lequel une ancre de confiance peut être utilisée. La rfc5280 décris comment valider un chemin de certification. L'algorithme exige de traiter le nom et la clé depuis une ancre de confiance. L?utilisation d'autres informations, incluant le renforcement de contraintes, est permis mais non requis, et le traitement des règles ne sont pas spécifiés.

   Ce document définis un mécanisme pour identifier les contraintes qui devraient être forcés et les règles de traitement supplémentaires. Les règles supplémentaires spécifient une entrée additionnels et étendent les procédures d'initialisation dans l'algorithme de validation de chemin (rfc5280), les étapes de traitement post-initialisation ne sont pas affectés.

Identifier le contraintes d'ancre de confiance

   TAF supporte 3 formats pour représenter les informations d'ancre de confiance: TrustAnchorInfor, Certificate, et TBSCertificate. Dans les 3 cas, les contraintes d'ancre de confiance peut être représentée comme extensions. Dans la structure TrustAnchorInfor, les stratégies de certificat, contraintes de stratégie, les contraintes de noms, inhibitAnyPolicy, et les contraintes de bases n'apparaîssent pas comme extensions et apparaîssent dans le champ CertPathControls.

   Les extensions peuvent être marquées critique ou non. Quand les contraintes d'ancre de confiance sont forcées, les clients doivent rejeter les chemins de certification contenant une ancre de confiance avec des extensions critique non-reconnues. Quand les contraintes d'ancre de confiance ne sont pas forcées, les clients peuvent accepter les chemins de certification contenant une ancre de confiance avec les extensions critique non-reconnues. Les informations apparaissant dans le champ CertPathControls d'un objet TrustAnchorInfo doit être traité, pour s'assurer que les contraintes indiquées par ce champ sont forcés dans tous les cas.

   Pour certains types de contrainte d'ancre de confiance, il y a un manque de concordance entre les paramètres pour l'algoritme de validation de chemin de certification et l'extension qui contient la contrainte. L'algorithme de validation de chemin de certification définis essentiellement l'initial-any-policy-inhibit, initial-policy-mapping-inhibit et initial-explicit-policy comme valeurs booléennes. les extensions inhibitAnyPolicy et policyConstraints qui correspondent à ces entrées sont exprimées en valeurs entières. Dans les étapes décrites ci-dessous, la présence de l'extension inhibitAnyPolicy résulte dans la valeur initial-any-policy-inhibit à TRUE. Si une extension policyConstraints est présente et contient un champ requireExplicitPolicy, la valeur initial-explicit-policy est à TRUE. Si une extension policyConstraints est présente et contient un champ inhibitPolicyMapping, la valeur initial-policy-mapping-inhibit est à TRUE.

Utiliser les contraintes durant le traitement de chemin de certification

   Cet algorithme assume que les 9 entrées définies dans la rfc5280 sont fournis au traitement de chemin, plus une variable additionnelle:

enforceTrustAnchorConstraints Indique si les contraintes de l'ancre de confiance devraient être forcés

   Les implémentations conformes ne sont pas obligés de supporter ce paramètre. Si une implémentation ne supporte pas le paramètre de ce flag, il doit valider tous les chemins de certification en utilisant une valeur de TRUE pour enforceTrustAnchorConstraints.

Initialisation

   Si enforceTrustAnchorConstraints vaut false, aucune étape additionnelle n'est requise. Si enforceTrustAnchorConstraints vaut true, les étapes additionnelles suivante doivent être effectuées. Ces étapes (ou équivalentes) doivent être effectuées avant les étapes d'initialisation décrites dans la rfc5280.

- Si aucun nom distinct du sujet n'est associé avec l'ancre de confiance, la validation de chemin échoue. Le nom peut apparaître dans le champ subject d'un certification ou une structure TBSCertificate ou dans le champ taName de CertPathControls dans une structure TrustAnchorInfo.
- Si les contraintes de nom sont associées avec l'ancre de confiance, définis la variable initial-permitted-subtrees égale à l'intersection des permitted subtrees de l'ancre de confiance et de l'uinitial-permited-subtrees fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournie, la variable initial-permited-subtrees est définis à la valeur qui est disponible. Si aucun n'est fournis, la variable est définie à un jeu infinis.
- Si les contraintes de nom sont associées avec l'ancre de confiance, définis la variable initial-excluded-subtrees égal à l'union des excluded subtrees de l'ancre de confiance et de l'initial-excluded-subtrees fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournis, la variable est mis à la valeur qui est disponible. Si aucune n'est fournis, la variable est définie à un jeu vide.
- Si les stratégies de certificat sont associées avec l'ancre de confiance, définis la variable user-initial-policy-set égal à l'intersection des stratégies de certificat associés avec l'ancre de confiance et le user-initial-policy-set fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournie, la variable est définie à la valeur qui est disponible. Si aucune de ces valeurs n'est fournie, définis la variable à any-policy.
- Si une valeur inhibitAnyPolicy à TRUE est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension inhibitAnyPolicy) et que la valeur initial-any-policy-inhibit vaut false, définis la valeur initial-any-policy-inhibit à true.
- Si une valeur de stratégie explicite requise est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension policyConstraints) et que la valeur initial-explicite-policy vaut false, définis la valeur initial-explicit-policy à true.
- Si une valeur de mappage d'inhibition de stratégie est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension PolicyConstraints) et que la valeur initial-policy-mapping-inhibit vaut false, définis la valeur initial-policy-mapping-inhibit à true.
- Si une extension de contrainte de base est associée avec l'ancre de confiance et contient une valeur pathLenConstraint, défins la variable d'état max_path_length égal à la valeur pathLenConstraint de l'extension de contrainte de base.

Traitement de certificat de base

   Ce document n'exige pas d'augmentation d'étapes de traitement de certificat de base. Cepenadnt, certains types de contraintes d'ancre de confiance peuvent avoir définis des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Préparation pour le certificat i+1

   Ce document ne nécessite aucune augmentation des étapes pour préparer le traitement du certificat i+1. Cependant, certains types de contraintes d'ancre de confiance peuvent avoir définies des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Procédure wrap-up

   Ce document ne nécessite pas d'augmentation d'étapes de procédure d'enveloppement. Cependant, certains types de contraintes d'ancre de confiance peuvent avoir définies des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Relations à la rfc5280

   Le traitement décris ci-dessous peut être incorporé dans une implémentation rfc5280 ou être implémenté comme pré-traitement aux entrées rfc5280 et post-traitement des sorties rfc5280.

   Pour les contraintes de nom et les contraintes liées aux stratégies, le pré-traitement peut être utilisé, fournissant à l'implémentation rfc5280 la configuration des valeurs d'entrée user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, initial-any-policy-inhibit, initial-permitted-subtrees, et initial-excluded-subtrees. La rfc5280 ne définis pas d'entrée pour les contraintes de longueur de chemin, donc les contraintes de bases ne peuvent pas être implémentées en utilisant un pré-traitement. Il peut être implémenté comme post-traitement.

   Certains types de contraintes d'ancre de confiance peuvent imposer des exigences additionnelles à l'implémentation rfc5280 pour supporter le pré-traitement et le post-traitement pour forcer les contraintes des ancres de confiance.

Considérations de sécurité

   Les implémentations qui ne forcent par les contraintes d'ancre de confiance peuvent accepter certains chemins de certification rejetés par les implémentations qui imposent les contraintes d'ancre de confiance. Par exemple, une application qui ne force pas une contrainte de stratégie de certificat inclus dans une ancre de confiance peut accepter les certificats émis sous une stratégie de certificat qui fournis un niveau d'assurance plus faible que le niveau requis.

   Les informations d'ancre de confiance doivent être stockées de manière sécurisée. Les changements d'information d'ancre de confiance peut impliquer l'acceptation de certificat qui devraient être rejetés. Par exemple, si une définition d'ancre de confiance est altérée pour supprimer une contrainte de noms, les applications peuvent accepter les certificats contenant les noms qui n'auraient été validés que dans des certificats validés par une ancre de confiance différente. Similairement, l'ajout d'ancres de confiance inapproprié à un dépôt d'ancre de confiance peut résulter en une validation de certificats via une ancre de confiance différente et avec des contraintes différente.

   La rfc5914 et rfc5934 fournissent des considérations de sécurité additionnelles au regard de la préparation, le stockage, et l'utilisation d'ancres de confiance. La rfc5280 fournis des considérations de sécurité additionnelles au regard de l'utilisation des contraintes de nom.
^
05 août 2015

htmlpdflatexmanmd




rfc5914

rfc5914

Format d'ancre de confiance

   Ce document décris une structure pour représenter les informations d'ancre de confiance. Une ancre de confiance est une entité autoritative représentée par une clé publique et des données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisée pour contraindre les types d'information ou actions pour lesquelles l'ancre de confiance a autorité. Les structures définies dans ce document sont prévus pour satisfaire les exigences liées au format définis dans les exigencse de gestion d'ancre de confiance.

   Les ancres de confiance sons largement utilisées pour vérifier les signatures numériques et valider les chemins de certification. Ils sont requis pour valider les chemins de certification. Bien que largement utilisés, il n'y a pas de format standard pour représenter les informations d'ancre de confiance. ce document décris la structure TrustAnchorInfo. Cette structure est prévue pour satisfaire les exigences liées au format exprimées dans les exigences de gestion d'ancre de confiance ( rfc6024 ) et est exprimée en utilisant ASN.1. Il peut fournir une alternative plus compact aux certificats X.509 pour échanger les informations d'ancre de confiance et fournir un moyen d'associer des contraintes additionnelles ou alternatives avec les certificats sans casser la signature dans le certificat.

Syntaxe d'information d'ancre de confiance

Cette section décris la structure TrustAnchorInfo:
TrustAnchorInfo ::= SEQUENCE {
    version TrustAnchorInfoVersion DEFAULT v1,
    pubKey SubjectPublicKeyInfo,
    keyId KeyIdentifier,
    taTitle TrustAnchorTitle OPTIONAL,
    certPath CertPathControls OPTIONAL,
    exts [1] EXPLICIT Extensions OPTIONAL,
    taTitleLangTag [2] UTF8String OPTIONAL }
    
TrustAnchorInfoVersion ::= INTEGER { v1(1) }

Version

   La version identifie la version de TrustAnchorInfo. De futures mises à jours de ce document peuvent inclure des changements dans cette structure, auquel cas le numéro de version devrait être incrémenté. Cependant, la valeur par défaut, v1, ne peut pas être changée.

Clé publique

   pubKey identifie la clé publique et l'algorithme associé avec l'ancre de confiance en utilisant la structure SubjectPublicKeyInfo (rfc5280). La structure SubjectPublicKeyInfo contient l'identifiant d'algorithme suivi par la clé publique elle-même. Le champ algorithm est un AlgorithmIdentifier, qui contient un identifiant d'objet et des paramètres optionnels. L'identifiant d'objet nomme l'algorithme de clé publique et indique la syntaxe des paramètres, si présent, aussi bien que le format de la clé publique. La clé publique est encodée en chaîne de bits.

Titre de l'ancre de confiance


TrustAnchorTitle ::= UTF8String (SIZE (1..64))

   taTitle est optionnel. Si présent, il fournis un nom compréhensible pour l'ancre de confiance. Le texte est encodé en UTF-8. Le champ taTitleLangTag identifie la langue utilisée pour exprimer le taTitle. Quand taTitleLangTag est absent, l'englais ("en") est utilisé. La valeur de taTitleLangTag devrait être un tag de langue comme décris dans la rfc5646.

Contrôles de chemin de certification


CertPathControls ::= SEQUENCE {
    taName Name,
    certificate [0] Certificate OPTIONAL,
    policySet [1] CertificatePolicies OPTIONAL,
    policyFlags [2] CertPolicyFlags OPTIONAL,
    nameConstr [3] NameConstraints OPTIONAL,
    pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}

   certPath est optionnel. Si présent, il fournis les contrôles nécessaires pour initialiser une implémentation d'algorithme de validation de certification X.509. Si absent, l'ancre de confiance ne peut pas être utilisée pour valider la signature dans un certificat X.509.

   taName fournis le nom distinct X.500 associé avec l'ancre de confiance, et ce nom distinct est utilisé pour construire et valider un chemin de certification X.509. Le nom ne doit pas être une séquence vide.

   certificate fournis un certificat X.509 optionnel, qui peut être utilisé dans certains environnements pour représenter l'ancre de confiance dans le développement et la validation du chemin de certification. Si le certificat est présent, le nom du sujet dans le certificat doit correspondre exactement le nom distinct X.500 fournis dans le champ taName, la clé publique doit correspondre exactement à la clé publique dans le champ pubKey, et l'extension subjectKeyIdentifier, si présent, doit correspondre exactement l'identifiant de clé dans le champ keyId. La description complète de la syntaxe et les sémantiques du certificat sont fournis dans la rfc5280. Les contraintes définies dans les champs policySet, policyFlags, nameConstr, pathLenConstraint, et exts dans TrustAnchorInfo remplacent les valeurs contenues dans un certificat ou fournissent des valeurs pour les extensions non présente dans le certificat. Les valeurs définies dans ces champs TrustAnchorInfo sont toujours forcés. Les extensions inclues dans un certificat sont forcés seulement s'il n'y a pas de valeur correspondante dans le TrustAnchorInfo. La correspondance entre les extensions dans le certificat et les champs TrustAnchorInfo sont définis comme suit:

- une extension de certificat id-ce-certificatePolicies correspond au champ CertPathControls.policySet
- une extension de certificat id-ce-policyConstraints correspond au champ CertPolicyFlags.inhibitPolicyMapping et CertPolicyFlags.requireExplicitPolicy
- Une extension de certificat id-ce-inhibitAnyPolicy correspond au champ CertPolicyFlags.inhibitAnyPolicy
- Une extension de certificat id-ce-nameConstraints correspond au champ CertPathControls.nameConstr
- Le champ pathLenConstraint d'une extension de certificat id-ce-basicConstraints correspond au champ CertPathControls.pathLenConstraint ( La présence d'une structure CertPathControls correspond à une valeur TRUE dans le champ cA de l'extension BasicConstraints )
- Toute autre extension de certificat correspond au même type d'extension dans le champ TrustAnchorInfo.exts


CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
    
PolicyInformation ::= SEQUENCE {
    policyIdentifier CertPolicyId,
    policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }
    
CertPolicyId ::= OBJECT IDENTIFIER

   policySet est optionnel. Si présent, il contient une séquence d'identifiant de stratégie de certificat fournis en entrée de l'algorithme de validation de chemin de certification. Si absent, la valeur spéciale any-policy est fournie comme entrée de l'algorithme de validation de chemin de certification. La description complète de la syntaxe et des sémantiques de CertificatePolicies sont fournis dans la rfc5280, incluant la syntaxe PolicyInformation. Dans ce contexte, la structure optionnelle policyQualifiers ne doit pas être inclue.


CertPolicyFlags ::= BIT STRING {
    inhibitPolicyMapping (0),
    requireExplicitPolicy (1),
    inhibitAnyPolicy (2) }

   policyFlags est optionnel. Si présent, 3 valeurs booléennes pour l'entrée dans l'algorithme de validation de chemin de certification sont fournis dans un BIT STRING. Si absent, l'entrée de l'algorithme de validation de chemin de certification est { FALSE, FALSE, FALSE }, qui représente le paramètre le plus libéral de ces flags. Ces 3 bits sont utilisés comme suit:

- inhibitPolicyMapping indique si le mappage de stratégie est autorisé dans le chemin de certification. Quand mis à TRUE, le mappage de stratégie n'est pas permis. Cette valeur représente la valeur d'entrée initial-policy-mapping-inhibit dans l'algorithme de validation de chemin de certification décris dans la rfc5280.
- requireExplicitPolicy indique si le chemin de certification doit être valide pour au moins une des stratégies de certificat dans le policySet. À TRUE, tous les certificats dans le chemin de certification doivent contenir un identifiant de stratégie acceptable dans l'extension de stratégie de certificat. Cette valeur représente la valeur d'entrée initial-explicit-policy dans l'algorithme de validation de chemin de certification décris dans la rfc5280. Un identifiant de stratégie acceptable est un membre du policySet ou l'identifiant d'une stratégie qui est déclarée équivalente via le mappage de stratégie. Ce bit doit être à FALSE si policySet est absent.
- inhibitAnyPolicy indique si l'identifiant de stratégie anyPolicy, avec la valeur { 2 5 29 32 0 }, est considéré un match explicite pour d'autres stratégies de certificat. Cette valeur représente la valeur d'entrée initial-any-policy-inhibit dans l'algorithme de validation de chemin de certification décris dans la rfc5280.


NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees [1] GeneralSubtrees OPTIONAL }
    
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
    
GeneralSubtree ::= SEQUENCE {
    base GeneralName,
    minimum [0] BaseDistance DEFAULT 0,
    maximum [1] BaseDistance OPTIONAL }
    
BaseDistance ::= INTEGER (0..MAX)

   nameConstr est optionnel. Il a la même syntaxe et sématiques que l'extension de certificat de contrainte de noms, qui inclue une liste de noms permis et une liste de noms exclus. La définition de GeneralName peut être trouvée dans la rfc5280. Quand il est présent, les contraintes sont fournies sur les noms (incluant les noms alternatifs) qui doivent apparaître dans le certificats X.509 sous-jacents dans un chemin de certification. Ce champ est utilisé pour définir les valeurs d'entrée initial-permitted-subtrees et d'initial-excluded-subtrees dans l'algorithme de validation de chemin de certification décris dans la rfc5280. Quand ce champ est absent, la variable initial-permitted-subtrees n'est pas limitée et la variable initial-excluded-subtrees est vide.

   Le champ pathLenConstraint donne le nombre maximum de certificats intermédiaire non-auto-émis qui peuvent suivre ce certificat dans un chemin de certification valide. ( Note: le dernier certificat dans le chemin de certification n'est pas un certificat intermédiaire et n'est pas inclus dans cette limite. Généralement, le dernier certificat est en certificat EE, mais il peut être un certificat CA). Un pathLenConstraint de 0 indique qu'aucun certificat d'autorité de certification intermédiaire non-auto-émis ne peut suivre dans le chemin de certification. Quand il apparaît, le champ pathLenConstraint doit être supérieur ou égal àl 0. Quand il n'apparaît pas, aucune limite n'est imposée.

   Quand l'ancre de confiance est utilisée pour valider un chemin de certification, CertPathControls fournis les limitations dans le chemins de certification qui seront validés avec succès. Une application qui valide un chemin de certification ne devrait pas ignorer ces limitations, mais l'application peut imposer des limitations additionnelles pour s'assurer que le chemin de certification validé est approprié pour le contexte applicatif prévu. Comme entrée de l'algorithme de validation de chemin de certification, une application peut:

- Fournir un sous-jeu de stratégies de certification fournies dans le policySet
- Fournir une valeur TRUE, si approprié, pour les flags dans le policyFlags
- Fournir un sous-jeu de noms permis fournis dans nameConstr
- Fournir des noms exclus additionnels à ceux fournis dans le nameConstr
- Fournir une valeur plus petite pour pathLenConstraint

Extensions

   exts est optionnel. Si présent, il peut être utilisé pour associer des informations additionnelles avec l'ancre de confiance en utilisant la structure Extensions standard. Les extensions qui sont prévus pour être largement utilisé ont été inclus dans la structure CertPathControls pour éviter une surchage associée avec l'utilisation de la structure Extensions. Pour éviter la duplication avec le champ CertPathControls, les types d'extensions suivants ne doivent pas apparaître dans le champ exts et sont ignorés s'il n'apparaissent: id-ce-certificatePolicies, id-ce-policyConstraints, id-ce-inhibitAnyPolicy, et id-ce-nameConstraints.

Liste d'ancre de confiance

   TrustAnchorInfo permet la représentation d'une simple ancre de confiance. Dans de nombreux cas, il est préférable de représenter une collection d'ancre de confiance. La structure TrustAnchorList est définie dans ce but. TrustAnchorList est définis comme une séquence d'un ou plusieurs objects TrustAnchorChoice. TrustAnchorChoice fournis 3 options pour représenter une ancre de confiance. L'option certificat permet d'utiliser un certificat sans contraintes additionnelles. L'option tbsCert permet d'associer des contraintes en supprimant un signature dans un certificat et en changeant le champ extensions. L'option taInfo permet d'utiliser une structure TrustAnchorInfo définis dans ce document.


TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice
    
TrustAnchorChoice ::= CHOICE {
    certificate Certificate,
    tbsCert [1] EXPLICIT TBSCertificate,
    taInfo [2] EXPLICIT TrustAnchorInfo }
    
trust-anchor-list PKCS7-CONTENT-TYPE ::= { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }

   La structure TrustAnchorList peut être protégée en utilisant la structure SignedData définis dans CMS. L'identifiant d'objet id-ct-trustAnchorList a été définis pour représenter le payloads TrustAnchorList avec les structure CMS.

Considérations de sécurité

   La compromission d'une clé privée d'ancre de confiance permet à des tiers non-autorisés d'usurper l'ancre de confiance, avec des conséquences potentiellement sévères. Quand des contraintes basés sur TA sont forcés, une personne non-autorisée ayant la clé privée sera limité par les contrôles de chemin de certification associés avec l'ancre de confiance, comme exprimé dans les champs certPath et exts. Par exemple, les contraintes de nom dans l'ancre de confiance vont déterminer l'espace de nom qui sera accepté dans le certificats qui sont validés en utilisant l'ancre de confiance compromise. Le recours à une clé publique d'un ancre de confiance inapproprié ou incorrect a des conséquences potentiellement sévères.

   La compromission d'une clé privée de CA a le même type de problème que la compromission de clé privée d'une ancre de confiance. Une entité non autorisée possédant la clé privée de la CA sera limité par les contrôles de chemin de certification associés avec l'ancre de confiance, comme exprimé dans le champ certPath ou comme extension.

   L'utilisation d'un certificat indépendant de la structure TrustAnchorinfo qui l'enveloppe doit être géré avec prudence pour éviter de violer les contraintes exprimées dans le TrustAnchorInfo. En enveloppant un certificat dans une structure TrustAnchorinfo, les valeurs inclues dans le certificat devraient être évalués pour s'assurer qu'il n'y a pas de confusion ou de conflit avec les valeurs dans la structure TrustAnchorinfo.
^
28 juillet 2015

htmlpdflatexmanmd




rfc3739

rfc3739

Profile de certificats qualifiés

   Ce document forme un profile de certificat, basé sur la rfc3280, pour les certificat d'identité émis à des personnes naturelles.

   Le profile définis les conventions spécifiques pour les certificats qui sont qualifiés avec un framework définis, les Certificat Qualifiés nommés. Cependant, le profile ne définis aucune exigence légale pour de tels certificats qualifiés.

   Le but de ce document est de définir un profile de certificat qui supporte l'émission de certificat qualifiés indépendamment des exigences légales. Le profile n'est cependant pas limité aux certificats qualifiés et le profile peut simplifier les besoins locaux.

   Cette spécification fait partie d'une famille de standards pour la PKI X.509 de l'Internet. Elle est basées sur X.509 et la rfc3280, qui définissent les formats de certificat sous-jacent nécessaire à l'implémentation complète de ce standard.

Exigences et hypothèses

   Ce terme "Qualified Certificate" est utilisé par la directive européenne pour les signature électroniques (EU-ESDIR) pour référer à un type spécifique de certificats, en conformité avec la législation européenne sur la signature électronique. Cette spécification est prévue pour supporter cette classe de certificats, mais son périmètre n'est pas limité à cette application.

   Dans ce standard, le terme "Qualified Certificate" est utilisé généralement, décrivant un certificat dont le but premier est d'identifier une personne avec un haut niveau d'assurance, où le certificat répond à des exigences de qualification définie par un framework légale applicable, tels que la directive européenne sur la signature électronique. Les mécanismes actuels qui décident si un certificat devrait ou non être considéré comme certificat qualifié au regard de la législation est hors du périmètre de ce standard.

   L'harmonisation dans le champs des certificats d'identité émis aux personnes naturelles, en particulier les certificats qualifiés, est essentiel dans de nombreux aspects qui sont hors du périmètre de la rfc3280. Les aspects les plus important qui affectent le périmètre de cette spécification sont:

- Définition des noms et informations d'identité pour pouvoir identifier le sujet associé d'une manière uniforme
- Définition des informations qui identifient la CA et la juridiction sous laquelle la CA opère en émettant un certificat particulier.
- Définition de l'extension d'utilisation de clé pour les certificats qualifiés
- Définition de la structure d'informations pour le stockage d'informations biométriques.
- Définition d'une méthode standardisée de stocker des états pré-définis d'intérêt pour des certificats qualifiés.
- Exigences pour les extensions critiques

Propriétés

   Ce profile adapte les besoins de profilage pour les certificats qualifiés basés sur les hypothèses que:

- Les certificats qualifiés sont émis par une CA qui qui déclare que le certificat sert le but d'un certificat qualifié
- Le certificat qualifié indique une stratégie de certificat conforme aux engagements, pratiques, et procédures entrepris par la CA.
- Le certificat qualifié est émis à une personne naturelle.
- Le certificat qualifié contient un nom qui peut être soit basé sur le vrai nom du sujet ou un pseudonyme.

Déclaration d'intention

   Ce profile définis les conventions pour déclarer dans un certificat qu'il sert l'objectif d'être un certificat qualifié. Cela permet à la CA de définir explicitement cette intention.

   Ce profile définis 2 méthodes pour inclure cette information:

- Comme information définie par une stratégie de certificat inclue dans l'extension de stratégies de certificat
- Comme déclaration inclue dans l'extension de déclaration de certificats qualifiés.

problématique de stratégie

   Certains aspects de stratégie définissent le contexte dans lequel ce profile est compris et utilisé. Il est cependant en dehors du scope de ce profile de spécifier une stratégie ou les aspects légaux qui vont gouverner les services qui émettent ou utilisent les certificat en accord avec ce profile.

   C'est cependant un hypothèse sous-jacente dans ce profile qu'une CA émettrice responsable va entreprendre de suivre une stratégie de certificat qui est consistante avec ses engagements, pratiques et procédure.

Unicité des noms

   Les noms distincts sont initialement définis dans X.501 comme représentation d'un nom d'annuaire, définis comme une construction qui identifie un objet particulier parmi un ensemble de tous les objets. Le nom distinct doit être unique pour chaque sujet certifié par une CA comme définie par le champ issuer, pour toute la durée de vie d'une CA.

Profile de certificat et d'extensions de certificat

   Cette section définis les conventions de profile de certificat. Le profile est basé sur le profile de certificat de l'Internet (rfc3280), qui lui-même est basé sur le format X.509v3. Pour une implémentation complète de cette section, les implémenteurs doivent consulter les formats et sémantiques définies dans la rfc3280.

Champs de certificat de base

   Cette section fournis des détails au regard du contenu de 2 champs dans le certificat de base. Ces champs sont issuer et subject.

Issuer

   Le champ issuer devrait identifier l'organisation responsable de l'émission du certificat. Le nom devrait être un nom officiellement enregistré de l'organisation.

   Le nom distinct de l'émetteur devrait être spécifié en utilisant le sous-jeu approprié les attributs suivants:

domainComponent
countryName
stateOrProvinceName
organizationName
localityName
serialNumber

   L'attribut domainComponent est définis dans la rfc2247, tous les autres attributs sont définis dans la rfc3280 et X.520.

   Des attributs additionnels peuvent être présent, mais ils ne doivent pas être nécessaires pour identifier l'organisation émettrice.

   Un tiers de confiance peut avoir à consulter les stratégies de certificat associés et/ou la CPS de l'émetteur, pour pouvoir déterminer les sémantiques du nom des champs.

Subject

   Le champs subject d'un certificats conforme avec ce profile devrait contenir un nom distinct du sujet. Le champ subject devrait contenir un sous-jeu des attributs suivants:

domainComponent
countryName
commonName
surname
givenName
pseudonym
serialNumber
title
organizationName
organizationUnitName
stateOrProvinceName
localityName

   Des attributs additionnels peuvent être présent, mais ils ne doivent pas être nécessaires pour distinguer un nom de sujet d'un autre nom de sujet. C'est à dire, les attributs listés ci-dessus sont suffisant pour s'assurer de l'unicité des noms de sujet.

   De ces attributs, le champs sujet devrait inclure au moins un des suivants:

Choix I: commonName
Choix II: givenName
Choix III: pseudonym

   La valeur de l'attribut countryName spécifie un contexte général dans lequel d'autres attributs sont compris. L'attribut country n'indique pas nécessairement le pays de citoyenneté ou de résidence du sujet, ni n'indique le pays d'émission.

   Note: de nombreuses implémentations X.500 nécessitent la présence de countryName dans le DIT. Dans les cas où le nom du sujet, comme spécifié dans le champ subject, spécifie une entrée d'annuaire X.500, l'attribut countryName devrait toujours être présent.

   L'attribut commonName devrait, si présent, contenir un nom du sujet. Cela peut être dans le format de présentation préféré du sujet, ou un format préféré par la CA, ou un autre format. Les pseudonymes, surnoms, et noms ayant une orthographe autre que définie par le nom enregistré peut être utilisé. Pour comprendre la nature du nom présenté dans commonName, les applications conformes peuvent avoir à examiner les valeurs présentes des attributs givenName et surname, ou l'attribut pseudonym.

   Note: de nombreuses implémentations client pré-supposent la présence de la valeur de l'attribut commonName dans le champ subject et utilisent cette valeur pour afficher le nom du sujet sans regarder la présence de givenName, surname, ou pseudonym.

   Les types d'attribut surname et givenName devraient être utilisés dans le champ suject si ni l'attribut commonName ni l'attribut pseudonym n'est présent. Dans les cas où le sujet a seulement givenName, l'attribut surname devrait être omis.

   Le type d'attribut pseudonym devrait, si présent, contenir un pseudonyme du sujet. L'utilisation de l'attribut pseudonym ne doit pas être combiné avec l'utilisation de l'attribut surname et/ou givenName.

   Le type d'attribut serialNumber devrait, si présent, être utilisé pour différencier entre les noms où le champ subject serait sinon identique. Cet attribut n'a pas de sémantique définie au-delà de s'assurer de l'unicité des noms des sujets. Il peut contenir un nombre ou un code assigné par la CA ou un identifiant assigné par un gouvernement ou une autorité civile. C'est de la responsabilité de la CA de s'assurer que le serialNumber est suffisant à résoudre toute collision du nom du sujet.

   Le type d'attribut title devrait, si présent, être utilisé pour stocker une position désignée ou fonction ou sujet dans l'organisation spécifiée par les attributs organisationnelle présent dans le champs subject. L'association entre le titre, le sujet, et l'organisation est au-delà du périmètre de ce document.

   Les types d'attribut organizationName et organizationalUnitName, si présents, sont utilisé pour stocker le nom et les informations essentielles d'une organisation avec lequel le sujet est associé. Le type d'association entre l'organisation et le sujet est au-delà du périmètre de ce document.

   Les types d'attribut stateOrProvinceName et localityName devraient, si présents, être utilisés pour stocker les information géographiques avec lequel le sujet est associé. Si une valeur organizationName est également présente, les valeurs d'attribut stateOrProvinceName et localityName devraient être associés avec l'organisation spécifiée. Le type d'association entre stateOrProvinceName et localityName et soit le subject ou organizationName est au-delà du périmètre de ce document.

   Les implémentations conformes devraient être capable d'interpréter les attributs nommés dans cette section.

Extensions de certificat

   Cette section fournis des détails additionnels sur le contenu des 4 extensions de certificats définis dans la rfc3280: subjectAltName, subjectDirectoryAttributes, certificate policies, et key usage. Cette section définis également 2 extensions additionnelles: informations biométriques et déclaration de certificat qualifié.

Subject Alternative Name

   Si l'extension subjectAltName est présent, et qu'elle contient un directoryName, alors le directoryName doit suivre la convention spécifié dans la section subject plus haut dans ce document.

Subject Directory Attributes

   L'extension subjectDirectoryAttributes peut être présente et peut contenir des attributs additionnels associés avec le sujet, comme complément aux informations présentes dans le champ subject et l'extension subjectAltName.

   Les attributs prévus pour le stockage dans cet extension sont les attributs qui ne font pas partie du nom distinct du sujet, mais qui peuvent être utiles pour d'autres buts (ex: autorisation). Cette extension ne doit pas être marquée critique.

   Les implémentations conformes devraient être capable d'interpréter les attributs suivants:

- dateOfBirth
- placeOfBirth
- gender
- countryOfCitizenship
- countryOfResidence

   D'autres attributs peuvent être inclus en accord avec les définitions locales.

   L'attribut dateOfBirth devrait, si présent, contenir la valeur de la date de naissance du sujet. La manière dans laquelle la date de naissance est associée avec le sujet est hors du périmètre de ce document. La date de naissance est définis au format GeneralizedTime et devrait préciser GMT 12.00.00 (midi) jusqu'à la granularité des secondes, pour empêcher les changements de date accidentels lié aux ajustement de zone. Par exemple, une date de naissance du 27 Septembre 1959 est encodé "19590927120000Z". Une application qui lit un certificat conforme devrait ignorer toute donnée de temps et simplement présenter la date contenue sans ajustement de zone.

   L'attribut placeOfBirth devrait, si présent, contenir la valeur du lieu de naissance du sujet. La manière dans laquelle le lieu de naissance est associé avec le sujet est au-delà du périmètre de ce document.

   L'attribut gender devrait, si présent, contenir la valeur du genre du sujet. Pour une femme la valeur 'F' ou 'f', et pour un homme la valeur 'M' ou 'm', doivent être utilisés. La manière dont le genre est associé avec le sujet est hors du périmètre de ce document.

   L'attribut countryOfCitizenship devrait, si présent, contenir l'identifiant d'au-moins un des pays de citoyenneté du sujet au moment où le certificat a été délivré. Si plus d'un pays est spécifié, chaque pays devrait être spécifié via un attribut countryOfCitizenship séparé. La détermination de la citoyenneté est une question de droit et est hors du périmètre de ce document.

   L'attribut countryOfResidence devrait, si présent, contenir la valeur d'au-moins un pays dans lequel le sujet réside. Si plus d'un pays de résidence est spécifié, chaque pays de résidence devrait être spécifié via un attribut countryOfResidence séparé. La détermination de résidence est une question de droit et est hors du périmètre de ce document.

Stratégies de certificat

   L'extension de stratégie de certificat devrait être présent et devrait contenir l'identifiant d'au-moins une stratégie de certificat qui reflète les pratiques et procédures utilisées par la CA. L'extension de stratégie de certificat peut être marquée comme critique.

   Les informations fournies par l'émetteur statuant le but du certificat, devrait être évident au travers de la stratégie indiquée.

   L'extension de stratégie de certificat doit inclure toutes les informations de stratégie nécessaire pour la validation de chemin de certification. Si les déclarations de stratégie connexes sont incluses dans l'extension QCStatements, alors ces déclarations devraient également être contenues dans les stratégies identifiées.

   Les stratégies de certificat peuvent être combinées avec tout qualifiant définis dans la rfc3280.

Utilisation de clé

   L'extension d'utilisation de clé devrait être présent. Les paramètres d'utilisation de clé devraient être définis en accord avec les définitions de la rfc3280. D'autres exigences sur les paramètres d'utilisation de clé peuvent être définis par stratégie locale et/ou exigences légales. L'extension d'utilisation de clé devrait être marqué critique.

Informations biométriques

   Cette section définis une extension optionnelle pour stocker les informations biométriques. Les informations biométriques sont stockés sous la forme d'un hash d'un modèle biométrique.

   Le but de cette extension est de fournir un moyen pour l'authentification d'information biométrique. Les informations biométriques qui correspondent au hash stocké ne sont pas stockés dans cette extension, mais l'extension peut inclure une URI (sourceDataUri) qui référence un fichier contenant cette information.

   Si inclus, l'URI doit utiliser le schéma http:// ou https://. Vu que les données d'identification en cours de vérification peuvent elles-même être des information sensibles, ceux qui déploient ce mécanisme peuvent également souhaiter considérer l'utilisation des URI qui ne peuvent pas être facilement liés par des tiers aux identités de ceux dont l'information est en cours de récupération.

   L'utilisation de l'option URI assume que le format d'encodage des données du contenu du fichier est déterminé via des moyens au-delà du périmètre de cette spécification, tel que les conventions de nommage de fichier et les méta-données dans le fichier. L'utilisation de cette URI n'implique pas que c'est la seule manière d'accéder à cette information.

   Il est recommandé que les informations biométriques dans cette extension soient limitées aux types d'informations utilisable pour la vérification humaine, par ex., lorsque la décision de savoir si l'information est une représentation précise du sujet est effectuée naturellement par une personne. Cela implique une utilisation où les informations biométriques soient représentée par, par exemple, une image affichée par le tiers de confiance, qui peut être utilisé par le tiers de confiance pour améliorer l'identification du sujet.

Cette extension ne doit pas être marquée critique.
biometricInfo EXTENSION ::= {
    SYNTAX BiometricSyntax
    IDENTIFIED BY id-pe-biometricInfo }
    
id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2}
    
BiometricSyntax ::= SEQUENCE OF BiometricData
    
BiometricData ::= SEQUENCE {
    typeOfBiometricData TypeOfBiometricData,
    hashAlgorithm AlgorithmIdentifier,
    biometricDataHash OCTET STRING,
    sourceDataUri IA5String OPTIONAL }
    
TypeOfBiometricData ::= CHOICE {
    predefinedBiometricType PredefinedBiometricType,
    biometricDataID OBJECT IDENTIFIER }
    
PredefinedBiometricType ::= INTEGER { picture(0),
    handwritten-signature(1)} (picture|handwritten-signature,...)
    

   L'image de type biométrique prédéfinie, si présent, devrait identifier que l'image source est sous la forme d'une image graphique affichable du sujet. Le hash de l'image graphique devrait être calculée sur tout le fichier image référencé.

   L'handwritten-signature de type biométrique prédéfinis, si présent, devrait identifier que la source de donnée est sous la forme d'une image graphique affichable de la signature manuscrite du sujet. Le hash de l'image graphique devrait être calculé sur tout le fichier image référencé.

Déclaration de certificat qualifié

   Cette section définis une extension optionnelle pour inclure les déclaration de propriétés explicites du certificat.

   Chaque déclaration devrait inclure un identifiant d'objet pour la déclaration et peut également inclure une donnée qualifiante optionnelle contenue dans le paramètre statementInfo.

   Si le paramètre statementInfo est inclus, alors l'identifiant d'objet de la déclaration devrait définir la syntaxe et devrait définir les sémantiques de ce paramètre. Si l'identifiant d'objet ne définis pas les sémantiques, un tiers de confiance peut avoir à consulter une stratégie de certificat ou CPS pour déterminer les sémantiques exactes.

   Cette extension peut être critique ou non. Si l'extension est critique, cela signifie que toutes les déclarations inclues dans l'extension sont considérés comme critique.


qcStatements EXTENSION ::= {
    SYNTAX QCStatements
    IDENTIFIED BY id-pe-qcStatements }
    
-- Note: cette extension en permet pas de mixer les déclarations de certificat qualifiés
-- critique et non-critique. Soit tout est critique, soit tous sont non-critique.
    
id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 }
    
QCStatements ::= SEQUENCE OF QCStatement
QCStatement ::= SEQUENCE {
    statementId QC-STATEMENT.&Id({SupportedStatements}),
    statementInfo QC-STATEMENT.&Type({SupportedStatements}{@statementId}) OPTIONAL }
    
SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}

   Une déclaration approprié pour cette extension peut être une déclaration par l'émetteur que le certificat est émis comme certificat qualifié en accord avec un système légal particulier.

   D'autres déclarations appropriés pour cette extension peuvent être des déclaration liées aux juridictions légales applicables dans lequel le certificat est émis. Par exemple, on peut inclure une limite de confiance maximale pour le certificat indiquant les restrictions de la responsabilité de la CA.

Déclaration prédéfinies

   La déclaration de certificat (id-qcs-pkixQCSyntax-v1), identifie la conformité avec les exigences définis dans la rfc3039 obsolète. Cet déclaration est fournie pour l'identification des anciens certificats émis en conformité avec la rfc3039. Cette déclaration ne doit pas être inclue dans les certificats émis en accord avec ce profile.

   Ce profile inclus une nouvelle déclaration de certificat qualifié (identifié par l'OID id-qcs-pkixQCSyntax-v2), identifiant la conformité avec les exigences définies dans ce profile. Ce profile de certificat qualifié est référé à la version 2.

Cette déclaration identifie la conformité avec les exigences de la rfc3039. Cette déclaration peut optionnellement contenir des informations de sémantique additionnelles comme spécifié plus bas:
qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }

Cette déclaration identifie la conformité avec les exigences définis dans ce profile de certificat qualifié. Cette déclaration peut optionnellement contenir des informations de sémantiques additionnelles comme spécifié plus bas:
qcStatement-2 QC-STATEMENT ::= { SYNTAX SemanticsInformation IDENTIFIED BY id-qcs-pkixQCSyntax-v2 }
    
SemanticsInformation ::= SEQUENCE {
    semanticsIdentifier OBJECT IDENTIFIER OPTIONAL,
    nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL }
    (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
    WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
    
NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   Le composant SemanticsInformation identifié par id-qcs-pkixQCSyntax-v1 peut contenir un identifiant de sémantique et peut identifier un ou plusieurs nom d'autorité d'enregistrement.

   Le composant semanticsIdentifier, si présent, devrait contenir un OID, définissant les sémantiques pour les attributs et les noms dans les champs de base du certificat et les extensions. L'OID peut définir les sémantiques pour tout, ou pour un sous-groupe de tous les attributs présents et/ou les noms.

   Le composant NameRegistrationAuthorities, si présent, devrait contenir un nom d'une ou plusieurs autorité d'enregistrement, responsable pour l'enregistrement des attributs ou noms associés avec le sujet. L'association entre un nom identifié d'autorité d'enregistrement et les attributs présents peuvent être définis par un OID de sémantique, par une CP ou CPS, ou autre facteurs implicites.

   Si une valeur de type SemanticsInformation est présente dans un QCStatement où le composant statementID est mis à id-qcs-pkig-QCSyntax-v1 ou id-qcs-pkix-QCSyntax-v2, alors au moins un des champs semanticsIdentifier ou nameRegistrationAuthorities doit être présent, comme indiqué. Noter que le composant statementInfo ne doit pas être présent dans une valeur QCStatement même si le composant statementID est mis à id-qcs-pkix-QCSyntax-v1 ou id-qcs-pkix-QCSyntax-v2.

Considérations de sécurité

   La valeur légale d'une signature numérique qui est validée avec un certificat qualifié dépend hautement de la stratégie gouvernant l'utilisation de la clé privée associée. Le propriétaire de la clé privée, et le tiers de confiance, devraient s'assurer que la clé privée est utilisée uniquement avec le consentement du propriétaire légitime de la clé.

   Vu que les clés publiques sont pour une utilisation publique avec des implications légales pour les parties concernées, certaines conditions devraient exister avant qu'une CA émette des certificat comme certificats qualifiés. Les clés privées associées doivent être unique pour le sujet, et doivent être maintenue sous le contrôle exclusif du sujet. C'est à dire, une CA ne devrait pas émettre un certificat qualifié si les moyens d'utiliser une clé privée ne sont pas protégés contre les utilisation non-prévues. Cela implique que la CA ait une certaine connaissance du module cryptographique du sujet.

   La CA doit de plus vérifier que la clé publique contenue dans le certificat représente légitimement le sujet.

   La CA ne devrait pas émettre de certificats CA avec les extensions de mappage de stratégie indiquant l'acceptation d'une autre stratégie de CA sauf si les conditions sont rencontrées.

   En combinant le bit de nonRepudiation dans l'extension d'utilisation de clé avec d'autres bits d'utilisation de clé peut avoir des implication de sécurité en fonction du contexte dans lequel le certificat est utilisé. Les applications validant les signature électronique basés sur de tels certificats devraient déterminer si la combinaison d'utilisation de clé est approprié pour leur utilisation.

   La capacité de comparer 2 certificats qualifiés pour déterminer s'ils représentent la même entité physique est dépendante des sémantiques des noms des sujets. Les sémantiques d'une attribut particulier peut être différent pour différent émetteurs. En comparant les noms sans connaître les sémantiques des noms dans ces certificats particulier peut fournir de faux résultats.

   Cette spécification est un profile de la rfc3280. Les considérations de sécurité de ce document s'appliquent à cette spécification également.
^
24 juillet 2015

htmlpdflatexmanmd




rfc3647

rfc3647

Framework de stratégie de certificat et de pratiques de certification

Introduction

   En général, un certificat à clé publique lie une clé publique maintenue par une entité (telle qu'une personne, une organisation, compte, périphérique, ou site) à un jeu d'informations qui identifient l'entité associée avec l'utilisation de la clé privée correspondante. Dans beaucoup de cas impliquant des certificats d'identité, cette entité est connue comme le "subject" ou "subscriber" du certificat. 2 exceptions cependant, incluant les périphérique (dans lequel le souscripteur est généralement l'organisation contrôlant le périphérique) et les certificats anonymes (dans lequel l'identité de l'individu ou de l'organisation n'est pas disponible depuis le certificat lui-même). D'autres types de certificats lient les clés publiques aux attributs d'une entité autre que l'identité de l'entité, tel qu'un rôle, un titre, ou des informations de solvabilité.

   Un certificat est utilisé par un utilisateur de certificat ou un tiers de confiance qui a besoin d'utiliser, et compte sur la précision de, le lien entre la clé publique du sujet distribué via ce certificat et l'identité et/ou d'autres attributs du sujet contenu dans ce certificat. Un tiers de confiance est fréquemment une entité qui vérifie la signature numérique du sujet du certificat où la signature numérique est associée avec un mail, document électronique, ou autre donnée. D'autres exemples de tiers de confiance peut inclure un émetteur de mail chiffré à un souscripteur, un utilisateur d'un navigateur web vérifiant un certificat serveur durant une session SSL, et une entité opérant un serveur qui contrôle l'accès aux informations online en utilisant des certificats client comme mécanisme de contrôle d'accès. En résumé, un tiers de confiance est une entité qui utilise une clé publique dans un certificat (pour vérification de signature et/ou chiffrement). Le degré auquel le tiers de confiance peut faire confiance à la liaison embarquée dans un certificat dépend de nombreux facteurs. Ces facteurs peuvent inclure les pratiques suivies par l'autorité de certification en authentifiant le sujet; la stratégie de la CA, les procédures, et les contrôles de sécurité. Le scope de la responsabilité du souscripteur (par exemple, en protégeant la clé privée); et les responsabilités statué et les termes et conditions de responsabilité de la CA.

   Un certificat X.509 version 3 peut contenir un champ déclarant qu'une ou plusieurs stratégies de certificat spécifiques s'appliquent à ce certificat. En accord avec X.509, une stratégie de certificat (CP) est "un jeu de règles nommés qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou classe d'applications avec des pré-requis de sécurité communs". Un CP peut être utilisé par un tiers de confiance pour aider à décider si un certificat est suffisamment digne de confiance et par ailleurs approprié pour une application particulière. Le concept CP est un prolongement du concept de déclaration de stratégie développé pour Internet Privacy Enhanced Mail.

   Une description plus détaillée des pratiques suivies par une CA en émettant et gérant des certificats peut être contenu dans une déclaration de pratique de certification (CPS) publié par ou référencé par la CA. En accord avec American Bar Association Information Security Committee's Digital Signature Guidelines (DSG) et l'Information Security Committee's PKI Assessment Guidelines (PAG), "un CPS est une déclaration des utilisations qu'une autorité de certification emploie pour émettre des certificats". En général, les CPS décrivent également des pratiques liées à tous les services de cycle de vie des certificats (ex: émission, gestion, révocation, renouvellement, etc), et les CPS fournissent des détails concernant d'autres question d'affaires, juridiques et techniques. Les termes contenus dans un CP ou CPS peuvent ou non être obligatoire pour les participants d'une PKI comme un contrat. Un CP ou CPS peut lui-même prétendre être un contrat. Plus communément, cependant, un agrément peut incorporer un CP ou CPS par référence et ainsi tenter de lier les parties de l'agrément à partie ou tous ses termes. Par exemple, certaines PKI peuvent utiliser un CP ou ( plus communément ) un CPS qui est incorporé par référence dans l'agrément entre un souscripteur et une CA ou RA (appelé un agrément de souscripteur) ou l'agrément entre un tiers de confiance et une CA (appelé un agrément de tiers de confiance ou RPA). Dans d'autres cas, cependant, un CP ou CPS n'a pas de signification contractuelle du tout. Une PKI peut définir ces CP ou CPS comme étant strictement informationels ou des documents d'information.

But

   Le but de ce document est double. D'abord, le document explique les concepts d'un CP ou d'un CPS, décris les différences entre ces 2 concepts, et décris leur relation au souscripteur et agréments de tiers de confiance. Ensuite, ce document présente un framework pour assister les rédacteurs et utilisateurs de stratégie de certificat ou CPS en définissant et comprenant ces documents. En particulier, le framework identifie les éléments qui peuvent être nécessaire à considérer en formulant un CP ou CPS. Le but n'est pas de définir de stratégie de certificat particulière ou CPS.

Périmètre

   Le périmètre de ce document est limité à la discussion des éléments qui peuvent être couverts dans un CP (comme définis dans X.509) ou CPS (comme définis dans DSG et PAG). En particulier, ce document décris les types d'information qui devraient être considérés pour les inclure dans un CP ou CPS. Bien que le framework présenté généralement assume l'utilisation de certificat X.509v3 pour fournir l'assurance d'identité, il n'est pas prévus qu'il soit restreint à l'utilisation de ce format de certificat. À la place, il est prévus que ce framework soit adaptable à d'autres formats de certificat et certificats fournissant des assurance autre que l'identité qui peuvent entrer en utilisation.

   Le scope ne s'étend pas à la définition des stratégies de certificat (tels que les stratégies de sécurité des organisation, stratégie de sécurité des systèmes, ou stratégie de labelisation des données). De plus, ce document ne définis pas de CP ou CPS spécifiue. En outre, en présentant un framework, ce document devrait être vu et utilisé comme un outil flexible présentant des éléments qui devraient être considérés comme un intérêt particulier pour les CP ou CPS, et pas comme une formue rigide pour produire des CP ou CPS.

   Ce document assume que le lecteur est familiarisé avec les concepts généraux de signature numérique, certificat, et infrastructure à clé publique, comme utilisé dans X.509, le DSG et le PAG.

Définitions

   Ce document utilise les termes suivant:

Activation Data Les valeurs, autre que les clés, qui sont requis pour opérer des modules cryptographiques et qui nécessitent d'être protégés.
Authentification Le processus qui établis que les individus, organisation, ou autre sont qui ils prétendent être. Dans le contexte d'une PKI, l'authentification peut être le processus d'établissement qu'un individu ou organisation applique pour accéder à quelque chose sous un certain nom est, en fait, l'individu ou l'organisation propre. Cela correspond au deuxième processus impliqué dans l'identification.
CA-certificate Un certificat pour une clé publique de CA émise par une autre CA
Certificate Policy Un jeu nommé de règles qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou class d'applications avec des besoins de sécurités communs. Par exemple, un CP particulier peut indiquer l'applicabilité d'un type de certificat pour l'authentification des parties engagés dans des transaction b2b pour le commerce de biens ou de services dans une plage de prix donné.
Certification path Une séquence ordonnée de certificats qui, ensemble avec la clé publique de l'objet initial dans le chemin, peuvent être traités avec la clé publique de l'objet initial dans le chemin, peut être traité pour obtenir l'objet final est dans le chemin.
Certification Practice Statement Une déclaration des pratiques qu'une autorité de certification emploie en émettant, gérant, révoquant, et renouvelant les certificats.
CPS Summary (ou CPS Abstract) Un sous-jeu des dispositions d'une CPS complète qui est rendue publique par une CA.
Identification Les processus établissant l'identité d'un individu ou d'une organisation, par ex, pour montrer qu'un individu ou une organisation est un individu ou une organisation spécifique. Dans le contexte d'une PKI, l'identification réfère à 2 processus:

        1. Établir qu'un nom donné d'un individu ou d'une organisation correspond à une identité du monde réel d'un individu ou d'une organisation
        2. Établir qu'un individu ou une organisation s'applique pour un accès à quelque chose sous ce nom est, en fait, l'individu ou l'organisation nommée. Une identification d'une personne peut être un demandeur de certificat, un demandeur pour un emploie dans un poste de confiance participant à une PKI, ou une personne cherchant accès au réseaux ou à une application, telle qu'un administrateur CA cherchant l'accès aux systèmes CA.

Issuing certification authority Dans le contexte d'un certificat particulier, la CA émettrice est la CA qui a émise le certificat.
Participant Un individu ou une organisation qui joue un rôle dans une PKI donnée comme un souscripteur, un tiers de confiance, CA, RA, etc.
PKI Disclosure Statement Un instrument qui complète une CP ou une CPS en divulguant des informations essentielles sur les stratégies et pratiques d'une CA/PKI. Un PDS est un véhicule pour divulguer et souligner les informations normalement couvertes en détail par les documents CP et/ou CPS associés. En conséquence, un PDS n'est pas prévu pour remplace une CP ou CPS.
Policy qualifier Information dépendante de la stratégie qui peut accompagner un identifiant de CP dans un certificat X.509. De telles informations peuvent inclure un pointeur vers une URL d'une CPS applicable ou d'un agrément de tiers de confiance. Il peut également inclure du texte qui contient les termes d'utilisation du certificat ou des informations légales.
Registration authority (RA) Une entité qui est responsable pour une ou plusieurs fonctions: l'identification et l'authentification des demandeurs de certificat, l'approbation ou le rejet des applications de certificat, initier les révocations de certificat ou leur suspension sous certaines circonstances, traiter les demandes de renouvellement ou changement de clé. Les RA, cependant, ne signent ou n'émettent pas de certificat.
Relying party Un destinataire d'un certificat qui agit en se fondant sur ce certificat et/ou toutes signature vérifiées en utilisant ce certificat. Dans ce document, les termes "certificate user" et "relying party" sont utilisé de la même manière.
Relying party agreement (RPA) Un agrément entre une autorité de certification et un tiers de confiance qui établis typiquement les droits et responsabilité entre ces parties en regardant la vérification des signatures ou d'autres utilisation des certificats.
Set of provisions Une collection de déclarations de stratégies et/ou de pratique, couvrant un éventails de sujets standards, à utiliser dans l'expression d'un CP ou CPS utilisant l'approche décrite dans ce framework.
Subject certification authority (subject CA) Dans le contexte d'un certificat CA particulier, le subjet CA est la CA dont la clé publique est certifiée dans le certificat
Subscriber Un Sujet d'un certificat qui a été émis.
Subscriber Agreement Un agrément entre une CA et un souscripteur qui établis les droits et responsabilités des parties en regardant l'émission et la gestion des certificats.
Validation Le processus d'identification des demandeurs de certificat. la validation est un sous-jeu de l'identification et réfère à l'identification dans le contexte d'établissement de l'identité des demandeurs de certificat.

Concepts

   Cette section explique les concepts des CP et CPS, et décris leur relation avec d'autres documents PKI, tels que les agréments de souscripteur et de tiers de confiance. D'autres concepts liés sont également décris. Certains supports couverts dans cette section et dans d'autres sections sont spécifiques aux extensions de stratégie de certificat comme définis dans X.509v3. Excepté pour ces sections, ce framework est prévu pour être adaptable à d'autres formats de certificat qui peuvent être utilisés.

Certificate Policy

   Quand une autorité de certification émet un certificat, elle fournis une déclaration à l'utilisateur du certificat qu'une clé publique particulière est liée à l'identité et/ou d'autres attributs d'une entité particulière. La mesure par laquelle le tiers de confiance devrait se conformer sur cette déclaration, cependant, doit être évalué par le tiers de confiance ou d'entité qui contrôle ou coordonne la manière dont les tiers de confiance ou les applications de confiance utilisent les certificats. Différents certificats sont émis suivant différentes pratiques et procédures, et peuvent être utilisable pour différentes applications et/ou buts.

   Le standard X.509 définis une CP comme un jeu nommé de règles qui indique l'applicabilité d'un certificat à une communauté et/ou classe d'application particulier avec les pré-requis de sécurité communs. Un certificat X.509v3 peut identifier une CP applicable spécifique, qui peut être utilisé par un tiers de confiance pour décider de faire confiance ou non à un certificat, la clé publique associée ou les signatures numériques vérifiées en utilisant la clé publique pour un but particulier.

   Il y a typiquement 2 catégories de CP. D'abord, certaines CP indiquent l'applicabilité d'un certificat à une communauté particulière. Ces CP présentent les pré-requis pour l'utilisation de certificat et les pré-requis des membres d'une communauté. Par exemple, une CP peut se concentrer sur les besoins d'une communauté géographique, tel que les pré-requis de stratégie ETSI pour les CA émettant des certificats qualifiés. Également, une CP de ce type peut se focaliser sur les besoins d'une communauté de marché spécifique telle que les services financiers.

   La seconde catégorie de CP indique l'applicabilité d'un certificat à une classe d'applications avec des pré-requis de sécurité communs. Ces CP identifient un jeu d'applications ou d'utilisations pour les certificats et indique que ces applications ou utilisations nécessitent un certain niveau de sécurité. Ils sont ainsi exposés aux exigences PKI qui sont appropriés pour cet applications ou utilisation. Une CP dans cette catégorie créé souvent des jeux de pré-requis appropriés pour un certain niveau d'assurance fournis par les certificats, relatifs aux certificats émis conformément aux CP liés. Ces niveaux d'assurance peuvent correspondre à des classes ou des types de certificat.

   Par exemple, le Government of Canada PKI Policy Management Authority (GOC PMA) a établis 8 stratégies de certificat dans un seul document, 4 stratégies pour les certificats utilisé pour les signatures et 4 certificat pour les certificats utilisé pour le chiffrement. Pour chacune de ces applications, le document établis 4 niveaux d'assurances: rudimentaire, basique, moyen et élevé. Le GOC PMA décris certains types d'utilisation de signature numérique et de confidentialité, chacun avec un certain jeu de pré-requis de sécurité, et groupé en 8 catégories. Le GOC PMA établis ainsi les pré-requis PKI pour chacune de ces catégories, en créant 8 types de certificats, chacun fournissant des niveaux d'assurance rudimentaire, basique, moyen et élevé. La progression du niveau d'assurance rudimentaire à élevé correspond à l'augmentation du niveau de sécurité et d'assurance requis.

   Une CP est représentée dans un certificat par un numéro unique appelé un OID. Cet OID, ou au moins un "arc", peut être enregistré. Un "arc" est le début d'une séquence numérique d'un OID et est assigné à une organisation particulière. Le processus d'enregistrement suit les procédures spécifiées dans les standards ISO/IETC et ITU. Le partie qui enregistre l'OID ou l'arc peut également publier le texte d'un CP, pour être examiné par les tiers de confiance. Tout certificat va explicitement déclarer une seule CP ou, possiblement, être émis en accord avec un petit nombre de stratégies différentes. De telles déclaration apparaissent dans l'extension de stratégie de certificat des certificats X.509v3. Quand une CA place plusieurs CP dans une extension de stratégie de certificat d'un certificat, la CA affirme que le certificat est approprié pour utilisation en accord avec une des CP listées.

   Les CP constituent également une base pour un audit, accréditation, ou autre évaluation d'une CA. Chaque CA peut être évaluée avec une ou plusieurs stratégie de certificat ou CPS qui sont reconnus comme implémentés. Quand une CA émet un certificat CA pour une autre CA, le CA émettrice doit évaluer le jeu de stratégie de certificats pour lequel il trust le sujet. Le jeu évalué est ainsi indiqué par la CA émettrice dans le certificat CA. Le traitement logique du chemin de certification X.509 emploie ces indication CP dans son modèle de validation.

Exemples de stratégie de certification

   Dans un but d'exemple, supposons que l'International Air Transport Association ( IATA ) s'engage à définir certaines stratégies de certificat pour l'utilisation dans l'industrie du transport aérien, dans une PKI opérée par IATA en combinaison avec les PKI opérés par les transports aériens individuels. 2 CP peuvent être définis - l'IATA General-Purpose CP, et l'IATA Commercial-Grade CP.

   L'IATA General-Purpose CP pourrais être utilisé par l'industrie pour protéger les informations de routine (ex: mails) et pour authentifier les connexions depuis les navigateurs web vers les services d'informations générales. Les paires de clé sont générées, stockées, et gérées en utilisant des systèmes à base de logiciel et à faible coût, tels que les navigateurs commerciaux. Sous cette stratégie, un certificat peut être automatiquement émis à tous les employés dans l'annuaire de l'IATA ou un membre qui a envoyé une demande de certificat signée par le biais d'un administrateur réseaux dans son organisation.

   L'IATA Commercial-Grade CP pourrait être utilisé pour protéger les transactions financières ou lier les échanges contractuels entre les entreprises. Sous cette stratégie, l'IATA pourrait imposer que les paires de clé certifiées soient générées et stockées dans des jetons hardwares cryptographiques approuvés. Les certificat et jetons pourraient être fournis aux employés avec une autorité de validation. Les individus autorisés peuvent ainsi être obligés d'être présents dans le bureaux de sécurité de l'organisation, montrer un badge d'identification valide, et signer un agrément de souscripteur qui leur impose de protéger le jeton et de l'utiliser seulement pour les buts autorisés.

Champs de certificat X.509

   Les extensions X.509 suivant sont utilisés pour supporter les CP:

- Extension de stratégies de certificat
- Extension de mappage de stratégie
- Extension de contrainte de stratégie

Extension de stratégie de certificat

   Un champ de stratégies de certificat liste les CP que l'autorité de certification déclare comme applicable. En utilisant l'exemple de l'IATA General-Purpose et Commercial-Grade définis plus haut, les certificats émis pour les employés normaux vont contenir l'identifiant d'objet pour la stratégie à but générale. Les certificats émis pour les employés avec autorité de validation vont contenir les identifiants d'objets pour les 2 stratégies. L'ajout des 2 stratégies dans les certificats signifie qu'ils sont appropriés pour les 2 stratégies. Ces stratégies de certificat peuvent également être optionnellement transmettre les valeurs de qualifiants pour chaque stratégie identifié.

   En traitant un chemin de certification, un CP qui est acceptable pour l'application doit être présent dans tous les certificats dans le chemin, par ex., dans les certificats CA et les certificat EE.

   Si le champ de stratégies de certificats est marqué critique, il sert le même but que décris plus haut mais a un rôle additionnel. Spécifiquement, il indique que l'utilisation du certificat est restreint à une des stratégies identifiées, par ex, l'autorité de certification déclare que le certificat doit seulement être utilisé en accord avec les dispositions d'au moins une CP listée. Ce champ est prévu pour protéger l'autorité de certification contre les réclamations pour des dommages causés par un tiers de confiance qui a utilisé le certificat dans un but inapproprié ou d'une manière inapproprié, comme stipulé dans la CP applicable.

   Par exemple, l'Internal Revenue Service peut émettre des certificat pour les contribuables dans le but de protéger les déclarations fiscales. L'Internal Revenue Service peut comprendre et accommoder les risques lié à l'émission de mauvais certificat, par ex, à un imposteur. Supposons, cependant, que quelqu'un à utilisé un certificat comme base pour le chiffrement de secrets commerciaux à plusieurs millions de dollars, qui tombent ensuite dans de mauvaises mains suite à une attaque par cryptanalytique par un attaquant qui est capable de déchiffrer le message. L'Internal Revenue Service peut vouloir se défendre lui-même contre les réclamations de dégâts dans de telles circonstances en pointant la criticité de l'extension des stratégies de certificat pour montrer la mauvaise utilisation du certificat par le souscripteur et le tiers de confiance. L'extension de stratégies de certificat marquée critique est prévue pour limiter les risques de la CA dans de telles situations.

Extension de mappage de stratégie

   L'extension de mappage de stratégie peut seulement être utilisé dans les certificats CA. Ce champ permet à une autorité de certification d'indiquer que certaines stratégies dans son propre domaine peuvent être considérés équivalents à d'autres stratégies dans le domaine du sujet de l'autorité de certification.

   Par exemple, supposons que pour faciliter l'interopérabilité, l'ACE Corporation établis un agrément avec ABC Corporation pour cross-certifier les clés publiques de chaque autorité de certification pour sécuriser mutuellement leur échanges respectifs. De plus, supposons que les 2 entreprises ont des stratégies de protection de transaction financières pré-existantes appelées ace-e-commerce et abc-e-commerce, respectivement. On peut voir que générer simplement les cross-certificats entre les 2 domaines ne fournis pas l'interopérabilité, vu que les 2 applications d'entreprises sont configurées avec, en les certificats des employés sont renseignés avec, leur stratégies de certificat respectifs. Une possibilité est de reconfigurés toutes les applications financières pour imposer une des 2 stratégies et de ré-émettre tous les certificats avec les 2 stratégies apparaissant dans l'extension de stratégies de certificat. Une autre solution, qui peut être plus simple à administrer, utilise le champ de mappage de stratégie. Si ce champ est inclus dans un cross-certificat pour l'autorité de certification d'ABC Corporation émis par l'autorité de certification de ACE Corporation, il peut fournir une déclaration que la stratégie de protection des transactions financières de ABC (ex: abc-e-commerce) peut être considéré équivalent à celle de ACE Corporation (ex: ace-e-commerce). Avec une telle déclaration inclue dans le cross-certificat émis à ABC, les applications tiers dans le domaine ACE nécessitent la présence de l'identifiant d'objet pour que la CP ace-e-commerce soit également acceptée, traitée, et validée une fois les certificats émis dans le domaine ABC contenant l'identifiant d'objet pour la CP abc-e-commerce.

Extension de contraintes de stratégie

   L'extension de contraintes de stratégie supporte 2 fonctionnalités optionnelles. La première est la capacité pour une autorité de certification de nécessiter que les indications de CP explicites soient présents dans tous les certificats suivant dans la chaîne de certification. Les certificats au début d'un chemin de certification peuvent être considérés par un tiers de confiance comme partie d'un domaine de confiance, par ex, les autorités de certification sont validés pour tous les buts donc aucune CP n'est nécessaire dans l'extension de stratégies de certificat. De tels certificats n'ont pas besoin d'indications explicites de CP. Quand une autorité de certification dans le domaine, cependant, certifie en dehors du domaine, il peut activer les pré-requis d'un CP qui doit apparaître dans les certificats suivants dans le chemin de certification.

   L'autre fonctionnalité optionnelle dans le champ de contraintes de stratégie est la capacité pour une autorité de certification de désactiver le mappage de stratégie pour les autorités de certification suivant dans la chaîne de certification. Il peut être prudent de désactiver le mappage de stratégies en certifiant en dehors du domaine. Cela peut aider à contrôler les risques dus à des trusts de transitions.

Qualifiants de stratégie

   Le champ d'extension de stratégies de certificat comporte une disposition pour le transport, avec chaque identifiant de CP, d'informations se stratégie dans le champ qualifier. Le standard X.509 ne mandate pas le but lequel ce champ est utilisé, ni ne décris la syntaxe pour ce champ. Les types de qualifiants de stratégie peuvent être enregistrés par une organisation.

   Les types de qualifiants de stratégie suivant sont définis dans la rfc3280:

a) Le CPS Pointer contient un pointer vers une CPS, sommaire de CPS, RPA, ou PDS publié par la CA. Le pointeur est sous la forme d'une URI.
b) Le User Notice contient une chaîne texte qui est affiché au souscripteur et les tiers de confiance avant l'utilisation du certificat. Le texte peut être un IA5String ou BMPString. Une CA peut invoquer une procédure qui nécessite que la prise de connaissance par le tiers de confiance des termes applicables et des conditions d'utilisation.

   Les qualifiants de stratégie peuvent être utilisé pour supporter la définition de CP génériques ou paramétrisés. En fournissant la CP de base, les types de qualifiants de stratégie peuvent être définis pour transmettre, sur une base par-certificat, des détails de stratégie spécifiques additionnels qui complète la définition générique.

Déclaration de pratique de certification

   Le terme certification practice statement (CPS) est définis par le DSG et PAG en tant que "déclaration de pratique qu'un autorité de certification emploie pour émettre des certificats". Comme statué plus haut, une CPS établis les pratiques concernant le cycle de vie des services en plus de l'émission, tel que la gestion de certificat (incluant la publication et l'archivage), la révocation, et le renouvellement. Dans le DSG, le ABA étend cette définition avec les commentaires suivants:

   "Une déclaration de pratique de certification peut prendre la forme d'une déclaration par l'autorité de certification des détails de son système fiable et les pratiques qu'elle emploie dans ses opérations et dans le support d'émission d'un certificat." Cette forme de CPS est le type le plus commun, et peut varier en longueur et en niveau de détail.

   Certaines PKI peuvent ne pas avoir besoin de créer de déclaration détaillée et approfondie des pratiques. Par exemple, la CA peut elle-même être le tiers de confiance et sera toujours conscient de la nature et de la fiabilité de ses services. Dans d'autres cas, une PKI peut fournir des certificats fournissant seulement un très bas niveau d'assurance où les applications à sécuriser peuvent causer seulement des risques marginaux s'il sont compromis. Dans ces cas, une organisation établissant une PKI peut seulement vouloir écrire ou avec des CA utilisant un agrément de souscripteur, agrément de tiers de confiance, en fonction du rôle des différents participants de PKI. Dans de telles PKI, cet agrément peut servir comme seule déclaration de pratique utilisé par une ou plusieurs CA dans cette PKI. En conséquence, cet agrément peut également être considéré une CPS et peut être intitulé ou sous-titré comme tel.

   Également, vu qu'une CPS détaillée peut contenir des détails sensible de son système, une CA peut choisir de ne pas publier l'entièreté du CPS. Elle peut choisir de ne publier qu'une CPS sommaire ( ou CPS abstrait ). La CPS sommaire contient seulement les dispositions de la CPS que la CA considère être pertinents pour les participants dans la PKI (tel que les responsabilités des tiers ou les étapes du cycle de vie du certificat). Une CPS sommaire, cependant, ne contient pas les disposition sensibles de la CPS complète qui peut fournir à un attaquant les informations utiles sur les opérations de la CA. Tout au long de ce document, l'utilisation de CPS inclus la CPS détaillée et la CPS sommaire.

   Les CPS ne constituent pas automatiquement des contrats et ne lie pas automatiquement les participants de la PKI comme un contrat le ferai. Lorsqu'un document sert de double objectif d'agrément de souscripteur ou tiers de confiance et CPS, le document est prévu pour être un contrat et constitue un contrat liant dans la mesure où un agrément de souscripteur ou de tiers de confiance serait considéré comme tel. La plupart des CPS, cependant, ne sont pas à double usage. Ainsi, dans beaucoup de cas, les termes de la CPS ont un effet lié comme termes de contrat seulement si un document séparé créé une relation contractuelle entre les parties et que ce document incorpore une partie ou toute la CPS en référence. De plus, si une PKI particulière emploie une CPS sommaire, la CPS sommaire peut être incorporé dans un agrément de souscripteur ou de tiers de confiance applicable.

   Dans le future, un tribunal ou une loi statutaire ou réglementaire applicable peut déclarer qu'un certificat lui-même est un document qui est capable de créer une relation contractuelle, pour étendre ses mécanismes conçus pour être incorporé par référence ( tel que l'extension de stratégies de certificat et ses qualifiants ) indique que les termes d'utilisation apparaissent dans certains documents. Pendant ce temps, cependant, certains agréments de souscripteurs et tiers de confiance peuvent incorporer une CPS par référence et ainsi prendre ses dispositions sur les parties de tels accords.

Relation entre CP et CPS

   Les CP et CPS adressent le même jeu de sujets qui sont d'interêt pour un tiers de confiance en terme de degré à et le but pour lequel un certificat à clé publique devrait être trusté. Leur principales différences sont dans le focus de leurs disposition. Un jeu CP énonce les pré-requis et les standards imposés par la PKI en respect de divers sujets. En d'autres termes, le but du CP est d'établir ce que les participants doivent faire. Une CPS, en contraste, status comment une CA et d'autres participants dans un domaine donné implémentent les procédures et contrôles pour répondre aux pré-requis statués dans la CP. En d'autres termes, le but de la CPS est de déclarer comment les participants effectuent leur fonction et implémentent les contrôles.

   Une autre différence relate le périmètre de couverture des 2 types de document. Vu qu'une CP est une déclaration des pré-requis, il est préférable pour communiquer un guide d'exploitation minimum qui doivent être rencontrés par les PKI intéropérantes. Donc, une CP s'applique généralement à plusieurs CA, plusieurs organisations, ou plusieurs domaines. En contraste, une CPS d'applique seulement à une simple CA ou une simple organisation.

   Un CA avec une seule CPS peut supporter plusieurs CP ( utilisés pour différentes applications et/ou différentes communautés tiers de confiance ). Également, plusieurs CA, avec des CPS différentes, peuvent supporter la même CP.

   Par exemple, le gouvernement fédéral peut définir une CP globale au gouvernement pour gérer les informations de ressources humaines confidentielles. La CP sera une déclaration générale des pré-requis pour les participants dans la PKI du gouvernement, et une indication des types d'applications pour lesquelles elle est prévue. Chaque département ou agence souhaitant opérer une autorité de certification dans cet PKI peut nécessiter l'écriture de sa propre CPS pour supporter cette CP en expliquant comment elle gère les pré-requis de la CP. Dans le même temps, un CPS de département ou agence peut supporter d'autres stratégies de certificat.

   Une autre différence entre une CP et une CPS concerne le niveau de détail des dispositions. Bien que le niveau de détail peut varier dans les CPS, une CPS va généralement être plus détaillée qu'un CP. Une CPS fournis une description détaillée des procédures et contrôles en places pour se conformer aux requis de la CP, alors que la CP est plus générale.

   Les principales différences entre CP et CPS peuvent être résumés comme suit:

a) Une PKI utilise une CP pour établir les requis qui statuent sur ce que les participants doivent faire. Une simple CA ou organisation peut utiliser une CPS pour divulguer comment elle se conforme aux requis d'une CP ou comment elle implémente ses pratiques et contrôles.
b) Une CP facilite l'interopérabilité entre cross-certification, certification unilatérale, ou d'autres moyens. De plus, elle est prévue pour couvrir plusieurs CA. En contraste, une CPS est une déclaration d'une seul CA ou organisation. Son but n'est pas de simplifier l'interopération.
c) Une CPS est généralement plus détaillée qu'une CP et spécifie comment la CA se conforme aux requis spécifiés dans une ou plusieurs CP sous lesquelles elle émet des certificats.

   En plus de populer l'extension de stratégies de certification avec l'OID de la CP applicable, une autorité de certification peut inclure, dans les certificats quelle émet, une référence à ses CPS.

Relation entre CP, CPS et d'autres documents

   CP et CPS jouent un rôle centrale en documentant les pré-requis et pratiques d'une PKI. Cependant, ce ne sont pas les seuls documents. Par exemple, les agréments de souscripteur et les agréments de tiers de confiance jouent un rôle critique en allouant les responsabilités des souscripteur et tiers de confiance liés à l'utilisation de certificats et des paires de clé. Ils établissent les termes et conditions sous lesquelles les certificats sont émis, gérés, et utilisés. Le terme agrément de souscripteur est définis par le PAG comme: "un agrément entre une CA et un souscripteur qui établis les droits et obligation des parties au regard de l'émission et la gestion des certificats". Le PAG définis un agrément de tiers de confiance comme: "un agrément entre une autorité de certification et un tiers de confiance qui établis typiquement les droits et obligations entre ces parties au regard de la vérification des signatures numériques ou d'autres utilisations de certificats".

   Comme mentionné précédemment, un agrément de souscripteur, un agrément de tiers de confiance, ou un agrément qui combine les 2 peut également service de CPS. Dans d'autres PKI, cependant, un agrément de souscripteur ou de tiers de confiance peut incorporer certains ou tous les termes d'une CP ou CPS par référence. D'autre PKI encore peuvent distiller depuis une CP et/ou CPS les termes qui sont applicables au souscripteur et place de tels termes dans un agrément de souscripteur auto-contenu, sans incorporer de CP ou CPS par référence. Elles peuvent utiliser la même méthode pour distiller les termes de tiers de confiance depuis une CP et/out CPS et placer de tels termes dans un agrément de tiers de confiance. Créer de tels agrément auto-contenus a l'avantage de créer des documents qui sont plus faciles à lire par les consommateurs. Dans certains cas, les souscripteur et les tiers de confiance peuvent être considérés comme des consommateurs sous une loi applicable, qui sont sujets aux lois civiles des pays, incorporer une CP ou une CPS par référence peut ne pas être efficace pour lier les consommateurs aux termes dans une CP ou CPS incorporé.

   Les CP et CPS peuvent être incorporés par référence dans d'autres documents, incluant:

- Agréments d'interopérabilité ( incluant les agréments entre les CA pour la cross-certification, la certification unilatérale, ou d'autres formes d'interopération ).
- Agréments de vendeur ( sous lequels un vendeur de PKI accepte de se conformer aux normes énoncées dans une CP ou CPS ).
- Un PDS

   Un PDS a une fonction similaire à une CPS sommaire. C'est un document relativement court contenant seulement un sous-jeu de détails critiques sur une PKI ou CA. Il peut différer d'une CPS sommaire, cependant, dans son but qui est d'agir comme sommaire d'information sur la nature globale de la PKI, en contraste à une forme condensée d'une CPS.

   De plus, son but est de distiller les informations sur la PKI, en opposé à la protection d'information sensible de sécurité contenu dans une CPS non-publiée, bien qu'un PDS pourrait servir également cette fonction.

   Tout comme un rédacteur pourrait souhaiter référer à une CP ou CPS ou l'incorporer par référence dans un agrément ou PDS, une CP ou CPS peut référer à d'autres documents lors de l'établissement des requis ou en définissant les déclarations. Par exemple, une CP pour définir les requis pour le contenu de certificat en se référant à un document externe énonçant un profile de certificat standard. Référencer des documents externes permet à une CP ou CPS d'imposer des requis détaillés ou des déclarations détaillées sans avoir à ré-écrire les dispositions longue depuis d'autres documents dans la CP ou CPS. De plus, référencer un document dans une CP ou CPS est une autre manière utile de diviser les dispositions entre les informations publique et les informations confidentielles sensibles ( en plus de ou comme alternative à une CPS sommaire ). Par exemple, une PKI peut souhaiter publier une CP ou CPS, mais maintenir les paramètres de construction du site pour une CA comme information confidentielle. Dans ce cas, la CP ou CPS pourrait référencer un manuel externe ou un document contenant ces paramètres détaillés.

   Les documents qu'une PKI peut souhaiter faire référence dans une CP ou CPS incluent:

- Une stratégie de sécurité
- Manuels de formation, opérationnel, installation, et utilisateurs ( qui peuvent contenir des requis opérationnels )
- Plans de gestion de clés
- Guides de ressources humaine et manuels d'embauche ( qui peuvent décrire certains aspects de pratiques de sécurité personnel )
- Stratégie d'email ( qui peut discuter des responsabilités des souscripteurs et tiers de confiance, aussi bien que les implications de gestion de clé, si applicable )

Jeu de disposition

   Un jeu de dispositions est une collection de pratiques et/ou déclarations de stratégies, couvrant un éventail de sujets à utiliser dans l'expression d'une CP ou CPS employant l'approche décrite dans ce framework.

   Une CP peut être exprimée comme un seul jeu de dispositions

   Une CPS peut être exprimée comme un seul jeu de dispositions avec chaque composant adressant les requis d'une ou plusieurs stratégie de certificat, ou, alternativement, comme une collection organisée de jeux de dispositions. Par exemple, une CPS pourrait être exprimées comme un combinaison des éléments suivants:

a) Une liste de stratégies de certificats supportés par la CPS;
b) Pour chaque CP dans (a), un jeu de dispositions qui contiennent les déclarations répondant à cette CP en ajoutant les détails non stipulés dans la stratégie ou expressément laissée à la discrétion de la CA (dans ses CPS); de telles déclarations servent à statuer comment cette CPS particulière implémente les requis d'une CP particulière, ou
c) Un jeu de dispositions qui contiennent des déclarations de pratique de certification dans la CA, sans regarder la CP.

   Les déclarations fournies dans (b) et (c) peuvent augmenter ou affiner les stipulations de la CP applicable, mais ne doit généralement pas être en conflit avec une des stipulations d'une telle CP. Dans certains cas, cependant, une autorité de stratégie peut permettre des exceptions aux pré-requis dans une CP, parce que certains contrôles de compensation de la CA sont décris dans sa CPS, qui permet à la CA de fournir des assurances qui sont équivalents aux assurances fournies par les CA qui sont complètement conformes avec la CP.

   Ce framework dessine le contenu d'un jeu de dispositions, en terme de 9 composants principaux, comme suit:

1. Introduction
2. Publication et dépôt
3. Identification et Authentification
4. Pré-requis opérationnels du cycle de vie de certificat
5. Installation, gestion, et contrôles opérationnels
6. Contrôles de sécurité techniques
7. Profiles de certificat, CRL, et OCSP
8. Audit de conformité
9. Autres affaires et questions juridiques

   Les PKI peuvent utiliser ce simple framework de 9 composant primaires pour écrire une CP ou CPS simple. De plus, une CA peut utiliser ce framework pour écrire des agréments de souscripteur et/ou de tiers de confiance. Si une CA utilise ce framework pour construire un agrément, il peut utiliser le paragraphe 1 comme introduction, peut exposer les responsabilités des parties dans le paragraphe 2-8, et peut utiliser le paragraphe 9 pour couvrir les problèmes légaux et commerciaux décris plus en détail plus bas. L'ordre des sujets dans ce simple framework et les questions juridiques et de business est le même que l'ordre des sujets dans un logiciel typique ou d'autres agréments technologiques. Cependant, une PKI peut établir un jeu de documents centraux ( avec une CP, CPS, agrément de souscripteur et de tiers de confiance ) ayant tous la même structure et ordre des sujets, facilitant ainsi les comparaisons et les mappages entre ces documents et entre les documents correspondant d'autres PKI.

   Ce simple framework peut également être utile pour les agrément autre que les agréments de souscripteur et de tiers de confiance. Par exemple, une CA souhaitant externaliser certains services à une RA ou une autorité de fabrication de certificat ( certificate manufacturing authority (CMA) ) peuvent trouver utile d'utiliser ce framework comme checklist pour écrire un agrément d'autorité d'enregistrement ou d'externalisation. Similairement, 2 CA peuvent souhaiter utiliser ce framework pour définir une cross-certification, certification unilatérale, ou d'autre agréments d'interopérabilité.

   Les composants primaires du framework peuvent rencontrer les besoins des rédacteurs de CP, CPS et agréments cours. Cependant, ce framework est extensible, et sa couverture de 9 composants est suffisamment flexible pour s'adapter aux besoins des rédacteurs de CP et CPS. Spécifiquement, les composants apparaissant ci-dessus peuvent comprendre plusieurs éléments. La section suivante fournis une description plus détaillée du contenu des composants et leur sous-composants. Les rédacteurs de CP et CPS sont autorisés à ajouter des niveaux additionnels de sous-composants sous les sous-composant pour correspondre à leurs besoins.

Contenu du jeu de dispositions

   Cette section étends le contenu du framework de dispositions. Les sujets identifiés dans cette section sont, en conséquence, des sujets candidats pour être inclus dans une CP ou CPS détaillée.

   bien que de nombreux sujets sont identifiés, il n'est pas nécessaire pour une CP ou une CPS d'inclure une déclaration concrète pour chaque sujet. À la place, une CP ou CPS particulière peut indiquer "aucune stipulation" pour un composant, sous-composant, ou élément sur lequel la CP ou CPS n'impose aucun requis ou ne divulgue rien. En ce sens, la liste des sujets peut être considéré comme une checklist de sujets pour aider à la rédaction d'une CP ou CPS.

   Il est recommandé que chaque composant et sous-composant soit inclus dans une CP ou CPS, même s'il n'y a aucune stipulation; cela indique au lecteur qu'une décision consciente a été faite d'inclure ou exclure une disposition concernant ce sujet. Ce style de rédaction protège contre les oublis par inadvertance d'un sujet, tout en facilitant la comparaison de différentes stratégies de certificat ou CPS.

   Dans une CP, il est possible de laisser certains composants, sous-composants et/ou élément non-spécifiés, et pour stipuler que les informations requises seront indiquées dans un qualifiant de stratégie, ou le document vers lequel le qualifiant de stratégie pointe. Le jeu de dispositions devrait référencer ou définir les types de qualifiant de stratégie requis et devrait spécifier les valeurs par défaut applicables.

1. Introductions

   Ce composant identifie et introduit le jeu de dispositions, et indique les types d'entité et applications pour lesquels le document écris.

1.1 Vue générale

   Ce sous-composant fournis une introduction générale au document. Ce sous-composant peut également être utilisé pour fournir un synopsis de la PKI pour laquelle la CP ou CPS s'applique. Par exemple, il peut définir différents niveaux d'assurance fournis par les certificats dans une PKI particulière, une représentation diagrammatique de la PKI être utile ici.

1.2 Nom du document et identification

   Ce sous-composant fournis des noms applicable ou d'autres identifiants incluant les identifiants d'objets ASN.1, pour le document. Un exemple d'un tel nom de document serait "US Federal Government Policy for Secure E-mail".

1.3 Participants de la PKI

   Ce sous-composant décris l'identité ou les types d'entités qui ont un rôle de participant dans une PKI:

        Autorités de certification, Par ex, les entités qui émettent des certificat. Une CA est la CA émettrice respectant le certificat CA qui lui a été donné. Les CA peuvent être organisés hiérarchiquement dans laquelle une CA d'organisation émet des certificats à des CA opérés par des organisations subordonnées, comme une branche, une division, ou un département dans une plus grande organisation.
        autorités d'enregistrement, par ex, les entités qui établissent les procédures d'enrôlement pour les candidats de certificats finaux, l'identification et l'authentification pour les candidats de certificats, et l'initialisation des demandes de révocation pour les certificats, et les approuver le renouvellement ou le changement de clé des certificats. Les organisations subordonnées dans une grande organisation peuvent agir comme RA pour la CA servant toute l'organisation, mais les RA peuvent également être externe à la CA.
        souscripteurs des exemples de souscripteurs qui reçoivent des certificats d'une CA incluent les employés d'une organisation avec sa propre CA, les clients de banque ou de courtage, organisations hébergeant des sites de e-commerce, etc.
        Tiers de confiance. Des examples de tiers de confiance incluent les employés d'une organisation ayant sa propre CA qui reçoit des emails signés par d'autres employs, les clients d'un site e-commerce, les organisations participant à un échange business-to-business, etc.
        Autres participants, tels que les autorités de fabrique de certificat, les fournisseurs de services de dépôt, et d'autres entités fournissant des service liés à la PKI.

1.4 Utilisation de certificat

   Ce sous-composant contient:

        - Une liste ou les types d'applications pour lesquels les certificats émis sont utilisable, tels que les mails éléctroniques, les transactions de vente, contrats, ou ordre de voyage, et/ou
        - Une liste ou les types d'applications pour lesquels l'utilisation des certificats est interdite.

   Dans le cas d'une CP ou CPS décrivant différents niveaux d'assurance ce sous-composant peut décrire les application ou les types d'applications qui sont appropriés ou inappropriés pour les différents niveaux d'assurance.

1.5 Administration de stratégie

   Ce sous-composant inclus le nom et l'adresse de l'organisation qui est responsable pour la rédaction, l'enregistrement, la maintenance, et la mise à jours de cette CP ou CPS. Il inclus également le nom, l'adresse email, numéro de téléphone, et numéro de fax d'une personne à contacter. Au lieu de nommer un personne, le document peut nommer un titre ou un rôle, un email alias, et d'autres informations généralisées. Dans certains cas, l'organisation peut statuer qui sa personne de contact, seule ou avec d'autre, est disponible pour répondre aux questions sur ce document.

   De plus, quand une autorité de stratégie formelle ou informelle est responsable pour déterminer si une CA devrait être autorisée à opérer dans ou intéropérer avec une PKI, il peut être souhaitable d'approuver la CPS d'une CA comme étant utilisable pour l'a CP de l'autorité de stratégie. Si c'est le cas, ce sous-composant peut inclure le nom ou titre, adresse email, numéro de téléphone, fax, et autres informations généralisées de l'entité en charge de prendre de telles décisions. Finalement, dans ce cas, le sous-composant peut également inclure les procédures par lesquels cette détermination est faite.

1.6 Définitions et acronymes

   Ce sous-composant contient une liste de définitions pour les termes définis utilisés dans ce document, aussi bien qu'une liste d'acronymes dans le document leur signification.

2 Responsablités de publication et de dépôt

   Ce composant contient les dispositions applicable avec:

- Une identification de l'entité ou les entités qui opèrent les dépôts dans la PKI, tels qu'une CA, CMA, ou fournisseur de service de dépôt indépendant
- La responsabilité d'un participant de PKI pour publier les informations de pratiques, certificat, et le statuts courant de tels certificats, qui peuvent inclurent les responsabilités de rendre la CP ou CPS disponible au publique en utilisant divers mécanismes en identifiant les composants, sous-composants, et élément de tels documents qui existent mais ne sont pas publiquement disponible, par exemple, les contrôles de sécurité, les procédures de dédouanement, ou information secrètes.
- Quand les informations doivent être publiés et la fréquence de publication, et
- le contrôle d'accès sur les objets publiés incluant les CP, CPS, certificats, statuts de certificats, et CRL.

3 Identifiation et authentification

   Ce composant décris les procédures utilisées pour authentifier l'identité et/ou les autres attributs d'un utilisateur demandant un certificat à une CA ou une RA avant de recevoir le certificat. En plus, le composant énonce les procédures pour authentifier l'identité et les critères d'accèptation des demandes des entités cherchant à devenir un CA, RA, ou d'autres entités opérant dans ou intéropérant avec la PKI. Il décris également comment les parties demande un renouvellement de clé ou une révocation sont authentifiés. Ce composant adresse également les pratiques de nommage, incluant la reconnaissance des droits de marque dans certains noms.

3.1 Nommage

   Ce sous-composant inclus les éléments suivants pour le nommage et l'identification des souscripteurs:

- Les types et noms assignés au sujet, tel que les DN X.500, noms rfc822, et noms X.400.
- Si les noms doivent avoir un sens ou non
- Si les souscripteurs peuvent être anonymes ou des pseudonymes, et s'ils le peuvent, quels noms leur sont assignés ou peuvent être utilisé par les souscripteurs anonymes.
- Les règles pour interpréter divers formes de nom, tels que le standard X.500 et rfc822.
- Si les nom doivent être uniques, et
- La reconnaissance, l'authentification, et le rôle des marques.

3.2 Validation initiale de l'identité

   Ce sous-composant contient les éléments suivant pour les procédures d'identification et d'authentification pour l'enregistrement initial de chaque type de sujet (CA, RA, souscripteur, ou autre participant):

- Si et comment le sujet doit prouver la possession d'une clé privée associée à la clé privée en cours d'enregistrement, par exemple, une signature numérique dans le message de demande de certificat.
- Les requis d'identification et d'authentification pour l'entité organisationnelle du souscripteur ou du participant (CA, RA, souscripteur, ou autre participant), par exemple, en consultant la base d'un service qui identifie les organisations ou en inspectant les statuts de l'organisation.
- Les requis d'identification et d'authentification pour un souscripteur ou une personne agissant pour le compte d'une organisation ou d'un participant (CA, RA, dans le cas de certificats émis aux organisation ou périphériques contrôles par une organisation, souscripteur, ou autre participant), incluant:

        - Le type de documentation et/ou le nombre de référence d'identification requis.
        - Comment une CA ou RA authentifie l'identité de l'organisation ou individu basé sur la documentation ou les accréditifs fournies
        - Si l'individu doit se présenter personnellement à la CA ou RA authentifiante.
        - Comment un individu tel qu'une personne de l'organisation est authentifiée, tels que par référence à des documents d'autorisation signés ou un badge d'identification d'entreprise.

- La liste des informations de souscripteur qui n'est pas vérifiée durant l'enregistrement initial
- La validation de l'autorité implique de déterminer si une personne a des droits spécifiques ou des permissions incluant la permission d'agir pour le compte d'une organisation pour obtenir un certificat; et
- Dans le cas des applications par une CA souhaitant opérer dans, ou interopérer avec, une PKI, ce sous-composant contient le critère par lequel un PKI, CA, ou autorité de stratégie détermine si la CA est prévue pour de telles opérations ou intéropérations. Une telle intéropération peut inclure la cross-certification, certification unilatérale, ou d'autres formes d'intéropérations.

3.3 Identification et authentification pour les demande de renouvellement de clé

   Ce sous-composant adresse les éléments suivant pour les procédures d'identification et d'authentification pour le renouvellement de clé pour chaque type de sujet (CA, RA, souscripteur, ou autres participants).

- les requis d'identification et d'authentification pour les routines de renouvellement de clé, tel qu'une demande de renouvellement de clé qui contient la nouvelle clé et est signée en utilisant la clé actuellement valide, et
- Les requis d'identification et authentification pour le renouvellement de clé après la révocation de certificat. Un exemple est l'utilisation du même processus que pour la validation initiale

3.4 Identification et authentification pour les demandes de révocation

   Ce sous-composant décris les procédures d'identification et d'authentification pour une demande de révocation pour chaque type de sujet (RA, CA, souscripteur, et autres participants).

4 Requis opérationnel du cycle de vie des certificats

   Ce composant est utilisé pour spécifier les requis imposés en émettant des CA, sujets de CA, RA, souscripteurs, ou autres participants en respect avec le cycle de vie d'un certificat.

   Dans chaque cous-composant, des considérations séparées peuvent être nécessaire à donner au sujet d'une CA, RA, souscripteurs, et autres participants

4.1 Demande de certificat

   Ce sous-composant est utilisé pour adresser les requis suivant au regard de la demande de certificat:

- Qui peut émettre une demande de certificat, tel qu'un sujet de certificat ou la RA; et
- Le processus l'enrôlement utilisé par les sujets pour émettre des demandes de certificat et les responsabilités en connexion avec ce processus. Un exemple de ce processus est quand le sujet génère la paire de clé et envoie une demande à la RA. La RA valide et signe le demande et l'envoi à la CA. Une CA ou RA peut avoir la responsabilité d'établir le processus d'enrôlement pour pouvoir recevoir la demande. De même, les demandeurs de certificat peuvent avoir la responsabilité de fournir des informations précises sur leurs demandes de certificat.

4.2 Traitement des demandes de certificat

   Ce sous-composant est utilisé pour décrire la procédure pour traiter les demandes de certificat. Par exemple, La CA et RA émettrice peut effectuer des procédures d'identification et d'authentification pour valider la demande de certificat. En suivant ces étapes, la CA ou RA va soit approuver soit rejeter la demande, éventuellement basé sur certains critères. Finalement, ce sous-composant définis la durée limite qu'une CA et/ou RA doit agir et traiter la demande.

4.3 Émission de certificat

   Ce sous-composant est utilisé pour décrire les éléments suivant lié à l'émission de certificat:

- Les actions effectuées par la CA durant l'émission du certificat, par exemple une procédure par laquelle la CA valide la signature de la RA et l'autorité RA et génère un certificat; et
- Les mécanismes de notification, s'il y'en a, utilisé par la CA pour notifier le souscripteur de l'émission du certificat; par exemple, la procédure par laquelle la CA envoie par e-mail le certificat au souscripteur ou la RA ou les informations permettant au souscripteur de télécharger le certificat depuis un site web.

4.4 Acceptation de certificat

   Ce sous-composant adresse les éléments suivant:

- La conduite d'un candidat qui sera considéré pour constituer l'acceptation du certificat. Une telle conduite peut inclure des étapes d'affirmation pour indiquer l'acceptation, les actions impliquant l'acceptation, ou un rejet du certificat ou de son contenu. Par exemple, l'acceptation peut être considéré si la CA n'a pas reçu de notification du souscripteur dans une certaine période de temps; un souscripteur peut envoyer un message signé acceptant le certificat; ou un souscripteur peut envoyer un message signé rejetant le certificat qui inclus la raison du rejet et identifie les champs dans le certificat qui sont incorrect ou incomplets.
- La publication du certificat par la CA. Par exemple, la CA peut poster le certificat dans un annuaire LDAP ou X.500.
- La notification de l'émission du certificat par la CA à d'autres entités. Par exemple, la CA peut envoyer le certificat à la RA.

4.5 Utilisation du certificat et de la paire de clé

   Ce sous-composant est utilisé pour décrire les responsabilités liées à l'utilisation des clés et des certificats, incluant:

- La responsabilité du souscripteur lié à l'utilisation de la clé privée et du certificat du souscripteur. Par exemple, on peut imposer au souscripteur d'utiliser un clé privée et un certificat uniquement pour les applications appropriées comme indiquée dans la CP et en consistance avec le contenu du certificat (ex: le champ keyUsage). L'utilisation d'une clé privée et d'un certificat sont sujet aux termes de l'agrément du souscripteur, l'utilisation de la clé privée est permise seulement après que le souscripteur a accepté le certificat correspondant, ou le souscripteur doit arrêter l'utilisation de la clé privée après l'expiration ou la révocation du certificat.
- Les responsabilités des tiers de confiance liés à l'utilisation d'une clé publique de souscripteur et du certificat. Par exemple, un tiers de confiance peut être obligé de valider les certificats seulement pour les applications appropriées comme indiqué dans la CP et en consistance avec le contenu du certificat (ex: le champ keyUsage), exécuter avec succès les opération de clé publique comme condition de validation d'un certificat, assumer la responsabilité de vérifier le statut d'un certificat en utilisant un des mécanismes requis ou permis définis dans la CP/CPS, et le consentement des termes de l'agrément du tiers de confiance comme condition de validation de certificat.

4.6 Renouvellement de certificat

   Ce sous-composant est utilisé pour décrire les éléments suivants liés au renouvellement de certificat. Le renouvellement de certificat signifie l'émission d'un nouveau certificat au souscripteur sans changer le souscripteur ou d'autres clé publiques du participant ou informations dans le certificat:

- Les circonstances sous lesquelles le renouvellement du certificat prend place, tel que lorsque le certificat a expiré, mais la stratégie permet de réutiliser la même paire de clé.
- Qui peut faire des demandes de renouvellement de certificat, par exemple, le souscripteur, la RA, ou la CA peut automatiquement renouveler un certificat EE.
- Les procédures de CA ou RA pour traiter les demandes de renouvellement pour émettre le nouveau certificat, par exemple, l'utilisation d'un jeton, tels qu'un mot de passe, pour ré-authentifier le souscripteur, ou les procédures qui sont les même qui l'émission d'un certificat initial.
- La notification d'un nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.7 Renouvellement le clé

   Ce sous-composant est utilisé pour décrire les éléments suivants liés à un souscripteur ou un autre participant générant une nouvelle paire de clé et application pour l'émission d'un nouveau certificat qui certifie la nouvelle clé publique:

- Les circonstances sous lesquelles le renouvellement de clé de certificat peut ou doit être fait, tels qu'après la révocation d'un certificat pour une raison de compromission de clé ou après qu'un certificat a expiré et que la période d'utilisation de la paire de clé a également expiré.
- Qui peut demander le renouvellement le clé de certificat, par exemple, le souscripteur
- Les procédures CA ou RA pour traiter les demandes de renouvellement de clé pour émettre le nouveau certificat, tel que les procédures qui sont les même que pour l'émission de certificat initial.
- La notification du nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.8 Modification de certificat

   Ce sous-composant est utilisé pour décrire les éléments suivant liés à l'émission d'un nouveau certificat du à des changement d'informations dans le certificat autre qui la clé publique:

- Les circonstances sous lesquelles la modification de certificat peut se faire, tels qu'un changement de nom, changement de rôle, réorganisation résultant en un changement dans le DN.
- Qui peut effectuer des demandes de modification de certificat, par exemple, les souscripteurs, personnel des ressources humaines, ou la RA.
- Les procédures CA ou RA pour traiter les demandes de modification pour émettre le nouveau certificat, tel que les procédures qui sont les même que pour l'émission initiale.
- Notification du nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.9 Révocation et suspension de certificat

   Ce sous-composant adresse les points suivants:

- Les circonstances sous lesquelles un certificat peut être suspendu et les circonstances sous lesquelles il doit être révoqué, par exemple, dans le cas ou un souscripteur termine sont contrat, perd son jeton cryptographique, ou suspecte la compromission de la clé privé
- Qui peut demander la révocation du certificat du participant, par exemple, le souscripteur, RA ou CA dans le cas d'un certificat EE.
- Les procédures utilisées pour les demandes de révocation de certificat, tels qu'un message signé numériquement de la RA, du souscripteur, ou un appel téléphonique de la RA.
- La période de grâce disponible au souscripteur, dans laquelle le souscripteur doit créer une demande de révocation.
- Le temps dans lequel la CA doit traiter la demande de révocation
- Les mécanismes, s'il y en a, que le tiers de confiance peuvent utiliser ou doivent utiliser pour vérifier le statut des certificats qui souhaitent valider.
- Si un mécanisme de CRL est utilisé, la fréquence d'émission
- Si un mécanisme de CRL est utilisé, le délai maximum entre la génération de la CRL et sa publication (en d'autres termes, le temps maximum de traitement)
- La disponibilité d'un mécanisme de vérification on-line, par exemple, OCSP.
- Les pre-requis des tiers de confiance pour effectuer des vérification de statut/révocation on-line
- D'autres formes d'annonce de révocation disponible
- Toutes variations des stipulations précédentes pour lesquelles la suspension ou la révocation est le résultat d'une compromission de clé privée
- Les circonstances sous lesquelles un certificat peut être suspendu
- Qui peut demander la suspension d'un certificat, par exemple, le souscripteur, le personnel des ressources humaines, un superviseur du souscripteur, ou la RA dans le cas d'un certificat utilisateur.
- Les procédures pour demander la suspension du certificat, tel qu'un message signé numériquement du souscripteur ou d'un RA, un appel téléphonique de la RA
- La durée de suspension

4.10 Services de statut de certificat

   Ce sous-composant adresse les services de vérification de statut de certificat disponible aux tiers de confiance, incluant:

- Les caractéristiques opérationnelles des services de vérification de statut de certificat
- La disponibilité de tels services, et toutes stratégies applicables sur l'indisponibilité
- Toutes fonctionnalités optionnelles de tels services.

4.11 Fin de souscription

   Ce sous-composant adresse les procédures utilisée pour les souscripteurs pour terminer la souscription des services CA, incluant:

- La révocation des certificat à la fin de la souscription ( qui peut différer, en fonction de si la fin de souscription est dûe à l'expiration du certificat ou la fin du service ).

4.12 dépôt et récupération de clé

   Ce sous-composant contient les éléments pour identifier les stratégies et pratiques liées au dépôt, et/ou récupération des clés privées quand des services de dépôt de clés privée sont disponibles.

- Identification du document contenant les stratégies et pratiques de dépôt de clé et de récupération ou une liste de telles stratégies et pratiques
- Identification du document contenant les stratégies et pratiques d'encapsulation des clés de session ou une liste de telles stratégie et pratiques.

5. Gestion, opérationnel, et contrôles physiques

   Ce composant décris les contrôles de sécurité non-techniques (c'est à dire, les contrôles physiques, procédurales et personnelles) utilisées par la CA émettrice pour effectuer de manière sécurisée les fonctions de génération de clé, authentification du sujet, assurances de certificat, révocation de certificat, audit, et archivage.

   Ce composant peut également être utilisé pour définir des contrôles de sécurité non-techniques sur les dépôt, tels que les sujets CA, RA, souscripteurs, et autres participants. Les contrôles de sécurité non-techniques pour les CA, RA, souscripteurs, et autres participants peuvent être les mêmes, similaires, ou très différents.

   Ces contrôles de sécurité non-techniques sont critique pour valider les certificat vu qu'un manque de sécurité peut compromettre les opérations CA résultantes par exemple, en la création de certificats ou CRL avec des informations erronées ou la compromission de la clé privée de la CA.

   Dans chaque sous-composant, des considérations séparées vont, en général, être donnés à chaque type d'entité.

5.1 Contrôles de sécurité physiques

   Dans ce sous-composant, les contrôles physiques sur les installation abritant les systèmes de l'entité sont décris:

- La construction et l'emplacement du site, tel que la pré-requis de construction pour des zones à haute sécurité et l'utilisation de salles fermées, cages, coffre-fort, et armoires.
- L'accès physique, par ex, les mécanismes de contrôles d'accès d'une zone à une autre ou l'accès à des zones de haute sécurité, tels que les opérations CA localisées dans une salle information sécurisée et supervisée par des gardiens ou des alarmes de sécurité.
- Puissance et climatisation
- Exposition à l'eau
- Prévention et protection contre le feu
- Stockage, par exemple, la nécessité d'un stockage de sauvegarde dans un emplacement séparé qui est sécurisé physiquement et protégé du feu et de l'eau.
- L'élimination des déchets
- sauvegarde hors-site

5.2 Contrôles procédurales

   Dans ce sous-composant, les pré-requis opur reconnaître les rôles de confiance sont décris, avec les responsabilités de chaque rôle. Des exemples de rôles de confiance incluent les administrateurs systèmes, les responsables de la sécurité, et les auditeurs système.

   Pour chaque tâche identifié, le nombre d'individus requis pour effectuer la tâche devrait être statué pour chaque rôle. L'identification et l'authentification requis pour chaque rôle peut également être définis.

   Ce composant inclus également la séparation des privilèges en termes de rôles qui ne peuvent pas être effectués par les même individus.

5.3 Contrôles de sécurité personnel

   Ce sous-composant adresse les éléments suivant:

- Qualifications, expérience, et habilitations que le personnel doit avoir comme condition pour jouer ces rôles de confiance ou d'autres rôles importants. Par exemple les accréditifs, expérience professionnelle, et habilitations gouvernementales que les candidats à ces positions doivent avoir.
- La vérification des antécédents et des procédures d'habilitations qui sont requis dans le cadre de l'embauche de personnel remplissant des rôles de confiance ou d'autres rôles importants; de tels rôles peuvent nécessiter une vérification de leur casier judiciaire, références, et habilitations additionnelles qu'un participant engage après une décision d'embauche d'une personne particulière.
- Formations requises et procédures de formations pour chaque rôle qui suivent l'embauche.
- Toute période de renouvellement et les procédures de renouvellement pour chaque rôle après l'achèvement de la formation initiale.
- La fréquence et la séquence de la rotation des postes sur divers rôles
- Les sanctions contre le personnel pour les actions non autorisées, l'utilisation d'autorité non autorisée, l'utilisation non autorisé des systèmes dans le but d'imposer la responsabilité sur un participant.
- Les contrôles du personnel qui sont des indépendant aux lieu d'employés de l'entité, par exemple:

        - Exigences de cautionnement sur le personnel sous contrat
        - Les exigences contractuelles, y compris l'indemnisation des dommages dûs à des actions du personnel en contrat
        - L'audit et la supervision du personnel en contrat
        - D'autres contrôles sur le personnel en contrat

- La documentation à fournir au personnel durant la formation initiale, le renouvellement, ou autre.

5.4 Procédures d'audit de connexion

   Ce sous-composant est utilisé pour décrire les évènements de connexion et les systèmes d'audit, implémentés dans le but de maintenir un environnement sécurisé.

- Les types d'évènements enregistrés, tels que les opérations sur le cycle de vie des certificats, tentatives d'accès au système, et requêtes faites au système.
- Fréquence à laquelle les logs d'audits sont traités ou archivés, par exemple, chaque semaine, suivant un évènement anormal ou d'alerte, ou quand le log d'audit est plein.
- Période pour laquelle les données d'audit sont conservées
- Protection des logs d'audit:

        - Qui peut voir les logs d'audit, par exemple, les administrateurs d'audit
        - La protection contre la modification des logs d'audit, par exemple une exigence qu'aucune modification ou suppression les enregistrements d'audit ou que seul l'administrateur d'audit peut supprimer un fichier d'audit comme partie de la rotation du fichier d'audit
        - Protection contre la suppression des logs d'audit.

- Procédures de sauvegarde des log d'audits
- Si le système de d'accumulation des logs d'audits est interne ou externe à l'entité
- Si le sujet qui à causé un évènement d'audit est notifié de l'action d'audit
- L'évaluation des vulnérabilité, par exemple, où les données d'audit sont lancées via un outils qui identifie les tentatives potentielles pour casser le système de sécurité

5.5 Archivage des données d'enregistrement

   Ce sous-composant est utilisé pour décrire les stratégies d'archivage des enregistrements:

- Les types d'enregistrement qui sont archivés, par exemple, toutes les données d'audit, les information d'application de certificat, et la documentation supportant les applications de certificat.
- La période de rétention pour une archive
- La protection d'une archive

        - Qui peut voir l'archive, par exemple, seulement l'administrateur d'audit
        - La protection contre la suppression de l'archive
        - La protection contre la détérioration du support sur lequel l'archive est stockée, tel que la migration des donnée périodiquement sur un nouveau support.
        - La protection contre l'obsolescence du matériel, systèmes d'exploitation et autres logiciels.

- Les procédure de sauvegarde des archives
- Les pré-requis pour l'horodatage des enregistrements
- Si le système de collecte d'archive est interne ou externe
- Les procédures pour obtenir et vérifier les informations d'archive, tels que le besoin de maintenir 2 copies de l'archive sous le contrôle de 2 personnes, et que les 2 copies soient comparées pour s'assurer que les informations sont valides.

5.6 Renouvellement des clés

   Ce sous-composant décris les procédures pour fournir une nouvelle clé aux utilisateurs de la CA après un renouvellement de clé par la CA. Ces procédures peuvent être les même que les procédures pour fournir la clé courante. Également, la nouvelle clé peut être certifiée dans un certificat signé en utilisant l'ancienne clé.

5.7 Récupération après sinistre ou compromission

   Ce sous-composant décris les pré-requis liées à la notification et les procédures de récupérations dans le cas d'une compromission ou d'un sinistre. Chaque point suivant doit être adressé séparément

- L'identification ou la liste des incidents et compromissions applicable et les procédure de gestion et de reporting.
- Les procédures de récupération utilisée si les ressources informatiques, logiciels et/ou données sont corrompues ou suspectée comme tel. Ces procédures décrivent comment un environnement sécurisé est ré-établis, quels certificats sont révoqués, si la clé de l'entité est révoquée, comme la nouvelle clé publique est fournie aux utilisateurs, et comment les sujets sont re-certifiés.
- Les procédures de récupération utilisées si la clé de l'entité est compromise. Ces procédures décrivent comment un environnement est ré-établis, comme la nouvelle clé de l'entité publique est fournie aux utilisateurs, et comment les sujets sont re-certifiés.
- Les capacités de l'entité pour s'assurer de la continuité du business après un sinistre naturel ou autre. De telles capacités peuvent inclure la disponibilité d'un site distant sur lequel les opérations peuvent être récupérées. Il peut également inclure les procédures pour sécuriser ses facilités durant la période de temps suivant un désastre naturel ou autre et avant un rétablissement d'un environnement sécurisé, soit sur le site original, soit sur un site distant. Par exemple, les procédures pour protéger contre le vol de matériel sensible sur un site endommagé par un séisme.

5.8 Cessation de CA ou RA

   Ce sous-composant décris les requis liées aux procédures pour la notification de cessation et la cessation d'une CA ou RA, incluant l'identité du gardien des documents d'archive de la CA ou RA.

6. Contrôles de sécurité technique

   Ce composant est utilisé pour définir les mesures techniques prises par la CA émettrice pour protéger ses clés cryptographique et données d'activation (par ex, PIN, mot de passe, ou clé partagées gérées manuellement). Ce composant peut également être utilisé pour imposer des contraintes sur les dépôts, sujets CA, souscripteur, et autres participants pour protéger leur clés privées, données d'activation pour leur clé privées, et paramètres de sécurité critique. La gestion de clé sécurisé est critique pour s'assurer que tous les secrets et clés privées et données d'activation sont protégées et utilisés seulement par le personnel autorisé.

   Ce composant décris également d'autres contrôles de sécurité technique utilisées par la CA émettrice pour effectuer les fonctions sécurisées de génération de clé, d'authentification de l'utilisateur, d'enregistrement de certificat, de révocation de certificat, d'audit, et d'archivage. Les contrôle techniques incluent les contrôle de sécurité du cycle de vie ( incluant la sécurité de l'environnement de développement logiciel, la méthodologie de développement logiciel) et les contrôles de sécurité opérationnel.

   Ce composant peut également être utilisé pour définir d'autres contrôles de sécurité technique sur les dépôts, sujets CA, RA, souscripteurs, et autres participants.

6.1 Génération et installation de paire de clé

   La génération et l'installation de paire de clé doit être considéré pour la CA émettrice, les dépôts, sujets de CA, RA, et souscripteurs. Pour chacun de ces types d'entité, les questions suivantes peuvent potentiellement être répondues:

1. Qui génère l'entité publique, la paire de clé? Cela peut être le souscripteur, la RA, ou la CA. Également, comment est effectuée la génération de la clé? Est-ce que la génération de clé est faite par un hardware ou un software?
2. Comment est fournie la clé privée à l'entité de manière sécurisée? Par exemple, une situation où l'entité l'a généré et donc l'a déjà, qui manipule physiquement la clé privée, envoie un jeton contenant la clé privée de manière sécurisée ou en la délivrant dans une session SSL.
3. Comment la clé publique de l'entité est fournie de manière sécurisée à l'autorité de certification? Certaines possibilités sont dans une session SSL ou dans un message signé par la RA.
4. Dans le cas de la CA, comment la clé publique de la CA est fournie aux tiers de confiance de manière sécurisée.
5. Quels sont les tailles de clé?
6. Qui génère les paramètres de la clé publique, et est-ce que la qualité des paramètres sont vérifiés durant la génération?
7. Dans quel but la clé peut être utilisée, ou quel usage de clé est interdite? Pour les certificats X.509v3, ces but devraient être mappés dans les flags d'utilisation de clé.

6.2 Contrôles de Protection de clé privé et de module cryptographique

   Les pré-requis pour la protection de la clé privée et des modules cryptographiques doivent être considérés pour la CA emettrice, les dépôts, les sujets de CA, RA, et souscripteurs. Pour chacun de ces types ou entités, les questions suivantes doivent être répondue:

1. Quels standards, s'il y en a, sont requis pour le module cryptographique utilisé pour générer les clé? Un module cryptographique peut être composé de hardware, software, firmware, ou une combinaison. Par exemple, est-ce que les clé certifiées par l'infrastructure doivent être générés en utilisant des modules conformes FIPS 140-1? Si c'est le cas, quel est le niveau FIPS 140-1 du module? Y'a t'il une autre ingénierie ou d'autres contrôles liés au module cryptographique, tel que l'identification des limites du module cryptographique, l'entrée/sortie, les rôles et services, l'état de la machine, la sécurité physique, la sécurité logiciel, la sécurité du système d'exploitation, la conformité des algorithmes, la compatibilité éléctro-magnétique, et les selfs tests.
2. Est-ce que la clé privée est sous contrôle de n de m personnes. Si c'est le cas, fournir n et m (2 contrôleurs est un cas spécial où n=m=2)
3. Est-ce que la clé privée est entiercée? si c'est le cas, qui est l'agent d'entièrcement, sous quelle forme est la clé entiercée (texte clair, chiffré, splitté), et quels sont les contrôles de sécurités dans le système d'entièrcement?
4. Est-ce que la clé privée est sauvegardée? Si c'est le cas, qui est l'agent de sauvegarde, sous quelle forme est la clé sauvegardée, et quels sont les contrôles de sécurité dans le système de sauvegarde?
5. Est-ce que la clé privée est archivée? Si c'est le cas, qui est l'agent d'archivage, sous quelle forme est archivée la clé, et quels sont les contrôles de sécurité dans le système d'archivage?
6. Sous quelles circonstances, s'il y en a, la clé privée peut être transférée dans ou depuis un module cryptographique? Qui est autorisé à effectuer une telle opération de transfert? Sous quelle forme est la clé privée durant le transfert?
7. Comment est stocké la clé privée dans le module?
8. Qui peut activer (utiliser) la clé privée? Quelles actions doivent être effectués pour activer la clé privée (ex: login, mise en route, fournir un PIN, insérer la clé/jeton, automatique, etc.)? Une fois la clé activée, est-ce que la clé est active pour une période indéfinie, active pour une seule fois, ou pour une période définie?
9. Qui peut désactiver la clé privée et comment? des exemples des méthodes de désactivation de clés privée incluent la déconnexion, suppression de la clé/jeton, désactivation automatique, et date d'expiration.
10. Qui peut détruire la clé privée et comment? Par exemple, la remise symbolique, la destruction symbolique, et écraser la clé.
11. Fournir les capacité du module cryptographique dans les zones suivantes: identification des limites du module cryptographique, entrée/sortie, rôles et services, état de la machine, sécurité physique, sécurité logiciel, sécurité du système d'exploitation, conformité des algorithmes, compatibilité éléctromagnétique, et selfs tests. Les capacités peuvent être exprimés via une référence de conformité avec un standard tel que FIPS 140-1 et le niveau associé.

6.3 Autres aspects de la gestion de paire de clés

   D'autres aspects de gestion de clé doivent être considérés pour la CA émettrice, les dépôts, les sujets CA, RA, souscripteurs, et d'autres participants. Pour chacun de ces types d'entité, les questions suivante ont potentiellement besoins d'être répondues:

1. Est-ce que la clé publique est archivée? Si c'est le cas, qui est l'agent d'archivage et quels sont les contrôles de sécurité sur le système d'archivage? Également, quel logiciel et hardware doit être conservé comme partie de l'archive pour permettre d'utiliser la clé publique dans le temps? Note: ce sous-composant n'est pas limité aux requis aux pré-requis ou à la description de l'utilisation des signatures numériques avec les données d'archive, mais peut adresser les contrôles d'intégrité autre que les signatures numériques quand une archive nécessite une protection contre l'altération. Les signatures numériques ne fournissent pas de protection contre l'altération ou de protection de l'intégrité des données; Elles vérifient simplement l'intégrité des données. De plus, la période d'archivage peut être supérieur à une signature numérique appliquée à la donnée archivée.
2. Quel est la période opérationnelle des certificats émis au souscripteur. Quelles périodes d'utilisation, ou durée de vie, pour les paires de clé du souscripteur?

6.4 Données d'activation

   Les données d'activation réfèrent aux valeurs de données autre que les clé privées qui sont nécessaire pour opérer les clés privées ou les modules cryptographique contenant les clés privées, tels qu'un PIN, passphrases, ou portions d'une clé privée utilisées dans un schéma de splitting de clé. La protection des données d'activation empêchent l'utilisation non autorisée de la clé privée, et les besoins potentiels à considérer pour la CA émettrice, les sujets CA, RA, et les souscripteurs. Une telle considération nécessite potentiellement d'adresser tout le cycle de vie des données d'activation depuis la génération jusqu'à l'archivage et la destruction. Pour chaque types d'entité (CA émettrice, sujets CA, RA, souscripteur, et autres participants), toutes les questions listées en 6.1 à 6.3 peuvent potentiellement être répondus en respect des données d'activation au lieu du respect des clés.

6.5 Contrôles de sécurité informatique

   Ce sous-composant est utilisé pour décrire les contrôles de sécurité informatique tels que: l'utilisation de concept de base de calcul de confiance, le contrôle d'accès discrétionnaire, le contrôle d'accès obligatoire, la réutilisation d'object, l'audit, d'identification et l'authentification, les chemin de confiance, les tests de sécurité, et les tests de pénétration. L'assurance de produit peut également être adressé.

   Un taux de sécurité informatique pour les systèmes informatiques peut être requis. Le taux peut être basé, par exemple, sur le Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), ou le Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. Ce sous-composant peut également adresser les requis pour l'analyse de l'évaluation de produit, tests, profilage, certification de produit, et/ou accréditation de produit lié à l'activité entreprise.

6.6 Contrôles de sécurité du cycle de vie

   Ce sous-composant adresse les contrôles de développement système et les contrôles de gestion de la sécurité.

   Les contrôles de développement système incluent la sécurité de l'environnement de développement, la sécurité du personnel de développement, la sécurité de la gestion de configuration durant la maintenance produit, les pratique d'ingénierie logiciel, la méthodologie de développement logiciel, la modularité, couches, l'utilisation de concepts à sécurité intégrée et implémentation technique et sécurité des facilités de développement.

   Les contrôles de gestion de sécurité incluent l'exécution d'outils et de procédures pour s'assurer que les systèmes opérationnels et réseaux adhèrent à la sécurité configurée. Ces outils et procédures incluent la vérification de l'intégrité du logiciel de sécurité, firmware, et hardware pour s'assurer de leur opérations correct.

   Ce sous-composant peut également adresser le cycle de vie de la sécurité basé par exempel, sur Trusted Software Development Methodology (TSDM) niveau IV et V, independent life-cycle security controls audit, et Software Engineering Institute's Capability Maturity Model (SEI-CMM).

6.7 Contrôles de sécurité réseaux

   Ce sous-composant adresse les contrôles liés à la sécurité des réseaux, incluant les firewalls.

6.8 Horodatage

   Ce sous-composant adresse les requis ou pratiques liées à l'utilisation d'horodatage de diverses données. Il peut également discuter de si l'application de l'horodatage doit utiliser une source de temps fiable.

7. Profils de certificat et de CRL

   Ce composant est utilisé pour spécifier le format de certificat et, si des CRL et/ou OCSP sont utilisés, le format de CRL et/ou OCSP. Cela inclus les informations dans les profils, versions, et extensions utilisées.

7.1 Profil de certificat

   Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 3280.

- Les versions supportées
- Les extensions de certificat utilisées et leur criticité
- Les identifiant d'objet d'algorithmes cryptographiques
- Les formes de nom utilisé pour la CA, RA, et les noms des souscripteurs
- Les contraintes de nom utilisés et les formes de nom utilisé dans les contraintes de nom
- Les OID de CP applicable
- L'utilisation de l'extension de contrainte de stratégie
- La syntaxe et sémantiques des qualifiants de stratégie
- Les sémantiques de traitement pour l'extension critique CP

7.2 Profile de CRL

   Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 3280.

- Les numéro de version supportés
- Les extensions d'entrée de CRL utilisées et leur criticité

7.3 Profile OCSP

   Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 2560.

- La version d'OCSP qui est utilisé comme base pour établir un système OCSP
- Les extensions OCSP utilisés et leur criticité

8 Audit et autres évaluations de conformité

   Ce composant adresse les sujets suivants:

- La liste des sujets couverts par l'évaluation et/ou la méthodologie d'évaluation utilisée pour effectuer l'évaluation; par exemple WebTrust pour les CA et SAS 70.
- La fréquence de l'audit de conformité ou autres évaluations pour chaque entité qui doit être évalué conformément à une CP ou CPS, ou les circonstances qui vont déclencher une évaluation; par exemple un audit annuel, évaluation pré-opérationnelle comme condition d'autorisation pour une entité d'être opérationnelle, ou des investigations suivant une possible compromission de la sécurité.
- L'identité et/ou les qualifications du personnel effectuant l'audit ou autre évaluation.
- La relation entre l'évaluateur et l'entité qui est évaluée, incluant le degré d'indépendance de l'évaluateur.
- Les actions prises en résultat de déficience trouvé durant l'évaluation; par exemple, une suspension temporaire des opérations jusqu'à ce que la déficience soit corrigée, la révocation de certificats émis par l'entité évaluée, le changement de personnel, les investigations spéciales ou des évaluation de conformité plus fréquentes, et les demandes pour les dommages contre l'entité évaluée.
- Qui est habilité à voir les résultat d'une évaluation (ex, les entités évaluées, d'autres participant, tout le monde), qui leur fournis, et comment ils sont communiqués.

9 Autre questions juridiques et sur l'entreprise

   Ce sous-composant couvre les questions juridiques et liées à l'entreprise. Les sections 9.1 et 9.2 discutent des questions d'entreprise de redevances à percevoir pour divers services et les responsabilités financières des participants pour maintenir les ressources pour les opérations en cours et pour le payements des jugements ou règlement en réponse aux allégations formulées contre eux. Les sections restantes sont plus généralement concernés par les sujets légaux.

   À partir de la section 9.3, l'ordre des sujets est le même que l'ordre des sujets dans un agrément de licence logiciel ou autre agrément technologique. En conséquence, ce framework n'est pas seulement pour les CP et CPS, mais également associé aux agréments liés à la PKI, spécialement les agréments de souscripteur et de tiers de confiance. Cet ordre est prévu pour aider les avocats examinant les CP, CPS et autres documents qui adhèrent à ce cadre.

   En respect à de nombreux sous-composant légaux dans ce composant, une rédacteur de CP ou CPS peut choisir d'inclure dans le document les termes et conditions qui s'appliquent directement aux souscripteurs ou tiers de confiance. Par exemple, une CP ou CPS peut énoncer les limitations de responsabilité applicables aux souscripteurs et tiers de confiance. L'inclusion des termes et conditions est plus approprié dans les cas où la CP ou CPS est elle-même un contrat ou partie d'un contrat.

   Dans d'autres cas, cependant, la CP ou CPS n'est pas un contrat ou partie d'un contrat; à la place, elle est configurée pour que ses termes et conditions soient appliquées aux parties par des documents séparés, qui peuvent inclure des agréments associés, tels qu'un agrément de souscripteur ou tiers de confiance. Dans ce cas, un rédacteur de CP peut écrire une CP de façon à exiger que certaines conditions juridiques apparaissent (ou n'apparaissent pas) dans de tels agréments. Par exemple, une CP pour inclure un sous-composant statuant qu'un certain terme de limitation de responsabilité apparaisse dans les agréments de souscripteur et de tiers de confiance. Un autre exemple est une CP qui contient un sous-composant interdisant l'utilisation d'un agrément de souscripteur ou de tiers de confiance contenant une limitation de la responsabilité de la CA incompatible avec les disposition de la CP. Un rédacteur de CPS peut utiliser des sous-composants légaux pour divulguer que certains termes et conditions apparaissent dans des agréments de souscripteur, de tiers de confiance, ou d'autres, associé, utilisé par la CA. Une CPS peut expliquer, par exemple, que la CA écris qu'elle utilise un agrément de souscripteur ou de tiers de confiance associé qui applique une disposition particulière pour limiter la responsabilité.

9.1 Honoraires

   Ce sous-composant contient les dispositions applicables liés aux frais des CA, dépôts, ou RA, tels que:

- frais d'émission ou de renouvellement de certificat
- frais d'accès au certificat
- frais d'accès aux informations de status ou de révocation
- frais pour d'autres services tels que ceux fournissant l'accès aux CP ou CPS
- Stratégies de remboursement

9.2 Responsabilité financière

   Ce sous-composant contient les pré-requis ou les informations relatives aux ressources disponible aux CA, RA, et autres participants fournissant des services de certification pour supporter l'exécution de leurs responsabilité opérationnels, et pour rester solvable et payer les dommages dans le cas où ils sont tenus de payer un jugement ou un règlement dans le cadre d'une réclamation résultant de ces opérations. De telles dispositions incluent:

- Une déclaration que le participant maintient un certain montant de couverture d'assurance pour ses engagements envers les autres participants.
- Une déclaration que le participant a accès à d'autres ressources pour supporter les opérations et payer les dommages pour la responsabilité potentielle, qui peut être formulée en termes d'un niveau minimum d'actifs nécessaires pour opérer et couvrir les imprévus qui pourraient survenir au sein d'une PKI, par exemple, les actifs sur le bilan d'une organisation, un cautionnement, une lettre de crédit, et un droit en vertu d'un accord pour une indemnité sous certaines circonstances.
- Une déclaration qu'un participant a un programme qui offre une assurance de première partie ou la protection de garantie à d'autres participants dans le cadre de leur utilisation de la PKI.

9.3 Confidentialité des informations de l'entreprise

   Ce sous-composant contient les dispositions liées au traitement des information confidentielles de l'entreprise que les participants peuvent communiquer aux autres, tels que les business plan, informations de vente, secrets bancaires, et autres informations reçues d'un tiers de confiance sous un agrément de non-divulgation. spécifiquement, ce sous-composant adresse:

- Le périmètre de ce qui est considéré comme information confidentielle.
- Les types d'informations qui sont considérés hors périmètre des informations confidentielles
- Les responsabilités des participants qui reçoivent des informations confidentielles pour éviter une compromission, et éviter des les utiliser ou les divulguer à des tiers.

9.4 Confidentialité des renseignements personnels

   Ce sous-composant est lié à la protection que les participants, particulièrement les CA, RA, et dépôts, peut nécessiter pour permettre d'identifier les informations privées personnelles des candidats de certificat, souscripteurs, et autres participants. Spécifiquement, ce sous-composant adresse les éléments suivant:

- La désignation et divulgation du plan de protection des renseignements personnels applicables qui s'appliquent aux activités des participants, si requis par la stratégie ou la loi applicable.
- Les informations qui sont considérés ou non privée dans la PKI
- Toute responsabilité des participants qui reçoivent des informations privée pour les sécuriser, et éviter leur utilisation ou divulgation à des tiers.
- Tout prérequis pour avis, ou le consentement des individus concernant l'utilisation ou la divulgation d'informations privées.
- Toutes circonstances sous lesquelles un participants a droit ou est tenus de divulguer des informations privées en vertu judiciaire, traitement administratif dans un processus privée ou gouvernemental, ou tout traitement légal.

9.5 Droits de propriété intellectuelle

   Ce sou-composant adresse les droits de propriété intellectuelle, tels que les droits d'auteur, brevets, marques, ou secrets commerciaux, que certains participants peuvent avoir ou réclamer dans une CP, CPS, certificats, noms, et clés, ou font l'objet d'une licence ou de participant.

9.6 Représentations et garanties

   Ce sous-composant peut inclure des représentations et garanties de divers entités qui sont faites en vertu de la CP ou CPS. Par exemple, une CPS qui sert de contrat peut contenir une garantie de la CA que les informations contenus dans le certificat sont précis. Alternativement, une CPS peut contenir une garantie moins étendue où les informations dans le certificat sont vrai au mieux de la connaissance de la CA après avoir effectué certaines procédures d'authentification de l'identité. Ce sous-composant peut également inclure des prérequis que les représentations et garanties apparaissent dans certains agréments. Par exemple, une CP peut contenir un prérequis qui toutes les CA utilisent un agrément de souscripteur, et qu'un agrément de souscripteur doit contenir une garantie par la CA que les informations dans le certificat est précis. Les participants qui peuvent faire les représentation et garanties incluent les CA, RA, souscripteurs, tiers de confiance, et autres participants.

9.7 exclusions de garanties

   Ce sous-composant peut inclure des exclusions de garanties expresses qui pourraient être réputé exister dans un accord, et les exclusions de garanties implicites qui pourraient être imposées par la loi applicable, tels que les garanties de qualité marchande ou d'adéquation pour un but particulier. La CP ou CPS peut directement imposer de tels exclusions, ou la CP ou CPS peut maintenir une obligation que les exclusions apparaissent dans les agrément associés.

9.8 Limitations de responsabilité

   Ce sous-composant peut inclure des limitations de responsabilité dans une CP ou CPS ou des limitations qui apparaissent ou doivent apparaître dans un agrément associés avec la CP ou CPS. Ces limitations peuvent rentrer dans un des deux catégories: les limitations sur les éléments de dommages récupérables et les limitations sur la quantité de dommage récupérable, également connus sous le terme plafonnement de responsabilité. Souvent, les contrats contiennent des clauses empêchant la récupération d'éléments de dommage tels qu'un dommage accessoire et indirect, et les dommage punitifs. Fréquemment, les contrats contiennent des clauses qui limitent la possible récupération d'une partie ou l'autre à un certain montant ou à un montant correspondant à un indice de référence, tels que le montant qu'un vendeur a été payé en vertu du contrat.

9.9 Indémité

   Ce sous-composant inclus les dispositions par lesquelles un partie utilise envers un second partie pour les pertes ou dommages encourus par le second partie, résultant généralement de la conduite de la première partie. Ils peuvent apparaîtrent dans une CP, CPS, ou agrément. Par exemple, une CP peut nécessiter que les agréments de souscripteur contiennent un terme sous lequel un souscripteur est responsable de l'indemnisation de la CA pour les pertes que la CA soutient découlant de fausses déclarations d'un souscripteur dans la demande de certificat en vertu de laquelle la CA a émis au souscripteur un certificat inexact. Similairement, une CPS peut dire qu'une CA utilise un agrément de tiers de confiance, sous lequel les tiers de confiance sont responsable de l'indemnisation d'une CA en cas de perte que la CA soutient à cause de l'utilisation d'un certificat sans vérifier les informations de révocation de statut ou l'utilisation d'un certificat dans un but que la CA n'a pas permis.

9.10 Durée et résiliation

   Ce sous-composant peut inclure la durée dans laquelle une CP ou CPS demeure en vigueur et les circonstances sous lesquelles le document, portions du document, ou son applicabilité à un participant particulier peut être terminé. En plus ou alternativement, la CP ou CPS peut inclure les exigences que certaines clause de durée et de résiliation apparaissent dans un agrément. En particulier, de tels termes incluent:

- La durée d'un document ou agrément, c'est à dire, quand le document devient effectif et quand il expire s'il n'est pas résilié plus tôt
- Les dispositions de résiliation statuant sur les circonstances sous lesquelles le document, certaines portions, ou son application à un participant particulier cesse d'être en effet.
- Les conséquences de résiliation du document. Par exemple, certaines dispositions d'un agrément peuvent survivre à la résiliation et rester en vigueur. Des exemples incluent la connaissance des droits de propriété intellectuelle et les dispositions de confidentialité. Également, la résiliation peut impliquer une responsabilité des parties de retourner les informations confidentielles au partie qui l'a divulgué.

9.11 Remarques individuels et communications avec les participants

   Ce sous-composant discute de la manière par laquelle un participant peut ou doit communiquer avec un autre participant sur une base 1 à 1 pour qu'une telle communication soit légalement effective. Par exemple, une RA peut souhaiter informer la CA qu'elle souhaite terminer sont agrément avec la CA. Ce sous-composant est différent des fonctions de publication et de dépôt, parce contrairement aux communications individuelles décrites dans ce sous-composant, la publication et l'envoi dans un dépôt servent à communiquer à une large audience. Ce sous-composant peut établir des mécanismes pour communiquer et indiquer les informations de contact à utiliser pour router de telles communications, tel que les email signés numériquement à une adresse spécifique, suivie par un email signé d'accusé de réception.

9.12 Modifications

   Si sera occasionnellement nécessaire d'amender une CP ou CPS. Certains de ces changements ne vont pas réduire matériellement l'assurance qu'une CP ou son implémentation fournis, et sera jugé par l'administrateur de stratégie sur l'effet insignifiant de l'acceptabilité des certificats. De tels changement dans une CP ou CPS ne nécessitent pas de changement dans l'OID de CP ou le pointeur CPS. D'une autre manière, certains changements dans une spécification va changer matériellement l'acceptabilité des certificats pour des buts spécifiques, et ces changement peuvent nécessiter des changements correspondant à l'OID de la CP ou le pointeur CPS. Ce sous-composant peut également contenir les informations suivantes:

- Les procédures par lesquelles la CP ou CPS et/ou les autres documents doivent, peuvent être, ou sont amendés. Dans le cas des amendements de CP ou CPS, les procédures de changement peuvent inclure un mécanisme de notification pour fournir des avis de modifications proposées aux parties concernées, tels que les souscripteurs ou tiers de confiance, une période de commentaire, un mécanisme par lequel les commentaires sont reçus, revus, et incorporés dans le document, et un mécanisme par lequel les amendements deviennent effectifs.
- Les circonstances sous lesquelles les amendements de CP ou CPS nécessitent un changement d'OID ou pointeur de CPS.

9.13 Procédures de règlement de différends

   Ce sous-composant discute des procédures utilisée pour résoudre les différents découlant des CP, CPS et/ou agréments. Des exemples de telles procédures incluent l'exigence qu'un différent soit résolu dans un certain forum ou par des mécanismes de résolutions de différents alternatifs.

9.14 Lois gouvernementales

   Ce sous-composant énonce une déclaration que la loi d'une certaine juridiction régit l'interprétation et l'application de la CP ou CPS ou agréments.

9.15 Conformité avec les lois applicables

   Ce composant a trait aux conditions énoncées que les participants se conforment avec les lois applicables, par exemple, les lois liées au hardware et software cryptographique que peuvent être sujet aux lois de contrôle d'export d'une juridiction donnée. La CP ou CPS pourrait prétendre imposer de telles exigences ou peuvent exiger que ces dispositions figurent dans d'autres agréments.

9.16 Dispositions diverses

   Ce sous-composnat contient diverses dispositions, parfois appelé "dispositions passe-partout" dans les contrats. Les clauses couvertes dans ce sous-composant peuvent apparaître dans une CP, CPS, ou agréments et inclus:

- Une clause d'agrément entière, qui identifie typiquement le document ou les documents comprenant l'intégralité de l'agrément entrée les parties et status que ces agrément remplacent tous les accords antérieurs et actuels écris ou compris oralement relatifs à la même question.
- Une clause de cession, qui peut agir pour limiter la capacité d'un partie dans un agrément, l'attribution de ses droits en vertu de l'accord à un autre partie (comme le droit de recevoir un flux de paiement dans le future) ou de limiter la capacité d'un partie à déléguer ses obligations en vertu de l'accord.
- Une clause de divisibilité, qui énonce les intentions des parties dans le cas où une cour ou un autre tribunal détermine qu'une clause dans un agrément est, pour certaines raisons, invalides ou non-applicables, et dont le but est fréquemment d'empêcher l'inapplicabilité d'une clause causant l'ensemble de l'agrément inapplicable.
- Une clause d'application, qui peut indiquer qu'un partie gagnant dans un litige découlant d'un accord a droit à des honoraires d'avocats dans le cadre de sa récupération, ou peut statuer que le renoncement d'un partie d'une rupture de contrat d'un partie ne constitue par un renoncement permanent, ou un renoncement future ou autres violation de contrat.
- Un clause de force majeur, communément utilisée pour excuser la performance d'un ou plusieurs partie à un accord en raison d'un événement hors du contrôle raisonnable de ou des parties affectées. En règle générale, la durée de l'exécution dispensée est proportionnelle à la durée du retard causé par l'événement. La clause peut également prévoir la résiliation de l'accord dans les circonstances et conditions spécifiées. Les événements considérés pour constituer une force majeur peut inclure ce que l'on appelle les "actes de dieu", les guerres, terrorisme, grèves, catastrophes naturelles, défaillances de fournisseurs ou vendeurs, ou défaillances de l'internet ou autre infrastructure. Les clauses de force majeur doivent être rédigées de manière à être compatibles avec d'autres parties du framework et des agrément de niveau de service applicable. Par exemple, les responsabilités et les capacités de continuation d'activité et de reprise sur incident peut placer des événements sous le contrôle raisonnable des parties, telles qu'une obligation de maintenir une alimentation électrique de secours.

9.17 Autres Dispositions

   Ce sous-composant est "fourre-tout" où des responsabilités additionnelles et termes peuvent être imposés aux participants de la PKI qui ne rentre par nécessairement dans une autre catégorie de ce framework. Les rédacteurs de CP et CPS peut placer toute disposition dans ce sous-composant qui n'est pas couvert par un autre sous-composant.

Considérations de sécurité

   En accord avec X.509, une stratégie de certificat est un jeu nommé de règles qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou classe d'applications avec des exigences de sécurité particulières. Une CP peut être utilisée par un tiers de confiance pour aider à décider si un certificat, et sa liaison, sont suffisamment dignes de confiance et appropriés à une application particulière.

   Le dégré auquel un tier de confiance peut avoir confiance à la liaison embarquée dans un certificat dépend de nombreux facteurs. Ces facteurs peuvent inclure les pratiques suivies par l'autorité de certification en authentifiant le sujet; la stratégie d'opération de la CA, les procédures, et les contrôles de sécurité techniques, incluant de scope des responsabilités des souscripteurs (par exemple, en protégeant la clé privée), et les responsabilités statué et les termes de responsabilités de la CA (par exemple, les garanties, déclarations de garanties, et les limitations de responsabilité).

   Ce document fournis un framework pour adresser les aspects techniques, procédurales, personnelles, et physiques des autorités de certification, d'enregistrement, les dépôts, souscripteurs, et modules cryptographiques de confiance, pour s'assurer que la génération de certificats, la publication, le renouvellement, changement de clé, utilisation, et révocation est faite de manière sécurisée.

Plan d'un jeu de dispositions

   Cette section contient un plan recommandé pour un jeu de dispositions prévues pour servir de checklist ou de template standard à utiliser par les rédacteurs de CP ou CPS. Un tel plan facilite:

- La comparaison entre 2 stratégies de certificats durant la cross-certification ou d'autres formes d'interopérations.
- La comparaison d'une CPS avec une CP pour s'assurer que la CPS implémente fidèlement la stratégie
- La comparaison entrée 2 CPS.

   Afin de se conformer à cette rfc, les rédacteurs d'une CP ou CPS conformes sont fortement encouragés à adhérer à ce plan. Bien que l'utilisation d'un plan alternatif est découragé, il peut être accepté si une justification est fournie pour la déviation et une table de mappage est fournie pour discerner clairement où chaque éléments décris dans ce plan est fournis.


1. INTRODUCTION
1.1 Overview
1.2 Document name and identification
1.3 PKI participants
1.3.1 Certification authorities
1.3.2 Registration authorities
1.3.3 Subscribers
1.3.4 Relying parties
1.3.5 Other participants
1.4 Certificate usage
1.4.1. Appropriate certificate uses
1.4.2 Prohibited certificate uses
1.5 Policy administration
1.5.1 Organization administering the document
1.5.2 Contact person
1.5.3 Person determining CPS suitability for the policy
1.5.4 CPS approval procedures
1.6 Definitions and acronyms
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.1 Repositories
2.2 Publication of certification information
2.3 Time or frequency of publication
2.4 Access controls on repositories
3. IDENTIFICATION AND AUTHENTICATION (11)
3.1 Naming
3.1.1 Types of names
3.1.2 Need for names to be meaningful
3.1.3 Anonymity or pseudonymity of subscribers
3.1.4 Rules for interpreting various name forms
3.1.5 Uniqueness of names
3.1.6 Recognition, authentication, and role of trademarks
3.2 Initial identity validation
3.2.1 Method to prove possession of private key
3.2.2 Authentication of organization identity
3.2.3 Authentication of individual identity
3.2.4 Non-verified subscriber information
3.2.5 Validation of authority
3.2.6 Criteria for interoperation
3.3 Identification and authentication for re-key requests
3.3.1 Identification and authentication for routine re-key
3.3.2 Identification and authentication for re-key after revocation
3.4 Identification and authentication for revocation request
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11)
4.1 Certificate Application
4.1.1 Who can submit a certificate application
4.1.2 Enrollment process and responsibilities
4.2 Certificate application processing
4.2.1 Performing identification and authentication functions
4.2.2 Approval or rejection of certificate applications
4.2.3 Time to process certificate applications
4.3 Certificate issuance
4.3.1 CA actions during certificate issuance
4.3.2 Notification to subscriber by the CA of issuance of certificate
4.4 Certificate acceptance
4.4.1 Conduct constituting certificate acceptance
4.4.2 Publication of the certificate by the CA
4.4.3 Notification of certificate issuance by the CA to other entities
4.5 Key pair and certificate usage
4.5.1 Subscriber private key and certificate usage
4.5.2 Relying party public key and certificate usage
4.6 Certificate renewal
4.6.1 Circumstance for certificate renewal
4.6.2 Who may request renewal
4.6.3 Processing certificate renewal requests
4.6.4 Notification of new certificate issuance to subscriber
4.6.5 Conduct constituting acceptance of a renewal certificate
4.6.6 Publication of the renewal certificate by the CA
4.6.7 Notification of certificate issuance by the CA to other entities
4.7 Certificate re-key
4.7.1 Circumstance for certificate re-key
4.7.2 Who may request certification of a new public key
4.7.3 Processing certificate re-keying requests
4.7.4 Notification of new certificate issuance to subscriber
4.7.5 Conduct constituting acceptance of a re-keyed certificate
4.7.6 Publication of the re-keyed certificate by the CA
4.7.7 Notification of certificate issuance by the CA to other entities
4.8 Certificate modification
4.8.1 Circumstance for certificate modification
4.8.2 Who may request certificate modification
4.8.3 Processing certificate modification requests
4.8.4 Notification of new certificate issuance to subscriber
4.8.5 Conduct constituting acceptance of modified certificate
4.8.6 Publication of the modified certificate by the CA
4.8.7 Notification of certificate issuance by the CA to other entities
4.9 Certificate revocation and suspension
4.9.1 Circumstances for revocation
4.9.2 Who can request revocation
4.9.3 Procedure for revocation request
4.9.4 Revocation request grace period
4.9.5 Time within which CA must process the revocation request
4.9.6 Revocation checking requirement for relying parties
4.9.7 CRL issuance frequency (if applicable)
4.9.8 Maximum latency for CRLs (if applicable)
4.9.9 On-line revocation/status checking availability
4.9.10 On-line revocation checking requirements
4.9.11 Other forms of revocation advertisements available
4.9.12 Special requirements re key compromise
4.9.13 Circumstances for suspension
4.9.14 Who can request suspension
4.9.15 Procedure for suspension request
4.9.16 Limits on suspension period
4.10 Certificate status services
4.10.1 Operational characteristics
4.10.2 Service availability
4.10.3 Optional features
4.11 End of subscription
4.12 Key escrow and recovery
4.12.1 Key escrow and recovery policy and practices
4.12.2 Session key encapsulation and recovery policy and practices
5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11)
5.1 Physical controls
5.1.1 Site location and construction
5.1.2 Physical access
5.1.3 Power and air conditioning
5.1.4 Water exposures
5.1.5 Fire prevention and protection
5.1.6 Media storage
5.1.7 Waste disposal
5.1.8 Off-site backup
5.2 Procedural controls
5.2.1 Trusted roles
5.2.2 Number of persons required per task
5.2.3 Identification and authentication for each role
5.2.4 Roles requiring separation of duties
5.3 Personnel controls
5.3.1 Qualifications, experience, and clearance requirements
5.3.2 Background check procedures
5.3.3 Training requirements
5.3.4 Retraining frequency and requirements
5.3.5 Job rotation frequency and sequence
5.3.6 Sanctions for unauthorized actions
5.3.7 Independent contractor requirements
5.3.8 Documentation supplied to personnel
5.4 Audit logging procedures
5.4.1 Types of events recorded
5.4.2 Frequency of processing log
5.4.3 Retention period for audit log
5.4.4 Protection of audit log
5.4.5 Audit log backup procedures
5.4.6 Audit collection system (internal vs. external)
5.4.7 Notification to event-causing subject
5.4.8 Vulnerability assessments
5.5 Records archival
5.5.1 Types of records archived
5.5.2 Retention period for archive
5.5.3 Protection of archive
5.5.4 Archive backup procedures
5.5.5 Requirements for time-stamping of records
5.5.6 Archive collection system (internal or external)
5.5.7 Procedures to obtain and verify archive information
5.6 Key changeover
5.7 Compromise and disaster recovery
5.7.1 Incident and compromise handling procedures
5.7.2 Computing resources, software, and/or data are corrupted
5.7.3 Entity private key compromise procedures
5.7.4 Business continuity capabilities after a disaster
5.8 CA or RA termination
6. TECHNICAL SECURITY CONTROLS (11)
6.1 Key pair generation and installation
6.1.1 Key pair generation
6.1.2 Private key delivery to subscriber
6.1.3 Public key delivery to certificate issuer
6.1.4 CA public key delivery to relying parties
6.1.5 Key sizes
6.1.6 Public key parameters generation and quality checking
6.1.7 Key usage purposes (as per X.509 v3 key usage field)
6.2 Private Key Protection and Cryptographic Module Engineering Controls
6.2.1 Cryptographic module standards and controls
6.2.2 Private key (n out of m) multi-person control
6.2.3 Private key escrow
6.2.4 Private key backup
6.2.5 Private key archival
6.2.6 Private key transfer into or from a cryptographic module
6.2.7 Private key storage on cryptographic module
6.2.8 Method of activating private key
6.2.9 Method of deactivating private key
6.2.10 Method of destroying private key
6.2.11 Cryptographic Module Rating
6.3 Other aspects of key pair management
6.3.1 Public key archival
6.3.2 Certificate operational periods and key pair usage periods
6.4 Activation data
6.4.1 Activation data generation and installation
6.4.2 Activation data protection
6.4.3 Other aspects of activation data
6.5 Computer security controls
6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating
6.6 Life cycle technical controls
6.6.1 System development controls
6.6.2 Security management controls
6.6.3 Life cycle security controls
6.7 Network security controls
6.8 Time-stamping
7. CERTIFICATE, CRL, AND OCSP PROFILES
7.1 Certificate profile
7.1.1 Version number(s)
7.1.2 Certificate extensions
7.1.3 Algorithm object identifiers
7.1.4 Name forms
7.1.5 Name constraints
7.1.6 Certificate policy object identifier
7.1.7 Usage of Policy Constraints extension
7.1.8 Policy qualifiers syntax and semantics
7.1.9 Processing semantics for the critical Certificate Policies extension
7.2 CRL profile
7.2.1 Version number(s)
7.2.2 CRL and CRL entry extensions
7.3 OCSP profile
7.3.1 Version number(s)
7.3.2 OCSP extensions
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
8.1 Frequency or circumstances of assessment
8.2 Identity/qualifications of assessor
8.3 Assessor's relationship to assessed entity
8.4 Topics covered by assessment
8.5 Actions taken as a result of deficiency
8.6 Communication of results
9. OTHER BUSINESS AND LEGAL MATTERS
9.1 Fees
9.1.1 Certificate issuance or renewal fees
9.1.2 Certificate access fees
9.1.3 Revocation or status information access fees
9.1.4 Fees for other services
9.1.5 Refund policy
9.2 Financial responsibility
9.2.1 Insurance coverage
9.2.2 Other assets
9.2.3 Insurance or warranty coverage for end-entities
9.3 Confidentiality of business information
9.3.1 Scope of confidential information
9.3.2 Information not within the scope of confidential information
9.3.3 Responsibility to protect confidential information
9.4 Privacy of personal information
9.4.1 Privacy plan
9.4.2 Information treated as private
9.4.3 Information not deemed private
9.4.4 Responsibility to protect private information
9.4.5 Notice and consent to use private information
9.4.6 Disclosure pursuant to judicial or administrative process
9.4.7 Other information disclosure circumstances
9.5 Intellectual property rights
9.6 Representations and warranties
9.6.1 CA representations and warranties
9.6.2 RA representations and warranties
9.6.3 Subscriber representations and warranties
9.6.4 Relying party representations and warranties
9.6.5 Representations and warranties of other participants
9.7 Disclaimers of warranties
9.8 Limitations of liability
9.9 Indemnities
9.10 Term and termination
9.10.1 Term
9.10.2 Termination
9.10.3 Effect of termination and survival
9.11 Individual notices and communications with participants
9.12 Amendments
9.12.1 Procedure for amendment
9.12.2 Notification mechanism and period
9.12.3 Circumstances under which OID must be changed
9.13 Dispute resolution provisions
9.14 Governing law
9.15 Compliance with applicable law
9.16 Miscellaneous provisions
9.16.1 Entire agreement
9.16.2 Assignment
9.16.3 Severability
9.16.4 Enforcement (attorneys' fees and waiver of rights)
9.16.5 Force Majeure
9.17 Other provisions

^
17 juin 2015

htmlpdflatexmanmd




rfc4210

rfc4210

Protocole de gestion de certificat des infrastructures à clé publique X.509

Introduction

   Ce document décris le protocole de gestion de certificat (CMP) des infrastructures à clé publique X.509. Les messages de protocole sont définis pour la création et la gestion des certificats. Le terme X.509 dans ce document réfère à un certificat X.509v3.

Définition des entités de PKI

   Les entités impliqués dans la gestion de PKI incluent l'entité finale et l'autorité de certification. Une autorité d'enregistrement peut également être utilisé.

Sujet et entités finales

   Le terme "subject" est utilisé ici pour référer à l'entité pour lequel le certificat est fournis, typiquement nommé dans le sujet ou le champ subjectAltName d'un certificat. Quand on souhaite distinguer les outils et/ou logiciels utilisés par le sujet (ex: un module de gestion de certificat local), on utilise le terme "subject equipment". En général, le terme "end entity" (EE), au lieu de "subject" est préféré pour éviter les confusions avec le nom du champ. Il est important de noter que les entités finales n'incluent pas seulement des utilisateurs humains d'applications, mais également les applications elles-mêmes. Ce facteur influence les protocoles que les opérations de gestion de PKI utilisent; par exemple, une application est plus susceptibles de savoir exactement quelles extensions de certificat sont nécessaires que ne le sont les utilisateurs humains.

   Les entités de gestion de PKI sont également des entités finales dans le sens qu'ils sont parfois nommés dans le sujet ou le subjectAltName d'un certificat ou un cross-certificate. Quand approprié, le terme "end entity" sera utilisé pour référer aux entités finales qui ne sont pas des entités de gestion de PKI.

   Toute entité finale nécessite un accès local sécurisé à certaines informations -- au minimum, son propre nom et clé privée, le nom d'une CA qui est directement trusté, et la clé publique de cette CA ( ou une empreinte de la clé publique où une version d'un certificat auto-fournis est disponible quelque part). Les implémentations peuvent utiliser un stockage local sécurisé pour plus que ce minimum. La forme de stockage varie également -- de simples fichier à des jetons cryptographiques inviolables. L'information stockée dans un tel stockage local est référé ici à l'environnement de sécurité personnel (PSE). Bien que les formats PSE sont au-delà du scope de ce document, un format générique d'échange pour les PSE est définis ici: un message réponse de certification peut être utilisé.

Autorité de certification

   L'autorité de certification peut ou non être un vrai tier de confiance du point de vue de l'entité finale. Très souvent, la CA appartient à la même organisation que les entités finales qu'elle supporte.

   De même, on utilise le terme CA pour référer à l'entité nommée dans le champ issuer d'un certificat. Quand il est nécessaire de distinguer les outils software ou hardware utilisé par la CA, on utilise le terme d'équipement CA. L'équipement CA inclus souvent un composant offline et un composant online, avec la clé privée de la CA uniquement disponible au composant offline.

   On utilise le terme "root CA" pour indiquer une CA qui est directement trusté par une entité finale; c'est à dire, acquérir de manière sécurité la valeur d'une clé publique d'une CA root nécessite certaines étapes out-of-band. Ce terme n'implique pas qu'une CA root soit nécessairement tout en haut d'une hiérarchie, simplement que la CA en question est trustée directement.

   Une CA subordonnée est une CA qui n'est pas une CA root pour l'entité finale. Souvent, une CA subordonnée ne sera une CA root pour aucune entité, mais ce n'est pas mandatoire.

   En plus des entités finales et des CA, de nombreux environnements font appel à un autorité d'enregistrement (RA) séparé de l'autorité de certification. Les fonctions du RA varie d'un cas à un autre mais peut inclure une authentification personnelle, la distribution de jetons, reporter la révocation, assignement de nom, génération de clé, archivage de paires de clé, etc.

   Ce document considère le RA comme composant optionnel: quand il n'est pas présent, la CA est supposé gérer les fonctions du RA, donc les protocoles de gestion de PKI sont les même du point de vue de l'entité finale. De même, on distingue le RA et les outils utilisés (les équipements RA).

   Noter qu'un RA est lui-même une entité finale. On assume que tous les RA sont en fait des entités finales certifiés et que les RA ont des clés privées qui sont utilisable pour la signature. La manière dont un équipement CA identifie des entités finales comme RA est un problème d'implémentation (par ex: Ce document ne spécifie pas d'opération de certification RA spécial). On ne mandate pas que le RA est certifié par la CA avec laquelle il inter-agit (donc un RA peut travailler avec plus d'une CA alors qu'il a été certifié une seule fois).

   Dans certaines circonstances, les entités finales vont communiquer directement avec une CA même quand un RA est présent. Par exemple, pour un enregistrement initial et/ou une certification, le sujet peut utiliser sont RA, mais communiquer directement avec le CA pour rafraîchir son certificat.

Pré-requis de gestion de PKI

   Les protocoles donnés ici nécessitent les pré-requis suivant pour la gestion de PKI:

1. La gestion de la PKI doit se conformer aux standards ISO/IEC 9594-8/ITU-T X.509
2. Il doit être possible de mettre à jour régulièrement une paire de clé sans affecter une autre paire de clé.
3. L'utilisation de la confidentialité dans les protocoles de gestion de PKI doit être conservé à un minimum pour pouvoir simplifier l'acceptation dans les environnements où une forte confidentialité peut causer des problèmes réguliers.
4. Les protocoles de gestion de PKI doivent permettre d'utiliser différents algorithmes cryptographiques ( incluant RSA, DSA, MD5 et SHA-1). Cela signifie qu'une CA, RA, ou entité finale donné, en principe, utilise les algorithmes qui lui conviennent pour ses propres paires de clés.
5. Les protocoles de gestion de PKI ne doivent pas pré-inclure la génération de paires de clé par l'entité finale concernée, par un RA, ou par une CA. La génération de clé peut également se produire n'importe où, mais dans le but de la gestion de PKI la clé est d'abord présente dans une entité finale, RA, ou CA.
6. Les protocoles de gestion de PKI doivent supporter la publication de certificats par l'entité finale concernée, par une RA, ou par une CA. Différences implémentations et différents environnements peuvent choisir n'importe quel approche ci-dessus.
7. Les protocoles de gestion de PKI doivent supporter la production de listes de révocation de certificat en permettant aux entités finales certifiées de créer des requêtes pour la révocation des certificats. Cela doit être fait de telle manière qu'une attaque DOS, qui est possible, ne soit pas simple.
8. Les protocoles de gestion de PKI doivent être utilisables sur une variété de mécanismes de transport, incluant les mails, http, TCP/IP et ftp.
9. L'autorité finale pour la création des certificats incombe à la CA. Aucune RA ou équipement d'entité finale ne peut supposer qu'un certificat fournis par une CA contienne ce qui a été demandé; Une CA peut altérer les valeurs de champs de certificat ou peut en ajouter, supprimer, ou modifier les extensions en accord à ses stratégies. En d'autres terme, toutes les entités PKI (entités finales, CA et CA) doivent être capable de manipuler les réponses aux requêtes pour les certificats dans lequel le certificat émis est différent de la demande. Noter qu'une stratégie peut dicter qu'une CA ne publie pas ou ne distribue pas le certificat tant que l'entité qui a fait la demande n'a pas accepté le certificat créé (généralement par un message certConf).
10. Une grâce, un changement planifié d'une paire de clé de CA non-compromise doit être supporté (noter que si la clé CA est compromise, la ré-initialisation doit être effectuée pour toutes les entités dans le domaine de la CA). Une entité finale dont le PSE contient la nouvelle clé publique CA doit également être capable de vérifier les certificats vérifiables en utilisant l'ancienne clé publique. Les entités finales qui trust directement l'ancienne paire de clé CA doivent également être capable de vérifier les certificat signés en utilisant la nouvelle clé privée de la CA.
11. Les fonctions d'un RA peut, dans certaines implémentations ou environnements, être géré par la CA elle-même. Les protocoles doivent être conçus pour que les entités finales utilisent le même protocole sans regarder si la communication est avec une CA ou une RA. Naturellement, l'entité finale doit utiliser la bonne clé public RA ou CA pour protéger la communication.
12. Pour une EE demandant un certificat contenant un valeur de clé publique donnée, celle-ci doit être prête à démontrer la possession de la clé privée correspondant.

Opérations de gestion de PKI

Le diagramme suivant affiche la relation entre les entités définies plus haut en terme d'opération de gestion de PKI. Les lettres dans le diagramme indiquent les protocoles dans le sens qu'un jeu définis de message de gestion de PKI peut être envoyé.
+---+_____cert._publish________+------------+______j
_____|___|__‹---------------------__|_End_Entity_|_‹-------
_____|_C_|_____________g____________+------------+______"out-of-band"
_____|_e_|____________________________|_^________________loading
_____|_r_|____________________________|_|______initial
_____|_t_|__________________________a_|_|_b_____registration/
_____|___|____________________________|_|_______certification
_____|_/_|____________________________|_|______key_pair_recovery
_____|___|____________________________|_|______key_pair_update
_____|_C_|____________________________|_|______certificate_update
_____|_R_|__PKI_"USERS"_______________V_|______revocation_request
_____|_L_|_-------------------+-+-----+-+------+-+-------------------
_____|___|__PKI_MANAGEMENT____|_^______________|_^
_____|___|____ENTITIES______a_|_|_b__________a_|_|_b
_____|_R_|____________________V_|______________|_|
_____|_e_|_____________g___+------+____d_______|_|
_____|_p_|___‹------------_|_RA___|_‹-----+____|_|
_____|_o_|______cert.______|______|_----+_|____|_|
_____|_s_|_______publish___+------+___c_|_|____|_|
_____|_i_|______________________________|_|____|_|
_____|_t_|______________________________V_|____V_|
_____|_o_|__________g_________________+------------+___i
_____|_r_|___‹------------------------|_____CA_____|-------›
_____|_y_|__________h_________________+------------+__"out-of-band"
_____|___|______cert._publish______________|_^_________publication
_____|___|______CRL_publish________________|_|
_____+---+_________________________________|_|____cross-certification
_________________________________________e_|_|_f__cross-certificate
___________________________________________|_|_______update
___________________________________________|_|
___________________________________________V_|
_________________________________________+------+
_________________________________________|_CA-2_|
_________________________________________+------+

1. Établissement de CA: en établissant une nouvelle CA, certaines étapes sont requises ( par ex. la production de crl initiales, l'export de la clé publique de la CA).
2. Initialisation de l'entité finale: inclus l'import d'une clé publique CA racine et la demande d'information sur les options supportées par une entité de gestion de PKI.
3. Certification: Diverses opérations résultent de la création de nouveaux certificats:

        1. Enregistrement/certification initiale: C'est le processus par lequel une entité finale se fait connaître auprès d'une CA ou RA, avant que la CA ne fournisse un certificat pour l'entité finale. Le résultat final de ce processus ( Quand il est réussit ) est qu'une CA fournis un certificat pour une clé publique d'une entité finale, et retourne ce certificat à l'entité finale et/ou poste ce certificat dans un répertoire publique. Ce processus peut, et est typiquement, être fait de plusieurs étapes, incluant une initialisation de l'équipement de l'entité finale. Par exemple, l'équipement de l'entité finale doit être initialisé de manière sécurisé avec la clé publique d'une CA, pour être utilisé dans la validation de chemins de certification.
        2. Mise à jour des paires de clé: Toute paire de clé doit être mis à jours régulièrement ( par ex: remplacé par une nouvelle paire de clé), et un nouveau certificat doit être fournis.
        3. Mise à jour de certificat: Vu que les certificats expirent, ils doivent être rafraîchis si rien n'a été changé dans l'environnement.
        4. Mise à jours de paire de clé de CA: Comme pour les entités finales, les paires de clé CA doivent être mis à jours régulièrement; cependant, différents mécanismes sont requis.
        5. Demande de cross-certification: Une CA demande de fournir un cross-certificat pour une autre CA. Pour ce standard, les termes suivants sont définis. Un cross-certificat est un certificat dans lequel le sujet de la CA et le fournisseur de la CA sont distincts et subjectPublicKeyInfo contient une clé de vérification (par ex: le certificat a été fournis pour la signature de la paire de clé du sujet de la CA.). Quand il est nécessaire de distinguer plus finement, les termes suivants peuvent être utilisé: un cross-certificat est appelé un certification inter-domaine si le sujet et le fournisseur appartiennent à des domaines administratifs différents.

                1. Note 1. La définition ci-dessus de cross-certificat s'aligne avec le term définis CA-certificate dans X.509. Noter que ce terme ne doit pas être confondu avec le type d'attribut cACertificate X.500, qui n'est pas lié.
                2. Note 2. Dans de nombreux environnements, le terme cross-certificate, sera compris comme synonyme de cross-certificate inter-domaine.
                3. Note 3. L'émission de cross certificat peut être, mais pas nécessairement, mutuel; c'est à dir, 2 CA peuvent fournir des cross certificats entre eux.

        6. Mise à jours de cross-certificats: Similairement à une mise à jours de certificat.

4. Opérations de découverte de certificat/CRL: Certaines opérations de gestion de PKI résultent dans la publication de certificats ou de CRL:

        1. Publication de certificat: Après avoir produit un certificat, un moyen de publication est nécessaire. Ce moyen définis dans PKIX peut impliquer les messages spécifiés plus bas, ou d'autres moyen (ldap par exemple).
        2. Publication de CRL: Comme pour une publication de certificat.

5. Opérations de récupération: Certaines opérations de gestion de PKI sont utilisée quand une entité finale a perdu son PSE:

        1. Récupération de paire de clé: Comme option, Les clé clients utilisateurs ( par exemple la clé privée de l'utilisateur utilisé pour le déchiffrement) peut être sauvegardé par une CA, une RA, ou un système de sauvegarde de clé associé avec une CA ou une RA. Si une entité a besoin de récupérer sa clé, un protocole d'échange peut être nécessaire pour supporter une telle récupération.

6. Opérations de révocation: Certaines opérations de PKI résultent en la création d'une nouvelle entrée de CRL et/ou une nouvelle CRL.

        1. Demande de révocation: Une personne autorisée avertis une CA d'une situation anormale nécessitant la révocation de certificat

7. Opérations PSE: Bien que la définition des opérations PSE soient en dehors du périmètre de ce document, on doit définir une PKIMessage ( CertRepMessage ) qui peut former la base de telles opérations.

   Noter que les protocoles on-line ne sont par la seule manière d'implémenter les opérations ci-dessus. Pour toutes les opérations, il y à des méthodes offline qui accomplissent le même résultat, et cette spécification ne mandate pas l'utilisation de protocoles on-line. Par exemple, quand des tokens hardware sont utilisé, de nombreuses opération peuvent être accomplies comme partie de la livraison de jetons physique.

Hypothèses et restrictions

Initialisation de l'entité finale

   La première étape pour une entité finale en dialoguant avec les entités de gestion de PKI est de demander les informations sur les fonctions de la PKI supportés et pour acquérir de manière sécurisé une copie des clé publiques de CA root.

Enregistrement/certification Initiale

   Il y a de nombreux schéma qui peuvent être utilisé pour accomplir un enregistrement et une certification des entités finales. Aucune méthode n'est adaptée pour toutes les situations à cause de la plage de stratégie qu'une CA peut implémenter et la variation dans les types d'entité finales qui peuvent se produire.

   Cependant, on peut classer les schémas d'enregistrement/certification qui sont supportés par cette spécification. Noter que le terme d'initial est crucial: on gère les situations où l'entité finale en question n'a jamais eu de contact avec la PKI. Quand l'entité finale possède déjà des clés certifiés, certaines simplification/alternatives sont possibles.

   En ayant classé les schémas qui sont supportés par cette spécification on peut ainsi spécifier certains comme obligatoire et d'autres comme optionnels. Le but est que les schéma obligatoires couvrent suffisamment de cas qui se produisent en utilisation réelle, alors que les schémas optionnels se produisent moins fréquemment. De cette manière, on accomplis une balance entre la flexibilité et la simplicité d'implémentation.

Critères utilisés

Initialisation de l'enregistrement/certification

   En terme de messages PKI qui sont produits, on peut regarder l'initialisation des échange d'enregistrement/certification initials comme se produisant chaque fois que le premier message de PKI lié à l'entité finale est produite. Noter que l'initialisation dans le monde réel de cette procédure peut se produire n'importe où.

Authentification du message originel de l'entité finale

   Les messages on-line produits par l'entité finale qui nécessitent un certificat peuvent être authentifiés ou non. Les prérequis ici sont pour authentifier l'origine de tous messages de l'entité finale vers la PKI (CA/RA).

   Dans cette spécification, une telle authentification est accomplie par la PKI ( CA/RA ) qui fournis à l'entité finale une valeur secrète ( clé d'authentification initiale ) et une valeur de référence ( utilisée pour identifier la valeur secrète ) via d'autres moyens. La clé d'authentification initiale peut ainsi être utilisée pour protéger les messages PKI important.

   Donc, on peut classer le schéma d'enregistrement/certification initial en fonction de si l'entité finale est on-line ou non -› les messages PKI sont authentifiés on non.

   Note 1: on ne discute pas des messages d'authentification de la PKI -› entité finale ici, vu que c'est toujours requis. Dans tous les cas, il peut être simplement une fois que la clé publique de la CA root a été installée dans l'équipement de l'entité finale ou peut être basée sur la clé d'authentification initiale.

   Note 2: Une procédure d'enregistrement/certification initiale peut être sécurisé via d'autres moyens alternatifs.

Emplacement de la génération de clé

   Dans cette spécification, la génération de clé est vu comme se produisant quand la clé publique ou privée se produit dans un PKIMessage. Noter que cela ne pré-inclus pas un service de génération de clé centralisée; la paire de clé actuelle peut avoir été générée n'importe où et envoyé à l'entité finale, RA, ou CA en utilisant un protocole de requête/réponse de génération de clé. Il y a donc 3 possibilités pour l'emplacement de la génération de clé: l'entité finale, une RA ou une CA.

Confirmation du succès de la certification

   Après la création d'un certificat initial pour une entité finale, Une assurance supplémentaire peut être obtenu en retournant une confirmation du succès de l'opération à l'entité finale, contenant le certificat. Cela donne 2 possibilités: confirmé ou non.

Schéma mandatoire

   Le critère ci-dessus permet un grand nombre de schéma d'enregistrement/certification initial. Cette spécification mandate qu'un équipement CA, RA, EE conformes doit supporter le schéma "Schéma authentifié de base", et peut supporter d'autres schémas additionnels.

Schéma centralisé

   En terme de classification, ce schéma est, d'une certaine manière, le plus simple possible, où:

- L'initialisation se produit sur la CA certifiante
- Aucune authentification on-line n'est requis
- La génération de clé se produit sur la CA authentifiante
- Aucun message de confirmation n'est requis

   En terme de flux de message, ce schéma signifie que le seul message requis est envoyé de la CA à l'entité finale. Le message doit contenir tout le PSE pour l'entité finale. Certains moyens externes doivent être fournis pour permettre à l'entité final d'authentifier le message reçu et pour décrypter et décrypter les valeurs.

Schéma authentifié de base

   En terme de classification, ce schéma est où:

- Une initialisation se produit au niveau de l'entité finale
- un message d'authentification est requis
- La génération de clé se produit sur l'entité finale
- Un message de confirmation est requis

   En terme de flux de message, ce schéma est comme suit: La génération de la clé, la création de la demande de certification et la protection de la clé d'authentification initiale (IAK) se produisent sur l'entité finale. L'autorité vérifie la requête, la traite et créé la réponse. L'entité final manipule cette réponse et créé la confirmation. L'autorité vérifie la confirmation et créé une réponse.

Preuve de possession de la clé privée

   Pour empêcher certaines attaques et pour permettre à une CA/RA de vérifier proprement la validité du lien entre une entité finale et une paire de clé, les opérations de gestion de PKI spécifiés ici permettent à une entité finale de prouver qu'il possède la clé privée correspondant à la clé publique pour laquelle un certificat est demandée. Une CA/RA est libre de choisir comment forcer le POP dans ses échanges de certification. Cependant, il est nécessaire qu'un CA/RA force le POP par n'importe quel moyen parce qu'il y a de nombreux protocoles opérationnels non-PKIX utilisés qui ne vérifient pas la liaison entre l'entité finale et la clé privée.

   POP est accomplis de différente manières en fonction du type de clé pour laquelle un certificat est demandé. Si une clé peut être utilisée différents but, une méthode appropriée peut être utilisée. Par exemple, une clé qui peut être utilisée pour signer, aussi bien que d'autres but, ne devraient pas être envoyés à la CA/RA pour prouver la possession).

   Cette spécification permet explicitement les cas où une entité finale fournis la preuve significative à une RA et que cette RA atteste à la CA que la preuve requise a été reçue et validée. Par exemple, une entité finale souhaite avoir une clé de signature certifiée, pourrait envoyer la signature appropriée à la RA, qui peut simplement notifier à la CA que l'entité finale a fournis la preuve requise. Bien sûr, une telle situation peut être interdite par stratégie ( ex: les CA peuvent être les seules entités permises à vérifier le POP durant la certification).

Clés de signature

   Pour les clés de signature, l'entité finale peut signer une valeur pour prouver la possession de la clé privée.

Clés de chiffrement

   Pour les clés de chiffrement, l'entité finale peut fournir la clé privée à la CA/RA, ou peut être requise pour déchiffrer une valeur pour prouver sa possession de la clé privée. En déchiffrant une valeur qui peut être accomplie soit directement, soit indirectement.

   La méthode directe sert à une RA/CA pour fournir un challenge aléatoire pour lequel une réponse immédiate par l'EE est requise.

   La méthode indirect sert à fournir un certificat qui est chiffré afin que l'EE puisse démontrer sa capacité à déchiffrer le message.

   Cette spécification encourage l'utilisation de la méthode indirecte parce qu'elle ne nécessite pas de messages supplémentaires à envoyer.

Clés d'agrément de clé

   Pour les clés d'agrément de clé, l'entité finale et l'entité de gestion de PKI doit établir un clé secrète partagée pour pouvoir prouver que l'entité finale possède la clé privée.

   Noter que cela nécessite de n'imposer aucune restriction sur les clés qui peuvent être certifiés par une CA donnée. En particulier, pour les clés Diffie-Hellman, l'entité finale peut librement choisir ses paramètres à condition que la CA puisse générer une paire de clé avec les paramètres appropriés si nécessaire.

Mise à jour de clé de la CA root

   Cette discussion s'applique uniquement aux CA qui sont directement trustés par certaines entités finales. Les CA auto-signés devraient être considérés comme des CA directement trustés. Reconnaître si une CA non auto-signé est supposé être directement trusté par certaines entités finales est une question de stratégie de CA et est hors du scope de ce document.

   La base de la procédure décrite ici est que la CA protège sa nouvelle clé publique en utilisant sa précédente clé privée et vice-versa. Donc, quand une CA met à jour sa paire de clé elle doit générer 2 valeurs d'attribut cACertificate supplémentaires si les certificats sont disponibles en utilisant un annuaire X.500 (pour un total de 4: OldWithOld, OldWithNew, NewWithOld, et NewWithNew).

   Quand une CA change sa paire de clé, ces entités qui ont acquis l'ancienne clé publique de la CA via des moyens tiers sont les plus affectés. Ce sont ces entités finales qui auront besoin d'accéder à la nouvelle clé publique CA protégée avec l'ancienne clé privée CA. Cependant, ils vont seulement avoir besoin de cela pour une période limitée (jusqu'à ce qu'ils aient acquis la nouvelle clé publique). Ce sera facile à accomplir quand les certificats des entités finales expirent.

   La structure de données utilisé pour protéger la nouvelle et l'ancienne clé publique CA est un certificat standard ( qui peut également contenir des extensions). Il n'y a pas de nouvelle structures de données requises.

   Note 1. Ce schéma n'utilise aucune extension X.509 v3 vu qu'il doit être capable fonctionner avec les certificats version 1. La présente de l'extension KeyIdentifier serait cependant plus efficace.

   Note 2. Bien que le schéma pourrait être généralisé pour couvrir des cas où les CA mettent à jours leur paire de clé plus d'une fois durant la période de validité du certificat d'une de ses entités finales, cette généralisation semble d'une valeur douteuse. Ne pas avoir cette généralisation signifie simplement que la période de validité des certificats émis avec l'ancienne paire de clé CA ne peut pas excéder la fin de la période de validité OldWithNew.

   Note 3. Ce schéma s'assure que les entités finales vont acquérir la nouvelle clé publique CA, à la dernière par expiration du dernier certificat qu'ils possèdent qui a été signé avec l'ancienne clé privée de la CA. Les opération de certificat et/ou de mise à jours de clé se produisant à d'autre moments ne nécessitent pas nécessairement cela.

Actions de l'opérateur CA

   Pour changer la clé de la CA, l'opérateur CA effectue:

1. Générer une nouvelle paire de clés
2. Créer un certificat contenant l'ancienne clé publique signée avec la nouvelle clé privée
3. Créer un certificat contenant la nouvelle clé publique signée avec l'ancienne clé privée
4. Créer un certificat contenant la nouvele clé publique CA signée avec la nouvelle clé privée
5. Publier ces nouveaux certificats via le dépôt et/ou d'autres moyens
6. Exporter la nouvelle clé publique CA pour que les entités finales puissent l'acquérir en utilisant un mécanisme externe (si nécessaire).

   L'ancienne clé privée CA n'est ainsi plus requise. Cependant, l'ancienne clé publique CA va continuer à être utilisée pour un certain temps. L'ancienne clé publique CA n'est plus requise ( autre que pour la non-répudiation ) quand toutes les entités finale de cette CA on acquis la nouvelle clé publique CA.

   Le certificat "old with new" doit avoir une période de validité commençant à la date de génération de l'ancienne paire de clé et se terminant à la date d'expiration de l'ancienne lé publique.

   Le certificat "new with old" doit avoir une période de validité commençant à la date de génération de la nouvelle paire de clé et se terminant à la date à laquelle toutes les entités finales de cette CA vont posséder la nouvelle clé publique.

   Le certificat 'new with new' doit avoir une période de validité commençant à la date de génération de la nouvelle paire de clé et se terminant à ou avant la date à laquelle la CA va mettre de nouveau à jour sa paire de clé.

Vérifier les certificats

   En vérifiant une signature, le vérificateur vérifie le certificat contenant la clé publique du signataire. Cependant, une fois qu'une CA est autorisée à mettre à jours ses clés il y a de nouvelles possibilités:

- Pour les cas impaires, le signataire des certificats est protégé avec la nouvelle clé publique, dans les cas paires, ce certificat est protégé avec l'ancienne clé publique.
- 2 types de dépôts: le dépôt contient la nouvelle et l'ancienne clé publique ou le dépôt ne contient que l'ancienne clé ( dû à un délay )
- 2 cas de possession de la clé: le PSE contient la nouvelle clé, ou le PSE contient l'ancienne clé.

Cas 1: le dépôt et le PSE contiennent la nouvelle clé: c'est le cas standard où le vérificateur peut directement vérifier le certificat sans utiliser le dépôt.
Cas 2: le dépôt et le PSE contiennent la nouvelle clé: Le vérificateur doit accéder au dépôt pour obtenir la valeur de l'ancienne clé publique
Cas 3: le dépôt a la nouvelle clé, mais pas le PSE. Dans ce cas, le vérifier doit accéder au dépôt pour obtenir la valeur de la nouvelle clé publique.
Cas 4: le dépôt a la nouvelle clé, mais pas le PSE. Le vérificateur peut directement vérifier le certificat sans utiliser le dépôt
Cas 5: Le PSE a la nouvelle clé, mais pas le dépôt. Bien que l'opération CA n'a pas mis à jours le dépôt, le certificat peut être directement validé (identique au cas 1)
Cas 6: Le PSE a la nouvelle clé, mais pas le dépôt. Le vérificateur pense qu'il s'agit d'un situation cas 2 et va accéder au dépôt, cependant, la vérification va échouer.
Cas 7: le dépôt et le PSE contiennent l'ancienne clé: Dans ce cas l'opérateur CA n'a pas mis à jours le dépôt et la vérification va échouer
Cas 8: le dépôt et le PSE contiennent l'ancienne clé: Bien que l'opérateur CA n'a pas mis à jours le dépôt, le vérificateur peut vérifier le certificat directement, (identique au cas 4)

Vérification dans les cas 1,4,5,8

   Dans ces cas, le vérificateur n'a pas de copie locale de la clé publique qui peut être utilisée pour vérifier le certificat directement. C'est la même situation où aucune clé n'a été changée. Noter que le cas 8 peut se produire entre le moment où l'opérateur CA a généré la nouvelle paire de clé et le moment où l'opérateur CA stock les attributs mis à jours dans le dépôt. Le cas 5 peut seulement se produire si l'opérateur CA a émis les certificats du signataire et du vérificateur durant cet écart ( L'opérateur CA devrait éviter cela).

Vérification dans le cas 2

   Dans le cas 2, le vérificateur doit avoir accès à l'ancienne clé publique de la CA. Le vérificateur fait ceci:

1. Recherche l'attribut caCertificate dans le dépôt et prend le certificat OldWithNew (déterminé sur la période de validité; noter que les champs subject et issuer doivent correspondre).
2. Vérifie que c'est correcte en utilisant la nouvelle clé CA ( que le vérificateur a localement ).
3. Si correct, vérifie le certificat du signataire en utilisant l'ancienne clé CA.

   Le cas 2 se produit quand l'opérateur CA a émis le certificat du signataire, puis changé la clé, puis émis le certificat du vérificateur; donc c'est un bon cas typique.

Vérification dans le cas 3

   Dans le cas 3, le vérificateur doit avoir accès à la nouvelle clé publique de la CA. Le vérificateur fait ceci:

1. Recherche l'attribut CACertificate dans le dépôt et prend le certificat NewWithOld (déterminé sur la période de validité; le subject et issuer doivent matcher.
2. Vérifie que c'est correct en utilisant l'ancienne clé
3. Si correct, vérifie le certificat du signataire en utilisant la nouvelle clé CA.

   Le cas 3 se produit quand l'opérateur CA a émis le certificat du signataire, puis changé la clé, et ainsi émis le certificat du signataire; donc c'est également un cas typique.

Érreur de vérification dans le cas 6

   Dans ce cas, la CA a émis le PSE du vérificateur, qui contient la nouvelle clé, sans mettre à jours les attributs du dépôt. Cela signifie que le vérificateur n'a aucun moyen d'obtenir une version trustée de l'ancienne clé de la CA et donc la vérification échoue. Cette erreur est une faute de l'opérateur CA.

Érreur de vérification dans le cas 7

   Dans ce cas, la CA a émis le certificat du signataire protégé avec la nouvelle clé sans mettre à jours les attributs du dépôt. Cela signifie que le vérificateur n'a aucun moyen d'obtenir une version trustée de l'ancienne clé de la CA et donc la vérification échoue. Cette erreur est une faute de l'opérateur CA.

Révocation - Changement de la clé CA

   Comme vu plus haut, la vérification d'un certificat devient de plus en plus complexe une fois que la CA est autorisée à changer sa clé. C'est également vrai pour les vérifications de révocation vu que la CA peut avoir signé la CRL en utilisant une clé privée plus récente que celle dans le PSE de l'utilisateur.

   L'analyse des alternatives est la même que pour la vérification du certificat.

Structures de données

   Cette section contient des descriptions des structures de données requise pour les messages de gestion de PKI. La section suivante décris les contraintes sur leur valeurs et la séquence des évènements pour chaque opération de gestion de PKI.

Message PKI

Tous les messages utilisés dans cette spécification pour les buts de gestion de PKI utilisent la structure suivante:
PKIMessage ::= SEQUENCE {
    header PKIHeader,
    body PKIBody,
    protection [0] PKIProtection OPTIONAL,
    extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

PKIHeader contient les informations qui sont communes aux messages PKI
PKIBody contient des informations spécifiques au message
PKIProtection si utilisé, contient les bits qui protègent le message de PKI.
extraCerts peut contenir des certificats qui peuvent être utiles. Par exemple, cela peut être utilisé par une CA ou RA pour présente une entité finale avec les certificats qui sont nécessaires pour vérifier son propre nouveau certificat. (Si, par exemple, la CA qui a émis le certificat EE n'est pas une CA root pour l'EE). Noter que ce champ ne contient pas nécessairement un chemin de certification; le destinataire peut avoir à trier, sélectionner, ou traiter les certificats supplémentaires pour pouvoir les utiliser.

En-tête de message de PKI

   Tous les messages de PKI nécessitent certaines informations d'en-tête pour l'adressage et l'identification de la transaction. Certaines de ces informations vont également être présentes dans une enveloppe spécifique au transport. Cependant, si le message PKI est protégé, alors cette information est également protégée.

La structure de données suivante est utilisée pour contenir cette information:
PKIHeader ::= SEQUENCE {
    pvno INTEGER { cmp1999(1), cmp2000(2) },
    sender GeneralName,
    recipient GeneralName,
    messageTime [0] GeneralizedTime OPTIONAL,
    protectionAlg [1] AlgorithmIdentifier OPTIONAL,
    senderKID [2] KeyIdentifier OPTIONAL,
    recipKID [3] KeyIdentifier OPTIONAL,
    transactionID [4] OCTET STRING OPTIONAL,
    senderNonce [5] OCTET STRING OPTIONAL,
    recipNonce [6] OCTET STRING OPTIONAL,
    freeText [7] PKIFreeText OPTIONAL,
    generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String

pvno est fixé à 2 pour cette version de ce document
sender contient le nom de l'émetteur du PKIMessage. Ce nom ( en conjonction avec senderKID, si fournis) devrait être suffisant pour indiquer la clé à utiliser pour vérifier la protection dans le message. Si rien sur l'émetteur n'est connus sur l'entité (ex: dans l'initialisation, un message req, où l'entité finale peut ne pas connaître son propre DN, e-mail, IP, etc), alors ce champ doit contenir une valeur NULL; c'est à dire une séquence de rdn de longueur 0. Dans un tel cas, le champ senderKID doit contenir un identifiant (par ex: un numéro de référence) qui indique au destinataire les information de clé secrète partagée appropriée pour vérifier le message.
recipient Contient le nom du destinataire du PKIMessage. Ce nom ( en conjonction avec recipKID, si fournis ) devrait être utilisable pour vérifier la protection du message.
protectionAlg Spécifie l'algorithme utilisé pour protéger le message. Si aucun bits de protection n'est fournis ( PKIProtection est optionnel ), ce champ doit être omis; si les bits de protection sont fournis, ce champ doit être fournis.
senderKID, recipKID Sont utilisables pour indiquer quelles clés ont été utilisées pour protéger le message. (RecipKID va normalement être requis seulement quand le message est protégé avec des clés DH ). Ces champs doivent être utilisés si nécessaire pour identifier de manière unique une clé et devraient être omis sinon.
transactionID est utilisé pour permettre au destinataire du message de le corréler avec une transaction sortante. C'est nécessaire pour toutes les transactions qui consistent d'une simple paire demande/réponse. Pour ces transactions demande/réponse, les règles sont comme suit. Un client peut populer le champ transactionID de la requête. Si un serveur reçois une telle requête qui a le champ transactionID mis, alors il doit mettre le champ transactionID de la réponse à la même valeur. Si un serveur reçois une telle requête avec un champ transactionID manquant, alors il peut mettre le champ transactionID de la réponse.

   Pour les transaction qui consistent de plus qu'une simple paire demande/réponse, les règles sont comme suit. Les client devraient générer une transactionID pour la première demande. Si un serveur reçoit une telle demande avec le champs transactionID mis, alors il doit mettre le champ transactionID de la réponse à la même valeur. Si un serveur reçois une telle demande sans le champs transactionID, il doit populer ce champs dans la réponse avec un ID généré par le serveur. Les requêtes et réponses suivantes doivent toutes mettre le champs transactionID avec la valeur établie. Dans tous les cas où un transactionID est utilisé, un client ne doit pas avoir plus d'une transaction avec le même transactionID en cours vers un serveur donné. Les serveur sont libre d'imposer ou non l'unicité du transactionID, tant qu'ils sont capable d'associer correctement les messages avec la transaction correspondante.

   Typiquement, cela signifie qu'un serveur va nécessiter que le couple client/transactionID soit unique, ou même le transactionID seul, s'il ne peut pas distinguer les clients basé sur les information au niveau du transport. Un serveur recevant le premier message d'un transaction ( qui nécessite plus d'une paire demande/réponse ) qui contient un transactionID qui ne permet pas de répondre aux contraintes ci-dessus ( généralement parce que le transactionID est déjà utilisé ) doit envoyer un ErrorMsgContent avec un PKIFailureInfo de transactionIdInUse. Il est recommandé que les client utilisent un transactionID avec une donnée pseudo-aléatoire 128-bits pour commencer la transaction pour réduire la probabilité d'avoir un transactionID utilisé par le serveur.

senderNonce, recipNonce protègent le PKIMessage avec les attaques replay. senderNonce est généralement une donnée pseudo-aléatoire 128-bits générée par l'émetteur, et recipNonce est copié de senderNonce du précédent message dans la transaction.
messageTime Contient l'horodatage du moment où l'émetteur a créé le message. Peut être utile pour permettre aux entités finales de corriger/vérifier l'heure local.
freeText Peut être utilisé pour envoyer des données additionnelles au destinataire. Le premier langage utilisé dans cette séquence indique la langue désirée pour les réponses.
generalInfo Peut être utilisé pour envoyer des données additionnelles traitable par la machine au destinataire. Les extentions generalInfo suivantes sont définies et peuvent être supportées:

ImplicitConfirm

C'est utilisé par l'EE pour informer la CA qu'elle ne souhaite pas envoyer une confirmation de certificat pour les certificats émis.
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL

   Si la CA autorise la demande, elle doit placer la même extension dans le PKIHeader de la réponse. Si l'EE ne trouve pas l'extension dans la réponse, elle doit envoyer la confirmation du certificat.

ConfirmWaitTime

C'est utilisé par la CA pour informer l'EE du temps d'attente prévu pour la confirmation de certificat avant de révoque le certificat et supprimer la transaction.
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime

Corps du message PKI


PKIBody ::= CHOICE {
    ir [0] CertReqMessages, --Initialization Req
    ip [1] CertRepMessage, --Initialization Resp
    cr [2] CertReqMessages, --Certification Req
    cp [3] CertRepMessage, --Certification Resp
    p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
    popdecc [5] POPODecKeyChallContent --pop Challenge
    popdecr [6] POPODecKeyRespContent, --pop Response
    kur [7] CertReqMessages, --Key Update Request
    kup [8] CertRepMessage, --Key Update Response
    krr [9] CertReqMessages, --Key Recovery Req
    krp [10] KeyRecRepContent, --Key Recovery Resp
    rr [11] RevReqContent, --Revocation Request
    rp [12] RevRepContent, --Revocation Response
    ccr [13] CertReqMessages, --Cross-Cert. Request
    ccp [14] CertRepMessage, --Cross-Cert. Resp
    ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
    cann [16] CertAnnContent, --Certificate Ann.
    rann [17] RevAnnContent, --Revocation Ann.
    crlann [18] CRLAnnContent, --CRL Announcement
    pkiconf [19] PKIConfirmContent, --Confirmation
    nested [20] NestedMessageContent, --Nested Message
    genm [21] GenMsgContent, --General Message
    genp [22] GenRepContent, --General Response
    error [23] ErrorMsgContent, --Error Message
    certConf [24] CertConfirmContent, --Certificate confirm
    pollReq [25] PollReqContent, --Polling request
    pollRep [26] PollRepContent --Polling response
}

   Les types spécifiques sont décris plus bas.

Protection de message PKI

   Certains message PKI vont être protéger pour l'intégrité. ( Noter que si un algorithme asymétrique est utilisé pour protéger un message et que le composant publique a déjà été certifié, l'origine du message peut également être authentifié ).

Quand la protection est appliquée, la structure suivante est utilisée:
PKIProtection ::= BIT STRING

L'entrée pour le calcul de PKIProtection est un encodé DER de la structure de données suivante:
ProtectedPart ::= SEQUENCE {
    header PKIHeader,
    body PKIBody
}

   Il peut y avoir des cas dans lesquels la chaîne de bit PKIProtection n'est délibérément pas utilisée pour protéger un message parce que d'autre protection externes sont appliqués à la place. Un tel choix est explicitement permit dans cette spécification. Des exemples de telles protections externes incluent les encapsulations PKCS#7 et Security Multiparts ( rfc1847 ) du PKIMessage ( ou simplement le PKIBody ), si les informations PKIHeader sont gérés de manière sécurisés dans le mécanisme externe. Il est noté, cependant, que de nombreux mécanismes externes nécessitent que l'entité finale possède déjà un certificat et/ou un DN unique, et/ou d'autres informations liées à l'infrastructure.

   Donc, ils peuvent être non appropriés pour un enregistrement initial, récupération de clé, ou tout autre processus avec des caractéristiques de 'boot-strapping'. Pour ces cas il peut être nécessaire que le paramètre PKIProtection soit utilisé. Dans le future, si et quand les mécanismes externes sont modifiés pour ces scénarios, l'utilisation de PKIProtection peut devenir rare ou non-existant.

   En fonction des circonstance, les bits PKIProtection peuvent contenir un MAC ou une signature. Seul les cas suivants peut se produire.

Information de secret partagé

Dans ce cas, l'émetteur et le destinataire partages une information secrète (établie via un moyen externe ou depuis une opération de gestion PKI précédente). PKIProtection va maintenir une valeur MAC et protectionAlg sera:
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
    salt OCTET STRING,
    owf AlgorithmIdentifier,
    iterationCount INTEGER,
    mac AlgorithmIdentifier
}

   Dans protectionAlg ci-dessus, la valeur salt est ajoutée à l'entrée du secret partagé. Le OWF est ainsi appliqué iterationCount fois, où le secret salé est l'entrée de la première itération et, pour chaque itération successive, l'entrée est la sortie de l'itération précédente. La sortie de l'itération finale ( appelée BASEKEY avec une taille H) est ce qui est utilisé pour former la clé symétrique. Si l'algorithme MAC nécessite une clé K-Bits et K ‹= H, alors les bits K les plus signifiant de BASEKEY sont utilisés. Si K › H, alors tout BASEKEY est utilisé pour les bits H les plus signifiant de la clé, OWF('1' || BASEKEY) est utilisé pour les bits H les plus signifiant suivants de la clé, OWF('2' || BASEKEY) est utilisé pour les bits H les plus signifiant suivants de la clé et ainsi de suite, jusqu'à ce que tous les bits K aient été dérivés.

   Note: il est recommandé que les champs de PBMParameter restent constants via les messages d'une simple transaction (ex: ir/ip/certConf/pkiConf) pour pouvoir réduire la charge associé avec le calcul de PasswordBasedMac.

Paires de clé DH

Où l'émetteur et le destinataire possèdent des certificats Diffie-Hellman avec des paramètres DH compatibles, pour pouvoir protéger le message l'entité finale doit générer une clé symétrique basée sur la clé privée DH et la clé publique DH du destinataire de message PKI. PKIProtection contient une valeur MAC protégé avec cette clé symétrique dérivée et protectionAlg sera:
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
    owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended)
    mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
}

   Dans le protectionAlg ci-dessus, OWF est appliqué au résultat du calcul DH. La sortie OWF (appelée BASEKEY, avec une taille H) est ce qui est utilisé pour former la clé symétrique. Si l'algorithme MAC nécessite une clé K-bit et K ‹= H, les bits K les plus signifiant de BASEKEY sont utilisé. Si K › H, tout BASEKEY est utilisé pour les bits H les plus signifiants suivants, OWF('1' || BASEKEY) est utilisé pour les bits H les plus signifiant suivant, OWF('2' || BASEKEY) est utilisé pour les bits H les plus signifiant suivant, et ainsi de suite, jusqu'à ce que les bits K aient été dérivés.

Signature

   Dans ce cas, l'émetteur possède une paire de clé de signature et signe simplement le message PKI. PKIProtection va contenir la valeur de signature et protectionAlg sera un AlgorithmIdentifier pour une signature numérique.

Protection Multiple

Dans les cas ou une entité finale envoie un message PKI protégé à une RA, la RA peut transférer ce message à une CA, attachant sa propre protection ( qui peut être un MAC ou une signature, en fonction des informations et des certificats partagés entre la RA et la CA ). C'est accomplis en imbriquant tout le message envoyé par l'entité finale dans un nouveau message PKI. La structure utilisée est:
NestedMessageContent ::= PKIMessages

   L'utilisation des PKIMessages, une sequence de PKIMessage, laisse la RA automatiser les requêtes de nombreux EE dans un simple nouveau message. Par simplicité, tous les messages dans le batch doivent être de même type (ex: ir). Si la RA souhaite modifier les messages d'une certaine manière (ex: ajouter des valeur de champ particulier ou de nouvelles extensions), elle peut créer sont propre PKIBody. Le PKIMessage originel de l'EE peut être inclus dans le champ generalInfo de PKIHeader. l'infoType utilisé dans cette situation est {id-it 15} et infoValue est PKIMessages (le contenu doit être dans le même ordre que les demandes dans PKIBody).

Structures de données communes

   Avant de spécifier les types spécifique qui peuvent être placés dans un PKIBody, on définis certaines structures qui sont utilisées dans plus d'un cas.

Contenu des certificats demandés

   Divers messages de gestion de PKI nécessitent que l'initiateur du message indique certains des champs qui doivent être présent dans un certificat. La structure CertTemplate permet à une entité finale ou une RA de spécifier ce qu'elle souhaite dans le certificat. CertTemplate est identique à une certificat, mais avec tous les champs optionnels.

   Noter que même si l'initiateur spécifie complètement le contenus d'un certificat, une CA est libre de modifier les champs dans le certificat qu'elle émet. Si le certificat modifié n'est pas acceptable pour le demandeur, le demandeur doit renvoyer un message certConf qui soit n'inclus pas ce certificat, ou inclus ce certificat ( via un CertHash ) avec un statut "rejected".

Valeurs chiffrées

   Quand des valeurs chiffrées ( restreintes, dans cette spécification, à des clés privées ou des certificats ) sont envoyés dans les messages PKI, la structure de données EncryptedValue est utilisée.

   L'utilisation de cette structure nécessite que le créateur et de destinataire soient capable de chiffrer et déchiffrer, respectivement. Typiquement, cela signifie que l'émetteur et de destinataire aient, ou soient capable de générer une clé secrète partagée.

   Si le destinataire du PKIMessage possède déjà une clé privée utilisable pour le déchiffrement, alors le champ encSymmKey peut contenir une clé de session chiffrée en utilisant la clé publique du destinataire.

Codes de status et information d'erreur pour les messages PKI

Tous les messages de réponse incluent une information de status. Les valeurs suivantes sont définies.
PKIStatus ::= INTEGER {
    accepted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4),
    revocationNotification (5),
    keyUpdateWarning (6)
}

Les répondeurs peuvent utiliser la syntaxe suivante pour fournir certaines informations sur les cas d'erreur
PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badMessageCheck (1),
    badRequest (2),
    badTime (3),
    badCertId (4),
    badDataFormat (5),
    wrongAuthority (6),
    incorrectData (7),
    missingTimeStamp (8),
    badPOP (9),
    certRevoked (10),
    certConfirmed (11),
    wrongIntegrity (12),
    badRecipientNonce (13),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17),
    badSenderNonce (18),
    badCertTemplate (19),
    signerNotTrusted (20),
    transactionIdInUse (21),
    unsupportedVersion (22),
    notAuthorized (23),
    systemUnavail (24),
    systemFailure (25),
    duplicateCertReq (26)
}
    
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL
}

Identification de certificat

   Pour pouvoir identifier des certificats particuliers, la structure de données CertId est utilisée.

Clé publique CA out-of-band

   Chaque CA root doit être capable de publier sa clé publique courante via des moyens externes. Bien que de tels mécanismes soient au-delà du scope de ce document, on définis des structures de données qui peuvent supporter de tels mécanismes.

Il y a généralement 2 méthodes disponibles: soit la CA publie directement son certificat auto-signé, ou cette information est disponible via l'annuaire ( ou équivalent ) et la CA publie un hash de cette valeur pour permettre la vérification de son intégrité avec utilisation.
OOBCert ::= Certificate

   Les champs dans ce certificat sont restreints comme suit:

- Le certificat doit être auto-signé (par ex: la signature doit être vérifiable en utilisant le champ subjectPublicKeyInfo.
- Les champs subject et issuer doivent être identiques
- Si le champ subject est NULL, alors les extensions subjectAltNames et issuerAltNames doivent être présents et avoir la même valeur
- Les valeur de toutes les autres extensions doivent être correct pour un certificat auto-signé.


OOBCertHash ::= SEQUENCE {
    hashAlg [0] AlgorithmIdentifier OPTIONAL,
    certId [1] CertId OPTIONAL,
    hashVal BIT STRING
}

   L'intension de la valeur de hash est que celui qui a reçu de manière sécurisée cette valeur peut vérifier un certificat auto-signé pour cette CA.

Options d'archive

   Les demandeurs peuvent indiquer qu'ils souhaitent que la PKI archive une valeur de clé privée en utilisant la structure PKIArchiveOptions.

Information de publication

   Les demandeurs peuvent indiquer qu'ils souhaitent que la PKI publient un certificat en utilisant la structure PKIPublicationInfo

Structures POP

Si la demande de certification concerne la signature d'une paire de clé, alors la preuve de possession de la clé privée est démontrée via l'utilisation de la structure POPOSigningKey.
POPOSigningKeyInput ::= SEQUENCE {
    authInfo CHOICE {
        sender [0] GeneralName,
        publicKeyMAC PKMACValue
    },
    publicKey SubjectPublicKeyInfo
}

   D'une autre manière, si la demande de certification est pour une paire de clé de chiffrement, alors la preuve de possession de la clé de privée peut être démontrée d'une des 3 manières suivante:

Méthode indirecte

   La CA ne retourne pas un certificat, mais un certificat chiffré ( le certificat chiffré avec une clé symétrique générée aléatoirement, et la clé symétrique est chiffrée avec la clé publique pour laquelle la demande de certificat est faite). L'entité finale prouve sa connaissance de la clé privée à la CA en fournissant le CertHash correct pour ce certificat dans le message certConf. Cela démontre le POP parce que l'EE peut seulement calculer le CertHash correct s'il est capable de récupérer le certificat, et il peut seulement récupérer le certificat s'il est capable déchiffrer la clé symétrique en utilisant sa propre clé privée. Pour que cela fonctionne, la CA ne doit pas publier le certificat tant que le message certConf n'est pas arrivé ( où certHash est utilisé pour démontrer POP).

Protocole Challenge-Response

   L'entité finale s'engage dans un protocole challenge-response ( en utilisant les messages POPODecKeyChall et POPODecKeyResp ) entre CertReqMessages et CertRepMessage -- c'est la méthode directe décrite plus haut. ( Cette méthode est généralement utilisée dans un environnement dans lequel une RA vérifie le POP et créé la demande de certification à la CA. Dans un tel scénario, la CA trust la RA pour avoir validé le POP correctement avant que la RA demande un certificat pour l'entité finale ). Le protocole complet ressemble comme suit:


EE____________RA____________CA
________----_req_----›
________‹---_chall_---
________----_resp_---›
______________________----_req'_---›
______________________‹---_rep_-----
______________________----_conf_---›
______________________‹---_ack_-----
________‹---_rep_-----
________----_conf_---›
________‹---_ack_-----

Ce protocole est plus long qu'un échange triple donné dans le choix 2 ci-dessus, mais permet à une RA d'être impliqué et a la propriété que le certificat n'est pas créé tant que le POS n'est pas complété. Dans certains environnements, un ordre différent peut être requis, tel que ceci ( peut être déterminé par stratégie):
EE____________RA____________CA
----_req_----›
‹---_chall_---
----_resp_---›
______________----_req'_---›
______________‹---_rep_-----
‹---_rep_-----
----_conf_---›
______________----_conf_---›
______________‹---_ack_-----
‹---_ack_-----

   Si la demande de certificat est pour une paire de clé d'agrément de clé (KAK), alors le POP peut être utilisé dans un échange triple décris plus haut pour encoder les paires de clé, avec les changement suivant: (1) le texte entre parenthèses 2) est remplacé avec "ex: le certificat chiffré avec la clé symétrique dérivé de la clé privée KAK de la CA et la clé publique pour laquelle la demande de certification est faite". (2) le premier texte entre parenthèses du champ challenge est remplacé avec "(PreferredSymmAlg et une clé symétrique dérivé de la clé privée KAK de la CA et la clé publique pour laquelle la demande de certificat est faite)". Alternativement, le POP peut utiliser la structure POPOSigningKey comme 4ème alternative pour démontrer le POP si la CA a déjà un certificat DH qui est connu de l'EE.

Les messages challenge-response pour POP d'une clé privée de chiffrement sont spécifié comme suit. Noter que cet échange est associé avec le message de demande de certification précédent by le transactionID utilisé dans le PKIHeader et par la protection appliquée au PKIMessage.
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
    owf AlgorithmIdentifier OPTIONAL,
    witness OCTET STRING,
    challenge OCTET STRING
}

Noter que la taille de Rand doit être approprié pour le chiffrement sous la clé publique de demandeur. Cet entier n'est généralement pas plus long que 64bits, laissant 100 octets pour le champ sender quand le modulo est 1024 bits. Si, dans certains environnements, les noms sont trop long, alors tout ce qui peut rentrer doit être utilisé ( tant que cela inclus au moins un nom commun, et tant que le destinataire est capable de comprendre l'abréviation).
POPODecKeyRespContent ::= SEQUENCE OF INTEGER

Sommaire des options POP

   Le texte dans cette section fournis de nombreuses options en respect des techniques POP. En utilisant SK pour Signing Key, EK pour Encryption Key, et KAK pour Key Agreement Key, les techniques peut être listés comme suit:

RAVerified
SKPOP
EKPOPThisMessage
KAKPOPThisMessage
KAKPOPThisMessageDHMAC
EKPOPEncryptedCert
KAKPOPEncryptedCert
EKPOPChallengeResp
KAKPOPChallengeResp

   En donnant ce tableau d'options, il est naturel de demander comment une entité finale peut connaître ce qui est supporté par la CA/RA. Les guides suivants devraient clarifier cette situation.

RAVerified Ce n'est pas une décision de l'EE; le RA l'utilise si et seulement si a vérifié le POP avant de transmettre la requête à la CA, donc il n'est pas possible pour l'EE de choisir cette technique.
SKPOP Si l'EE an une paire de clé de signature, c'est la seule méthode POP spécifiée pour l'utilisation dans la requête pour un certificat correspondant.
EKPOPThisMessage, KAKPOPThisMessage Donner on non sa clé privée à la CA/RA est une décision EE. Si l'EE décide de révéler sa clé, alors ce sont les seules méthodes POP disponible dans cette spécification pour l'accomplir.
KAKPOPThisMessageDHMAC L'EE peut seulement utiliser cette méthode si (1) la CA a un certificat DH disponible dans ce but, et (2) l'EE a déjà une copie de ce certificat. Si ces 2 conditions sont remplies, cette technique est clairement supportée et peut être utilisé par l'EE, si désiré.
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp L'EE choisis une des technique dans le message de demande, en fonction des préférences et du type de clés. L'EE ne fait pas de POP à ce moment là; il indique simplement quelle méthode il souhaite utilisé. Cependant, si la CA/RA répond avec une erreur badPOP, l'EE peut redemander en utilisant une autre méthode. Noter cependant que cette spécification encourage l'utilisation de EncryptedCert et, en outre, dit que le challenge-response devrait être utilisé quand une RA est impliquée et fait la vérification POP. Ainsi, l'EE devrait être capable de prendre une décision intelligente concernant la méthode POP à choisir dans la demande.

Initialisation de la demande

   Un message d'initialisation de demande contient comme PKIBody la structure CertReqMessages, qui spécifie les certificats demandés. Typiquement, SubjectPublicKeyInfo, KeyId, et Validity sont les champs qui doivent être fournis pour chaque demande de certificat. Ce message est prévu pour être utilisé par les entité qui s'initialise pour la première fois dans la PKI.

Initialisation de la réponse

   Un message d'initialisation de réponse contient comme PKIBody la structure CertRepMessage, qui a pour chaque attribut demandé un champ PKIStatusInfo, un sujet, et possiblement une clé privée (normalement chiffrée avec une clé de session, qui est elle-même chiffrée avec le protocolEncrKey). Noter que si la protection du message est de type secret partagé, tout certificat transporté dans le champ caPubs peut être directement validé comme certificat CA root par l'initiateur.

Demande de certification

   Un message de demande de certification contient comme PKIBody une structure CertReqMessages, qui spécifie les certificats demandés. Ce message est prévu pour être utilisé pour les entité PKI existantes qui souhaitent obtenir des certificats additionnels. Alternativement, PKIBody peut être un CertificationRequest. Cette structure peut être requise pour les demande de certificat pour les paires de clé de signature quand l'intéropérabilité avec les anciens systèmes est désirée, mais son utilisation est fortement découragée.

Réponse de certification

Un message de réponse de certification contient comme PKIBody une structure CertRepMessage, qui a la valeur de status pour chaque certificat demandé, et optionnellement une clé publique de CA, des informations d'erreur, un sujet, et une clé privée chiffrée.
CertRepMessage ::= SEQUENCE {
    caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
    response SEQUENCE OF CertResponse
}
    
CertResponse ::= SEQUENCE {
    certReqId INTEGER,
    status PKIStatusInfo,
    certifiedKeyPair CertifiedKeyPair OPTIONAL,
    rspInfo OCTET STRING OPTIONAL
         analogue à id-regInfo-utf8Pairs définis pour regInfo dans CertReqMsg
}
    
CertifiedKeyPair ::= SEQUENCE {
    certOrEncCert CertOrEncCert,
    privateKey [0] EncryptedValue OPTIONAL,
    publicationInfo [1] PKIPublicationInfo OPTIONAL
}
    
CertOrEncCert ::= CHOICE {
    certificate [0] Certificate,
    encryptedCert [1] EncryptedValue
}

   Seul un champ failInfo (dans PKIStatusInfo) et certificate (dans CertifiedKeyPair) peuvent être présents dans chaque CertResponse (en fonction du statut). Pour certaines valeurs de statut (ex: waiting), aucun des champs optionnels ne sont présents.

   En donnant un EncryptedCert et la clé de déchiffrement, le certificat peut êtr obtenu. Le but de cela est de permettre à une CA de retourner la valeur d'un certificat, mais avec la contrainte que seule le destinataire prévu peut obtenir le certificat. Le bénéfice de cette approche est qu'un CA peut répondre avec un certificat même en l'absence de preuve que le demandeur est l'entité finale qui peut utiliser la clé privée ( noter que la preuve n'est pas obtenue jusqu'à ce que le message certConf soit reçu par la CA). Donc, la CA n'aura pas à révoquer ce certificat dans le cas où quelque-chose ne va pas avec le POP.

Contenu des demandes de mise à jour de clé

   Pour les demandes de mise à jour de clé la syntaxe CertReqMessages est utilisée. Typiquement, SubjectPublicKeyInfo, KeyId, et Validity sont les champs fournis pour chaque clé à mettre à jours. Ce message est prévu pour être utilisé pour demanders des mises à jours de certificat existant non-révoqués et non-expirés. Une mise à jours est un remplacement de certificat contenant soit une nouvelle clé publique ou la clé publique courante.

Contenu des réponses de mise à jour de clé

   Pour les réponses de mise à jour de clé, la syntaxe CertRepMessage est utilisée. La réponse est identique à la réponse d'initialisation.

Contenu de demande de récupération de clé

   Pour les demandes de récupération de clé la syntaxe utilisée est identique à CertReqMessages des demandes d'initialisation. Typiquement, SubjectPublicKeyInfo et KeyId sont les champs qui peuvent être utilisé pour fournir une clé publique de signature pour laquelle un certificat est requis. Noter que si un historique de clé est requis, le demandeur doit fournir un contrôle de clé de chiffrement de protocole dans la demande.

Contenu de réponse de récupération de clé

Pour les réponses de récupération de clé, la syntaxe suivante est utilisée. Pour certaines valeurs de statut (ex: waiting), aucun champ optionnel 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
}

Contenu de demande de révocation

Pour une demande de révocation d'un ou plusieurs certificats, la structure de données suivante est utilisée. Le nom du demandeur est présent dans la structure PKIHeader
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
    certDetails CertTemplate,
    crlEntryDetails Extensions OPTIONAL
}

Contenu de réponse de révocation

La réponse de révocation est envoyée au demandeur de la révocation:
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
}

Contenu de demande de cross-certification

   Les demandes de cross-certification utilisent la même syntaxe (CertReqMessages) que pour les demandes de certification normales, avec comme restriction que la paire de clé doit avoir été générée par la CA demandeur et que la clé privée ne doit pas être envoyée. Cet requête peut également être utilisé par les CA subordonnées pour obtenir leur certificats signés par la CA parent.

Contenu de réponse de cross-certification

   Les réponse de cross-certification utilisent la même syntaxe (CertRepMessage) que pour les réponse de certification normales, avec comme restriction qu'aucune clé privée de chiffrement ne peut être envoyée.

Contenu d'annonce de mise à jour de clé CA

Quand une CA met à jours sa propre paire de clé, la structure de données suivante peut être utilisé pour annoncer cet évènement:
CAKeyUpdAnnContent ::= SEQUENCE {
    oldWithNew Certificate,
    newWithOld Certificate,
    newWithNew Certificate
}

Annonce de certificat

Cette structure peut être utilisé pour annoncer l'existence de certificat. Noter que ce message est prévu pour être utilisé pour les cas (s'il y'en a) où il n'y a pas de méthode pré-existante pour la publication de certificats; il n'est pas prévu pour être utilisé où, par exemple, X.500 est la méthode pour la publication de certificats
CertAnnContent ::= Certificate

Annonce de révocation

Quand une CA a été révoquée, ou est en train de révoquer un certificat particulier, elle peut émettre une annonce de cet évènement:
RevAnnContent ::= SEQUENCE {
    status PKIStatus,
    certId CertId,
    willBeRevokedAt GeneralizedTime,
    badSinceDate GeneralizedTime,
    crlDetails Extensions OPTIONAL
}

   Une CA peut utiliser une telle annonce pour alerter ou notifier un sujet que son certificat est révoqué. C'est généralement utilisé quand la demande de révocation en vient pas du sujet concerné. Le champ willBeRevokedAt contient la date à laquelle une nouvelle entrée sera ajoutée aux CRLs concernées.

Contenu de confirmation PKI

Cette structure est utilisée dans le protocole d'échange comme PKIMessage final. Son contenu est le même dans tous les cas -- actullement il n'y a aucun contenu vu que PKIHeader gère toutes les informations requises.
PKIConfirmContent ::= NULL

   L'utilisation de ce message pour la confirmation de certificat n'est pas recommandée. certConf devrait être utilisé à la place. Une fois reçu un PKIConfirm pour une réponse de certificat, le destinataire peut le traiter comme un certConf avec tous les certificats acceptés.

Contenu de confirmation de certificat

Cette structure est utilisée par le client pour envoyer une confirmation à la CA/RA pour accepter ou rejeter le certificat.
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
    certHash OCTET STRING,
    certReqId INTEGER,
    statusInfo PKIStatusInfo OPTIONAL
}

   Pour un CertStatus particulier, l'omission du champ statusInfo indique l'acceptation du certificat spécifié. Alternativement, des détails de statut explicite peuvent être fournis dans le champ statusInfo.

   Dans CertConfirmContent, l'omission d'une structure CertStatus correspond à un certificat fournis dans la réponse précédente indiquant le rejet du certificat. Donc, un CertConfirmContent vide peut être utilisé pour indiquer le rejet de tous les certificats émis.

Contenu du message général PKI


InfoTypeAndValue ::= SEQUENCE {
    infoType OBJECT IDENTIFIER,
    infoValue ANY DEFINED BY infoType OPTIONAL
} -- où {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue

Certificat de chiffrement de protocole CA

Peut être utilisé par l'EE pour obtenir un certificat depuis la CA à utiliser pour protéger les informations sensibles durant le protocole:
GenMsg: {id-it 1}, ‹ absent ›
GenRep: {id-it 1}, Certificate | ‹ absent ›
    
Les EE doivent s'assurer que le certificat correct est utilisé pour ce but.

Types de paire de clé de signature

Peut être utilisé par l'EE pour obtenir la liste des algorithmes de signature dont les valeur de clé publique peuvent être certifiés par la CA. Noter que dans le but de cet échange, rsaEncryption et rsaWithSHA1, par exemple, sont considérés équivalents.
GenMsg: {id-it 2}, ‹ absent ›
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

Types de paire de clé d'agrément de clé/chiffrement

Peut être utilisé par le client pour obtenir la liste des algorithmes d'agrément de clé/chiffrement dont les valeurs de clé publique peut être certifiés par la CA.
GenMsg: {id-it 3}, ‹ absent ›
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

Algorithme symétrique préféré

Peut être utilisé par le client pour obtenir l'algorithme de chiffrement préféré de la CA pour les informations confidentielles qui nécessitent d'échanger entre l'EE et la CA.
GenMsg: {id-it 4}, ‹ absent ›
GenRep: {id-it 4}, AlgorithmIdentifier

Paire de clé CA mise à jour

Peut être utilisé par la CA pour annoncer une mise à jour de clé de CA
GenMsg: {id-it 5}, CAKeyUpdAnnContent

CRL

Peut être utilisé par le client pour obtenir une copie de la dernière CRL.
GenMsg: {id-it 6}, ‹ absent ›
GenRep: {id-it 6}, CertificateList

Identifiant d'objet non supporté

C'est utilisé par le serveur pour retourner une liste d'identifiants d'objets qu'il ne reconnaît ou supporte.
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

Paramètres de paire de clé

Peut être utilisé par l'EE pour demander les paramètres de domaine à utiliser pour générer la paire de clé pour certains algorithmes à clé publique. Peut être utilisé, par exemple, pour demander P, Q et G appropriés pour générer la clé DH/DSA, ou pour demander un jeu de courbe elliptique.
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | ‹ absent ›

   Un infoValue absent dans GenRep indique que l'algorithme spécifié dans GenMsg n'est pas supporté. Les EE doivent s'assurer que les paramètres sont acceptable et que le message GenRep est authentifié.

passphrase de révocation

Peut être utilisé par l'EE pour envoyer un passphrase à une CA/RA pour authentifier un demande de révocation.
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, ‹ absent ›

Tags de langue supportés

Peut être utilisé pour déterminer le tag de langue approprié à utiliser dans les messages suivants. L'émeteur envoie sa liste de langages supportés ( par ordre de préférence ); le destinataire retourne celui qu'il souhaite utiliser. Si aucun des tags proposés ne sont supportés, une erreur doit être retournée.
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String

Contenu de réponse PKI Général


GenRepContent ::= SEQUENCE OF InfoTypeAndValue

Cette structure de données peut être utilisée par l'EE, CA ou RA pour transporter des informations d'erreur
ErrorMsgContent ::= SEQUENCE {
    pKIStatusInfo PKIStatusInfo,
    errorCode INTEGER OPTIONAL,
    errorDetails PKIFreeText OPTIONAL
}

   Ce message peut être généré à tout moment durant une transaction PKI. Si le client envoie cette requête, le serveur doit répondre avec une réponse PKIConfirm, ou un autre ErrorMsg si une partie de l'en-tête n'est pas valide. Chaque partie doit traiter ce message comme la fin de la transaction (si une transaction est en cours).

   Si la protection est souhaitée dans le message, le client doit le protéger en utilisant la même technique que le message de début de la transaction. La CA doit toujours le signer avec une clé de signature.

Demande et réponse d'interrogation

Cette paire de message est prévue pour manipuler les scénario dans lequel le client a besoin d'interroger le serveur pour déterminer le statut d'une transaction ir, cr, ou kur en cours. (par exemple quand le PKIStatus "waiting" a été reçu).
PollReqContent ::= SEQUENCE OF SEQUENCE {
    certReqId INTEGER }
    
PollRepContent ::= SEQUENCE OF SEQUENCE {
    certReqId INTEGER,
    checkAfter INTEGER, -- time in seconds
    reason PKIFreeText OPTIONAL }

   Les clauses suivantes décrivent quand les messages d'interrogation sont utilisés, et comment ils sont utilisés. Il est assumé que plusieurs messages certConf peuvent être envoyés durant les transactions. Il y'en aura un envoyé en réponse à chaque ip, cp, kup qui contient un CertStatus pour un certificat émis.

1. En réponse à un message ip, cp, ou kup, un EE va envoyer un certConf pour tous les certificats émis et, suivant le ack, un pollReq pour tous les certificats en attente.
2. En réponse à un message à un pollReq, une CA/RA va retourner un ip, cp, kup si un ou plusieurs certificats sont prêts; sinon, elle retourne un pollRep
3. Si l'EE reçois un pollRep, il attend au moins checkAfter avant d'envoyer un autre pollReq
4. Si nu ip, cd, ou kup est reçu en réponse à un pollReq, alors il sera traité de la même manière que la réponse initiale.


_______________________________START
_________________________________|
_________________________________v
______________________________Send_ir
_________________________________|_ip
_________________________________v
____________________________Check_status
____________________________of_returned_‹------------------------+
_______________________________certs_____________________________|
_________________________________|_______________________________|
_______+------------------------›|‹------------------+___________|
_______|_________________________|___________________|___________|
_______|________(issued)_________v_______(waiting)___|___________|
_____Add_to_‹-----------_Check_CertResponse_------›_Add_to_______|
____conf_list___________for_each_certificate______pending_list___|
_________________________________/_______________________________|
________________________________/________________________________|
___________________(conf_list)_/_____(empty_conf_list)___________|
______________________________/_____________________ip___________|
_____________________________/_________________+----------------+
______(empty_pending_list)__/__________________|____pRep
________END_‹----_Send_certConf_________Send_pReq------------›Wait
_________________________|_________________^___^_______________|
_________________________|_________________|___|_______________|
_________________________+-----------------+___+---------------+
____________________________(pending_list)

Dans l'échange suivant, l'EE s'enregistre pour 2 certificats en une seule demande:
Step__End_Entity_______________________PKI
____1___Format_ir
____2____________________-›_ir______-›
____3____________________________________Handle_ir
____4____________________________________Manual_intervention_is
_________________________________________required_for_both_certs.
____5____________________‹-_ip______‹-
____6___Process_ip
____7___Format_pReq
____8____________________-›_pReq_____-›
____9____________________________________Check_status_of_cert_requests
____10___________________________________Certificates_not_ready
____11___________________________________Format_pRep
____12___________________‹-_pRep_____‹-
____13__Wait
____14__Format_pReq
____15___________________-›_pReq_____-›
____16___________________________________Check_status_of_cert_requests
____17___________________________________One_certificate_is_ready
____18___________________________________Format_ip
____19___________________‹-_ip_______‹-
____20__Handle_ip
____21__Format_certConf
____22___________________-›_certConf_-›
____23___________________________________Handle_certConf
____24___________________________________Format_ack
____25___________________‹-_pkiConf___‹-
____26__Format_pReq
____27___________________-›_pReq_____-›
____28___________________________________Check_status_of_certificate
____29___________________________________Certificate_is_ready
____30___________________________________Format_ip
____31___________________‹-_ip_______‹-
____31__Handle_ip
____32__Format_certConf
____33___________________-›_certConf_-›
____34___________________________________Handle_certConf
____35___________________________________Format_ack
____36___________________‹-_pkiConf__‹-

Fonctions de gestion de PKI obligatoire

   Cette section décris les fonctions qui sont obligatoires dans le sens que toutes les implémentations EE, CA et RA doivent être capable de fournir les fonctionnalités décrites.

Initialisation de la CA root

   Une CA root nouvellement créée doit produire un certificat auto-émis, qui est une structure Certificate avec le profile définis pour le certificat "newWithNew" émis par la mise à jours de la clé CA.

   Pour que le certificat de la CA soit utile aux entités finales qui ne l'obtiennent pas par des moyens tiers, la CA doit également produire une empreinte pour son certificat. La structure de données utilisée pour gérer l'empreinte est OOBCertHash.

Mise à jours de la clé CA

   Les clés CA ( comme toutes les autres clés) on une durée de vie finie et doivent être mis à jours périodiquement. Les certificats NewWithNew, NewWithOld, et OldWithNew peuvent être émis par la CA pour aider les EE existantes qui possèdent l'ancien certificat auto-signé (OldWithOld) à passer de manière sécurisée au nouveau certificat (NewWithNew), et pour aider les nouvelles entités qui ont NewWithNew à obtenir OldWithOld pour la vérification de donné existante.

Initialisation de CA subordonnée

   Du point de vue des protocoles de gestion de PKI, l'initialisation d'une CA subordonnée est la même que l'initialisation d'un entité finale. La seule différence est que la CA subordonnée doit également produire une liste de révocation initiale.

Production de CRL

   Avant d'émettre des certificats, une CA nouvellement établie ( qui émet des crls ) doit produire des versions vides de chaque CRL qui sont périodiquement produites.

Demande d'information PKI

   Quand une entité PKI (CA, RA, ou EE) souhaite acquérir des informations sur le status courant d'une CA, elle peut lui envoyer une demande pour de telles informations.

   La CA doit répondre à le demande en fournissant toutes les informations demandées. Si certaines informations ne peuvent pas être fournies, une erreur doit être retournée.

   Si des PKIMessages sont utilisés pour demander et fournir cette information, alors la requête doit être le message GenMsg, la réponse doit être le message GenRep, et l'erreur doit être le message Error. Ce messages sont protégés en utilisant un MAC basé sur une information de secret partagé, ou en utilisant un autre moyen authentifié (si l'EE a un certificat existant).

Cross Certification

   Le demandeur CA est la CA qui va devenir le sujet du cross-certificat; le répondeur CA va devenir l'émetteur du cross-certificat. Le demandeur CA doit être "up and running" avant d'initialiser l'opération de cross-certification.

Schéma demande-réponse une voie

   Le schéma de cross-certification est essentiellement une opération one-way; c'est à dir, quand réussit, cette opération résulte en la création d'un nouveau cross-certificat. Si le pré-requis est que ce cross-certificat soit créé dans les 2 direction, alors chaque CA, en retour, doit initialiser une opération de cross-certification ( ou utiliser un autre schéma ).

   Ce schéma est prévu quand les 2 CA en question peuvent déjà se vérifier mutuellement leur signature. Description détaillée:

   La cross certification est initiée à une CA connue comme répondeur. L'administrateur CA pour le répondeur identifie la CA qu'il veut cross certifier et l'équipement du répondeur génère un code d'autorisation. L'administrateur du répondeur passe ce code d'autorisation à la CA demandeuse via un moyen externe à l'administrateur de la CA demandeuse, qui utilise ce code pour initier l'échange on-line.

   Le code d'autorisation est utilisé pour l'authentification et l'intégrité. C'est fait en générant une clé symétrique basée sur le code d'autorisation et en utilisant la clé symétrique pour générer des MAC pour tous les messages échangés. ( Une authentification peut alternativement être faite en utilisant les signature au lieu des MAC, si les CA sont capable de récupérer et valider les clés publiques requise.)

   La CA demandeuse initie l'échange en générant un demande de cross-certification ( ccr ) avec un nouveau nombre aléatoire. La CA demandeuse envoie le message ccr au répondeur. Les champs dans ce message sont protégés des modification avec un MAC basé sur le code d'autorisation.

   À la réception du message ccr, le répondeur valide le message et le MAC, sauvegarde le nombre aléatoire du demandeur, et génère son propre nombre aléatoire. Il génère ainsi un nouveau certificat qui contient la clé publique de la CA demandeuse et est signée avec la clé privée du répondeur. Le répondeur répond avec un message ccp. Les champs dans ce message sont protégés des modification avec un MAC basé sur le code d'autorisation.

   À la réception du message ccp, la CA demandeuse valide le message et le MAC. la CA demandeuse répond avec le message certConf. Les champs dans ce message sont protégés des modifications avec un MAC basé sur le code d'autorisation. La CA demandeuse peut écrire le certificat dans le dépôt comme aide pour la construction de future chemins de certificats.

   Une fois le message certConf reçu, le répondeur valide le message et le MAC, et envoi un accusé en utilisant le message PKIConfirm. Il peut également publier le certificat.

Notes

1. Le message ccr doit contenir une demande de certification complète: c'est à dire, tous les champs exceptés le numéro de série doivent être spécifiés par la CA demandeuse.
2. Le message ccp devrait contenir le certificat de vérification du répondeur; si présent, la CA demandeuse doit vérifier ce certificat.

   Une version plus simple et non-interactive de la cross-certification peut également être envisagé, dans lequel la CA émettrice obtient la clé publique de la CA depuis un dépôt, la vérifie via un mécanisme externe, et créé et publie le cross-certificat sans le concours explicite de la CA.

Initialisation de l'entité finale

   Comme avec les CA, les entités finales doivent être initialisées. L'initialisation des entités finales nécessite au moins 2 étapes:

- Acquisition des informations de la PKI
- Vérification tiers d'une clé publique de CA root

Acquisition d'information PKI

   Les informations requises sont:

- La clé publique de la CA racine courante
- (Si la CA certifiante n'est pas la CA racine) le chemin de certification depuis la CA racine jusqu'à la CA certifiante, avec les listes de révocation appropriés.
- Les algorithmes et paramètres d'algorithme que la CA certifiante supporte pour chaque utilisation.

   Des informations additionnelles peuvent être requises ( ex: extensions supportées ou informations de stratégie de CA) pour pouvoir produire une demande de certification qui sera réussie. Cependant, par simplicité, on n'oblige par l'EE d'obtenir ces information via les messages PKI. Le résultat final est simplement que certaines demandes de certification peuvent échouer (ex: si l'EE veut générer sa propre clé de chiffrement, mais que la CA ne le permet pas).

Vérification Out-of-Band de la clé CA racine

   Une EE doit posséder de manière sécurisée la clé publique de sa CA racine. Une méthode consiste à fournir à l'EE une empreinte du certificat de la CA via un moyen externe sécurisé. L'EE peut ainsi utiliser le certificat de la CA.

Demande de certificat

   Une EE initialisée peut demander un certificat additionnel à tout moment. Cette demande sera faite en utilisant le message de demande de certification (cr). Si l'EE possède déjà une paire de clé de signature ( avec un certificat de vérification correspondant ), alors ce message cr sera protégé par la signature numérique de l'entité. La CA retourne le nouveau certificat dans un CertRepMessage.

Mise à jour de clé

   Quand une paire de clé va expirer, l'entité finale peut demander une mise à jour de clé; c'est à dire, qu'elle peut demander à la CA d'émettre un nouveau certificat pour une nouvelle paire de clé (ou, dans certaines circonstances, un nouveau certificat pour la même paire de clé (. La demande est faite en utilisant un message de demande de mise à jour de clé (kur). Si l'EE possède déjà une paire de clé de signature ( avec le certificats de vérification correspondant ), alors ce message sera typiquement protégé par la signature numérique de l'entité. La CA retourne le nouveau certificat ( si la demande est réussie) dans une réponse de mise à jour de clé (kup), qui est syntaxiquement identique à un CertRepMessage.

Négociation de version

   Cette section définis la négociation de version utilisée pour supporter d'anciens protocoles entre client et serveurs.

   Si un client connaît les versions de protocoles supportés par le serveur (ex: depuis un précédent échange PKIMessage ou via un moyen externe ), il doit envoyer un PKIMessage avec la version la plus haute supportée par lui et le serveur. Si un client ne connaît pas les versions supportées par le serveur, il doit envoyer un PKIMessage en utilisant la version la plus élevée qu'il supporte.

   Si un serveur reçoit un message avec une version qu'il supporte, alors la version du message de réponse doit être la même que la version reçue. Si un serveur reçoit un message avec une version plus élevée ou moins élevée qu'il ne supporte, il doit envoyer en ErrorMsg avec le bit unsupportedVersion ( dans le champ failureInfo de pKIStatusInfo ). Si la version reçue est supérieur à la versions supportée, la version dans le message d'erreur doit être la plus haute version que le serveur supporte; si la version reçue est inférieur à la version la plus basse supportée par le serveur alors la version dans le message d'erreur doit être la version la plus basse que le serveur supporte.

   Si un client reçoit un ErrorMsgContent avec le bit unsupportedVersion et une version qu'il supporte, il peut retenter la requête avec cette version.

Support des implémentation rfc2510

   La rfc2510 ne spécifie pas le comportement des implémentation recevant des versions qu'il ne comprend pas vu qu'il ne comprend qu'une seule version. Avec l'introduction de cette révision, le comportement suivant sur le versionning est recommandé.

Clients parlant aux serveurs rfc2510

   Si, après avoir envoyé un message cmp2000, un client reçois un ErrorMsgContent avec une version de cmp1999, alors il doit annuler la transaction. Il peut ensuite retenter la transaction en utilisant des message cmp1999.

   Si un client reçois un PKIMessage non-erreur avec une version de cmp1999, il peut décider de continuer la transaction en utilisant les sémantiques rfc2510. S'il choisis de ne pas le faire et que la transaction n'est pas terminée, il doit annuler la transaction et envoyer un ErrorMsgContent avec une version de cmp1999.

Serveurs reçevant des PKIMessage cmp1999

   Si un serveur reçoit un message cmp1999, il peut revenir à un comportement rfc2510 et répondre avec des messages cmp1999. S'il choisi de ne pas le faire, il doit envoyer un ErrorMsgContent.

Considérations de sécurité

POP avec une clé de déchiffrement

   Dans les protocoles spécifiés avant, quand une entité finale doit prouver la possession d'un clé de déchiffrement, il est effectivement challengé pour déchiffrer quelque-chose (son propre certificat). Ce schéma (et beaucoup d'autres) peut être vulnérable à une attaque si le propriétaire de la clé de déchiffrement en question peut être dupé en déchiffrant un challenge arbitraire et en retournant le texte en clair à un attaquant. Bien que dans cette spécification, d'autres problèmes de sécurité sont requis pour que cette attaque réussise, il est concevable que des services futures pourraient être vulnérable à de telles attaques. Pour cette raison, on réitère la règle générale que les implémentations devraient suivre sur le déchiffrement arbitraire et la révélation du texte récupéré.

POP en exposant la clé privée

   Noter également qu'exposer une clé priée à la CA/RA comme technique POP peut exposer à des risques de sécurité. Les implémenteurs doivent faire preuve de prudence en sélectionnant et utilisant ce mécanisme POP particulier.

Appendice A. Raisons de la présence des RA

   Les raisons qui justifient la présence d'un RA peut être séparés en ceux, d'un part, qui sont dûs à des facteurs techniques, et ceux qui d'autre part sont de nature organisationnelles. Les raisons techniques sont les suivante:

- Si des jetons hardwares sont utilisé, toutes les entités finales n'ont pas l'équipement nécessaire à les initialiser; l'équipement RA peut inclure les fonctionnalités nécessaires.
- Certaines entités finales peuvent ne pas avoir la capacité de publier les certificats; de même, la RA peut être utilisé pour cela.
- La RA sera capable d'émettre des demandes de révocation signées à la demande des entités finales associées avec elle, alors que l'entité final peut ne pas être en mesure de le faire ( Si la paire de clé est complètement perdue ).

   Certaines raisons organisationnelles qui demandent la présente d'une RA sont:

- Il peut y avoir une raison de coût de concentrer les fonctionnalités dans un équipement RA plutôt que de fournir ces fonctionnalités à tous les EE.
- Établir des RA dans une organisation peut réduire le nombre de CA requises, ce qui est parfois désirable
- Pour beaucoup d'applications, Il y aura déjà en place une structure administrative pour que les candidats pour le rôle de RA soit facile à trouver.

Appendice B. Utilisation de passphrase de révocation

   Une demande de révocation doit incorporer des mécanismes de sécurité prévu, incluant une authentification propre, pour réduire la probabilité d'attaques DOS réussies. Une signature numérique dans la requête peut fournir l'authentification requise, mais il y a des circonstances sous lesquelles un mécanisme alternatif peut être souhaité (par ex: quand une clé privée n'est plus accessible et que l'entité souhaite demander une révocation avant de re-certifier une autre paire).

   Pour de telles circonstances, un PasswordBasedMac dans la demande est également obligatoire pour supporter cette spécification si les demandes de révocations sont également supportées et si les informations de secret partagé peuvent être établis entre le demandeur et le répondeur avant le besoin de révocation.

   Un mécanisme qui est utilisé dans certains environnement est la passphrase de révocation, dans lequel une valeur d'entropy suffisante ( ex: une passphrase relativement plus longue qu'un mot de passe court) est partagé entre (seulement) l'entité et la CA/RA à un certain moment avant la révocation; cette valeur est ensuite utilisé pour authentifier la demande de révocation.

   Dans cette spécification, la technique suivante pour établir une information à secret partagé est optionnelle. Son utilisation précise dans les messages CMP sont comme suit.

   L'OID et la valeur spécifié dans la section "passphrase de révocation" peuvent être envoyé dans un message GenMsg à tout moment, ou peut être envoyé dans le champ generalInfo du PKIHeader d'un PKIMessage a tout moment. ( En particulier, EncryptedValue peut être envoyé dans l'en-tête du message CertConf qui confirme l'acceptation des certificats requis dans une demande d'initialisation ou une demande de certification.). Cela transmet une passphrase de révocation choisie par l'entité ( ex: les octets déchiffrés du champ encValue) à la CA/RA; en outre, le transfert est accomplis avec les caractéristiques de confidentialité appropriés ( parce que la passphrase est chiffrée avec le protocolEncryptionKey de la CA/RA).

   Si une CA/RA reçois la passphrase de révocation dans un GenMsg, elle doit construire et envoyer un message GenRep qui inclus l'OID ( avec une valeur absente) spécifiée dans la section "passphrase de révocation". Si la CA/RA reçois la passphrase de révocation dans le champ generalInfo d'un PKIHeader d'un PKIMessage, elle doit inclure l'OID ( avec une valeur absente) dans le champ generalInfo du PKIHeader du PKIMessage de réponse correspondant. Si la CA/RA n'arrive pas à retourner le message de réponse approprié, elle doit envoyer un message d'erreur avec un status de rejet et optionnellement, un jeu de raison failInfo.

   Le champ valueHint de EncryptedValue peut contenir un identifiant de clé (choisi par l'entité finale, avec la passphrase elle-même) pour assister à la récupéraion de la passphrase correcte (ex, quand la demande de révocation est construite par l'entité et reçue par la CA/RA).

   Le messages de demande de révocation est protégé par un PasswordBasedMac, avec la passphrase de révocation comme clé. Si approprié, le champ senderKID dans le PKIHeader peut contenir la valeur précédemment transmise dans valueHint.

   En utilisant la technique spécifiée ci-dessus, la passphrase de révocation peut être initialement établie et mise à jour à tout moment sans nécessiter de messages supplémentaires ou d'échange externes. Par exemple, le message de demande de révocation lui-même (protégé et authentifié via un MAC qui utilise la passphrase de révocation comme clé) peut contenir, dans le PKIHeader, une nouvelle passphrase de révocation à utiliser pour authentifier de futures demandes de révocation pour tout autre certificat de l'entité. Dans certains environnements cela peut être préférable aux mécanismes qui révèlent la passphrase dans le message de demande de révocation, vu que cela peut permettre une attaque DOS dans laquelle la passphrase révélée est utilisée par un tier non-autorisé pour authentifier les demandes de révocation pour les autres certificat de l'entité. Cependant, parce que la passphrase n'est pas révélée dans la requête, il n'y a pas de pré-requis pour que la passphrase soit toujours mise à jours quand la demande de révocation est faite ( c'est à dire, la même passphrase peut être utilisée par une entité pour authentifier les demandes de révocation pour différents certificats à différents moments).

   De plus, la technique ci-dessus peut fournir une protection cryptographique forte sur tout le message de demande de révocation même quand une signature numérique n'est pas utilisée. Les techniques qui font de l'authentification de la demande de révocation en révélant simplement la passphrase de révocation ne fournissent pas de protection cryptographique sur les champs du message (donc une demande de révocation d'un certificat peut être modifié par un tier non autorisé pour révoquer un autre certificat pour cette entité).

Appendice C - Clarification du conportement des messages de demande

Dans le cas des mises à jours de la rfc4211, qui apporte des problème d'interprétation ou d'intéropérabilité, la rfc4211 devrait être le document normatif. Les définitions suivante viennent de la rfc4211. Elles sont inclues ici pour codifier les clarifications de comportement; sinon toutes les syntaxes et sémantiques sont identiques à la rfc4211.
CertRequest ::= SEQUENCE {
    certReqId INTEGER,
    certTemplate CertTemplate,
    controls Controls OPTIONAL }
    
-- Si certTemplate est une séquence vide, alors les contrôles peuvent contenir le contrôle
-- id-regCtrl-altCertTemplate, spécifiant un template pour un certificat autre qu'un
-- certificat à clé-publique x509v3. Inversement, si certTemplate n'est pas vide (au moins
-- un champ est présent), alors les contrôles ne doivent pas contenir id-regCtrl-altCertTemplate.
-- Le nouveau contrôle est définis comme suit:
    
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
    
POPOSigningKey ::= SEQUENCE {
    poposkInput [0] POPOSigningKeyInput OPTIONAL,
    algorithmIdentifier AlgorithmIdentifier,
    signature BIT STRING }
    
-- La signature (en utilisant AlgorithmIdentifier) est dans la valeur encodée DER de poposkInput.
-- Note: si CertReqMsg certReq certTemplate ( ou le contrôle altCertTemplate) contient les valeurs
-- subject et publicKey, alors poposkInput doit être omis et la signature doit être calculée dans
-- la valeur encodée DER de CertReqMsg certReq ( ou la valeur encodée DER de AltCertTemplate).
-- Si certTemplate/altCertTemplate ne contient ni le sujet ni la clé publique, poposkInput doit
-- être présent et doit être signé.
    
POPOPrivKey ::= CHOICE {
    thisMessage [0] BIT STRING,
    
-- Le type de "thisMessage" est donné en chaîne de bit dans la rfc4211; mais devrait être un
-- "EncryptedValue", en accord avec cette spécification.
    
    subsequentMessage [1] SubsequentMessage,
    dhMAC [2] BIT STRING }

Appendice D. profils de messages de gestion

   Cet appendice contient les profils détaillés pour ces PKIMessages qui doivent être supportés par les implémentations conformes. Les profils pour les PKIMessages utilisés dans les opérations de gestion PKI suivant sont fournis:

- Enregistrement/certification initiale
- Schéma authentifié de base
- Demande de certificat
- Mise à jour de clé

Règles générales pour l'interprétation de ces profils

1. Où les champs OPTIONAL ou DEFAULT ne sont pas mentionnés dans les profiles, ils doivent être absent du message. Les champs obligatoire ne sont pas mentionnés s'il ont une valeur évidente. (ex dans la version de cette spécification, pvno est toujours 2).
2. Où les structures se trouvent dans plus d'un message, elles sont profilés séparément comme appropriées.
3. Les algorithmIdentifier des structures PKIMessage sont profilés séparément.
4. Un DN X.500 spécial est appelé le "NULL-DN"; cela signifie un DN contenant une séquence RelativeDistinguishedNames de longueur 0 (son encodé DER est alors '3000'H).
5 Où un GeneralName est requis pour un champ, mais qu'aucune valeur prévue n'est disponible (ex: une entité produit une demande avant de connaître son nom), alors le GeneralName doit être un NULL-DN. Cette valeur spéciale peut être appelée NULL-GeneralName.
6. Où un profil omit de spécifier la valeur pour un GeneralName, la valeur NULL-GeneralName doit être présente dans le champs PKIMessage concerné.
7. Où toute ambiguïté peut se produire à cause du nommage des champs, le profile les nomme en utilisant une notation "point" (ex: certTemplate.subject signifie le champ subject dans un champ appelé certTemplate).
8. Où une séquence de types fait partie d'un message, une notation en tableau basé sur des 0 est utilisée pour décrire les champs dans la séquence (ex: crm[0].certReq.certTemplate.subject réfère à un sous-champ du premier CertReqMsh contenu dans un message de demande).
9. Tous les échanges de message PKI décris plus bas dans cet appendice nécessitent qu'un message certConf soit envoyé par l'entité qui initie et un PKIConfirm par l'entité qui répond. Le PKIConfirm n'est pas inclus dans certains profiles donnés vu que sont contenu est NULL et son header peut être utilisé pour le protectionAlg.

Utilisation des algorithmes

   La table suivante contient les définitions de l'utilisation d'algorithme dans les protocoles de gestion PKI. Les colonnes dans la table sont:

Name: Un identifiant utilisé pour les profiles de message
Use: Une description d'ou et pourquoi l'algorithme est utilisé
Mandatory: Un AlgorithmIdentifier qui doit être supporté par les implémentations conformes.
others: Alternatives à AlgorithmIdentifier.

Name_________Use________________________________________________Mandatory__________________Others
MSG_SIG_ALG__Protection des messages en utilisant une signature_DSA/SHA-1__________________RSA/MD5,ECDSA,...
MSG_MAC_ALG__Protection des messages en utilisant MAC___________PasswordBasedMac___________HMAC, X9.9,...
SYM_PENC_ALG_Chiffrement symétrique de la clé privée de l'EE____3-DES (3-key-EDE,CBC mode)_AES,RC5,CAST-128,...
PROT_ENC_ALG_Chiffrement asymétrique de la clé privée___________D-H________________________RSA,ECDH,...
PROT_SYM_ALG_Chiffrement symétrique des bits de la clé privée___3-DES (3-key-EDE,CBC mode)_AES,RC5,CAST-128,...

AlgorithmIdentifier mandatoire et spécifications:
DSA/SHA-1:
    AlgId: {1 2 840 10040 4 3};
    
Digital Signature Standard [FIPS-186]
    Public Modulus size: 1024 bits.
    
PasswordBasedMac:
    AlgId: {1 2 840 113533 7 66 13}, avec SHA-1 {1 3 14 3 2 26} et HMAC-SHA1 {1 3 6 1 5 5 8 1 2};
    
Secure Hash Standard [FIPS-180] and [RFC2104]
    HMAC key size: 160 bits (i.e., "K" = "H" in Section 5.1.3.1, "Shared secret information")
    
3-DES:
    AlgId: {1 2 840 113549 3 7}; (used in RSA's BSAFE and in S/MIME).
    
D-H:
    AlgId: {1 2 840 10046 2 1};
    
[ANSI-X9.42]
    Public Modulus Size: 1024 bits.
    DomainParameters ::= SEQUENCE {
        p INTEGER, -- odd prime, p=jq +1
        g INTEGER, -- generator, g^q = 1 mod p
        q INTEGER, -- prime factor of p-1
        j INTEGER OPTIONAL, -- cofactor, j›=2
        validationParms ValidationParms OPTIONAL
    }
    ValidationParms ::= SEQUENCE {
        seed BIT STRING, -- seed for prime generation
        pGenCounter INTEGER -- parameter verification
    }

Profile POP

Les champs POP utilisé (dans le champ signature du champ pop de la structure ProofOfPossession) en prouvant la possession d'une clé privée de signature qui correspond à une clé publique de vérification pour laquelle un certificat a été demandé.
Field_______________Value_________Comment
algorithmIdentifier_MSG_SIG_ALG___Seul la protection de la signature est permise pour cette preuve
signature___________present_______bits calculés en utilisant MSG_SIG_ALG

   La preuve de possession d'une clé privée de déchiffrement qui correspond à une clé public de chiffrement pour laquelle un certificat a été demandé n'utilise pas ce profile; le champ CertHash du message certConf est utilisé à la place.

   Toutes les CA/RA ne font pas de POP dans le protocole de demande de certification ( comment POP est faite peut être un problème de stratégie explicite pour une CA). Cependant, cette spécification mandate que les entités CA/RA doivent faire une POP comme partie du processus de certification. Toutes les entités finales doivent être préparée à fournir une POP.

Enregistrement/certification initial - schéma authentifié de base

   Une entité finale ( non initialisée ) demande un (premier) certificat à une CA. Quand la CA répond avec une message contenant un certificat, l'EE répond avec une confirmation de certificat. La CA envoie en PKIConfirm en retour, terminant la transaction. Tous les message sont authentifiés.

   Ce schéma permet à l'EE de demander une certification d'une clé publique générée localement (typiquement une clé de signature). L'EE peut également choisir de demander la génération et la certification centralisée d'une autre paire de clé (typiquement une paire de clé de chiffrement). La certification peut seulement être demandée pour en clé publique générée localement.

   L'EE doit supporter le POP d'une clé privée, associée avec la clé publique générée localement.

  Préconditions:

1. L'EE peut authentifier la signature de la CA via un moyen externe
2. L'EE et la CA partage une clé MAC symétrique

Flux de messages:
Step#_End_entity___________________________PKI
______1___format_ir
______2______________________-›___ir______-›
______3________________________________________handle_ir
______4________________________________________format_ip
______5______________________‹-___ip______‹-
______6___handle_ip
______7___format_certConf
______8______________________-›___certConf_-›
______9________________________________________handle_certConf
_____10________________________________________format_PKIConf
_____11______________________‹-___PKIConf__‹-
_____12___handle_PKIConf

   Pour ce profile, on mandate que l'EE doit inclure tous CertReqMsg dans un simple PKIMessage, et que le PKI (CA) doit produire une seul réponse PKIMessage qui contient la réponse complète (ex: incluant la seconde paire de clé optionnelle, s'il elle a été demandée et si la génération de la clé centralisée est supportée). Par simplicité, on mandate également que ce message doit être le final (ex: pas d'utilisation du status "waiting").

   L'EE a une interaction out-of-band avec la CA/RA. Cette transaction établis le secret partagé, le referenceNumber et optionnellement le dn utilisé pour sender et subject dans le template du certificat. Il est recommandé que le secret partagé ait au moins 12 caractères de long.

Demande de certificat

   Une EE (initialisé) demande un certificat depuis une CA. Quand la CA répond avec un message contenant un certifica, l'EE répond avec une confirmation de certificat. La CA répond avec un PKIConfirm, pour terminer la transaction. Tous les messages sont authentifiés. Le profile pour cet échange est identique à celui donné précédemment excepté:

- Le nom de l'émetteur devrait être présent
- protectionAlg de MSG_SIG_ALG doit être supporté ( MSG_MAC_ALG peut l'être également) dans le demande, la réponse, certConfirm et les PKIMessages.
- senderKID et recipKID sont seulement présents si requis pour la vérification du message
- body est cr ou cp
- body peut contenir une ou 2 structures CertReqMsg, mais CertReqMsg peut être utilisé pour demander une certification d'une clé publique générée localement ou une clé publique générée centralement.
- Les bits de protection sont calculés en accord avec le champ protectionAlg

Demande de mise à jour de clé

   Une entité finale ( initialisée ) demande un certificat à une CA ( pour mettre à jours la paire de clé et/ou le certificat correspondant qu'il possède déjà ). Quand la CA répond avec un message contenant un certificat, l'EE répond avec une confirmation de certificat. La CA répond avec un PKIConfirm, pour terminer la transaction. Tous les messages sont authentifiés. Le profile pour cet échange est identique à celui donné précédemment excepté:

- Le nom de l'émetteur devrait être présent
- protectionAlg de MSG_SIG_ALG doit être supporté ( MSG_MAC_ALG peut l'être également) dans le demande, la réponse, certConfirm et les PKIMessages.
- senderKID et recipKID sont seulement présents si requis pour la vérification du message
- body est kur ou kup
- body peut contenir une ou 2 structures CertReqMsg, mais CertReqMsg peut être utilisé pour demander une certification d'une clé publique générée localement ou une clé publique générée centralement.
- Les bits de protection sont calculés en accord avec le champ protectionAlg
- regCtrl OldCertId devrait être utilisé

Appendice E: Profile de message de gestion PKI

   Cet appendice contient les profile pour les PKIMessages qui peuvent être supportés par les implémentations. Les profiles pour les PKIMessages utilisé dans les opération de gestion PKI suivant sont fournis:

- Mise à jours de clé CA racine
- Demande/réponse d'informations
- Demande/réponse de cross-certification
- Initialisation in-band en utilisant en certificat d'identité externe.

Certificats auto-signés

Le profile sur la manière dont un certificat peut être auto-signé. Ces structures sont utilisées pour les distributions de clés publiques de CA. Cela peut se produire d'une des 3 manières.
Type________Fonction
newWithNew__Une vrai certificat auto-signé; la clé publique contenue doit être utilisable pour vérifier la signature
oldWithNew__La précédente clé CA Root signée avec la nouvelle clé privée.
newWithOld__La nouvelle clé publique CA root signée avec la précédente clé privée.

   De tels certificats doivent contenir les valeurs sensibles pour tous les champs. Par exemple, quand présent, subjectAltName doit être identique à issuerAltName, et, quand présent, keyIdentifier doit contenir les valeurs appropriées, etc.

Mise à jours de clé Root

   Une CA racine met à jour sa paire de clé. Elle produit ainsi un message d'annonce de mise à jours de clé CA qui peut être disponible (via certains mécanismes de transport) aux EE concernées. Un message de confirmation n'est pas requis pour les EE.

Demande/réponse d'information PKI

   L'entité finale envoie un message général à la PKI demandant des détails qui sont requis pour d'autres opérations de gestion PKI. La RA/CA répond avec une réponse générale. Si une RA génère la réponse, alors il va simplement transférer le message équivalent qui a été précédemment reçus de la CA, en ajoutant possiblement les certificats dans les champs extraCerts du PKIMessage. Un message de confirmation n'est pas requis pour les EE.

Demande/réponse de cross-certification

   La création d'un simple cross-certificat (ex: pas 2 en même temps). La CA demandeuse peut choisir qui est responsable pour la publication du cross-certificat créé par la CA répondante via l'utilisation du contrôle PKIPublicationInfo.

  Préconditions:

1. La CA répondante peut vérifier l'origine de la demande avant de traiter la demande.
2. La CA demandeuse peut authentifier l'authenticité de l'origine de la réponse avant de traiter la réponse.

   L'utilisation de confirmation de certification et la confirmation du serveur correspondant est déterminé par le champ generalInfo dans le PKIHeader. Le profile suivant ne mandate pas le supporte pour ces confirmations.

Initialisation in-band via certificat externe

   Une EE ( non-initialisée ) souhaite s'initialiser dans la PKI avec une CA, CA-1. Elle utilise, pour l'authentification, un certificat d'identité pré-existant émis par une autre CA (externe), CA-X. Une relation de confiance doit déjà avoir été établis entre CA-1 et CA-X pour que CA-1 puisse valider le certificat de l'EE signé par CA-X. De plus, certains mécanismes doivent déjà avoir été établis dans le PSE de l'EE qui lui permet d'authentifier et vérifier les PKIMessage signés par CA-1.

   L'EE envoie une demande d'initialisation pour démarrer la transaction. Quand CA-1 répond avec un message contenant le nouveau certificat, l'EE répond avec une confirmation de certificat. CA-1 répond avec un PKIConfirm pour terminer la transaction. Tous les messages sont signés ( les messages EE sont signés en utilisant la clé privée qui correspond à la clé publique dans son certificat d'identité externe, les messages CA-1 sont signés en utilisant la clé privée qui correspond à la clé publique dans un certificat qui peut être chaîné à une ancre de confiance dans le PSE de l'EE). Le profile pour cet échange est identique à celui donné précédemment excepté:

- L'EE et CA-1 ne partagent pas de clé MAC symétrique
- Le nom de l'émetteur dans ir doit être présent
- protectionAlg de MSG_SIG_ALG doit être utilisé dans tous les messages
- le certificat d'identité externe doit être géré dans le champ extraCerts de ir
- senderKID et recipKID ne sont pas utilisés.
- body est ir ou ip
- Les bits de protections sont calculés en accord avec le champ protectionAlg
^
12 mai 2015

htmlpdflatexmanmd




OpenSSL - ecparam

OpenSSL - ecparam

Manipulation et génération de paramètre EC

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-out filename fichier de sortie où écrire les paramètres
-text Affiche des infos sur les clés privée et publique
-noout n’affiche pas la version encodée des paramètres
-C Convertis les paramètres EC en code C.
-check Valide les paramètres de courbe elliptique
-name arg Utilise les paramètres EC avec le nom court spécifié.
-list_curves Affiche la liste de tous les paramètres EC implémentés.
-conv_form Spécifie comment les points sur la courbe elliptique sont convertis en chaîne d'octets ( compressed, uncompressed ou hybrid ).
-param_enc arg Spécifie comment les paramètres de courbe elliptique sont encodés. named_curve ou explicit
-no_seed Inhibe que le 'seed' pour la génération de paramètre soit inclus dans la structure ECParameters
-genkey Génère une clé privée EC en utilisant les paramètres spécifiés
-rand file Un ou plusieurs fichiers contenant des données aléatoires.
-engine id ecparam va tenter d’obtenir une référence fonctionnelle de ce moteur.

Notes

la forme PEM des paramètres EC utilisent la forme:
-----BEGIN EC PARAMETERS-----
-----END EC PARAMETERS-----

Exemples

Créer des paramètres EC avec le groupe 'prime192v1':
openssl ecparam -out ec_param.pem -name prime192v1
Créer des paramètres EC avec les paramètres explicites:
openssl ecparam -out ec_param.pem -name prime192v1 -param_enc explicit
Valider les paramètres EC donnés:
openssl ecparam -in ec_param.pem -check
Créer des paramètres EC et une clé privée:
openssl ecparam -out ec_key.pem -name prime192v1 -genkey
Changer l'encodage des points à compressed:
openssl ecparam -in ec_in.pem -out ec_out.pem -conv_form compressed
Afficher les paramètres EC:
openssl ecparam -in ec_param.pem -noout -text
^
12 mai 2015

htmlpdflatexmanmd




OpenSSL - ec

OpenSSL - ec

Outil de traitement de clé EC

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie où écrire la clé
-passout password source du mot de passe du fichier de sortie
-des|-des3|-idea Chiffre la clé privée avec DES, triple DES ou IDEA, ou un autre chiffrement supporté
-text Affiche des infos sur les clés privée et publique
-noout N’affiche pas la version encodée de la clé
-modulus Affiche la valeur du modulo de la clé
-pubin Lit une clé publique en entrée plutôt qu’une clé privée
-pubout Sort une clé publique plutôt qu’une clé privée
-engine id ec va tenter d’obtenir une référence fonctionnelle de ce moteur.
-conv_form Spécifie comment les points sur la courbe elliptique sont convertis en chaîne d'octets ( compressed, uncompressed ou hybrid ).
-param_enc arg Spécifie comment les paramètres de courbe elliptique sont encodés. named_curve ou explicit

Notes

la forme PEM de la clé privée contient:
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----

Exemples

Chiffrer une clé privée avec 3DES:
openssl ec -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl ec -in key.pem -outform DER -out keyout.der
Afficher les composants d'une clé privée sur stdout:
openssl ec -in key.pem -text -noout
Afficher la partie publique d'une clé privée:
openssl ec -in key.pem -pubout -out pubkey.pem
Changer les paramètres d'encodage à explicit:
openssl ec -in key.pem -param_enc explicit -out keyout.pem
Changer la conversion de point à compressed:
openssl ec -in key.pem -conv_form compressed -out keyout.pem
^
06 mars 2015

htmlpdflatexmanmd




rfc5280

rfc5280, rfc6818

Profile de certification et de liste de révocation de certificat d'infrastructure à clé publique X.509

Introduction

   Cette spécification fait partie d'une famille de standards pour les infrastructures à clé publique X.509 pour l'Internet.

   Cette spécification profile le format et les sémantiques des certificats et des listes de révocation de certificat pour les PKI Internet. Les procédures sont décrites pour traiter les chemins de certification dans l'environnement Internet. Finalement, les modules ASN.1 sont fournis dans l'appendice pour toutes les structures de données définies ou référencées.

La section "Exigences et hypothèses" décris les pré-requis de PKI Internet et les hypothèses qui affectent le périmètre de ce document.
La section "Aperçu de l'approche" Présentent un modèle d'architecture qui décrivent ses relations aux précédant standards IETF et ISO/IEC/ITU-T. En particulier, la relation de ce document avec les spécification PEM IETF et les document ISO/IEC/ITU-T X.509 sont décris.
La section "Profile de certificat et d'extensions de certificat" profile les certificats X.509 version 3.
La section "Profile de CRL et d'extensions de CRL" profile les CRL X.509 v2.
La section "Validation de chemin de certification" inclus les procédures de validation de chemin de certification. Ces procédures sont basée sur la définition ISO/IEC/ITU-T.

   Les procédures pour l'identification et l'encodage des clés publiques et des signatures numérique sont définis dans la rfc3279, la rfc 4055, et la rfc4491. Les implémentations de cette spécification ne sont pas obligés d'utiliser un algorithme crypto-graphique particulier. Cependant, les implémentations conformes qui utilisent les algorithmes identifiés dans la rfc3279,la rfc 4055, et la rfc 4491 doivent identifier en encoder la clé publique et les signatures numérique comme décris dans ces spécifications.

   Finalement, 2 appendices sont fournis pour aider les implémenteurs.

  Cette spécification obsolète la rfc 3280. Les différences sont résumées ici:

- Support amélioré pour les noms internationalisés, avec des règles pour l'encodage et la comparaison de noms de domaines internationalisés, Identifiant de ressources internationalisés (IRI), et de noms distinct. Ces règles sont alignés avec les règles de comparaison établies dans les rfc courantes, incluant la rfc3490, rfc3987 et la rfc 4518.
- Les section "Issuer" et "Subject" incorporent les conditions pour l'utilisation continue de schémas d'encodage de texte existant qui ont été spécifiés dans la rfc4630. Là où c'est utilisé par les PKI établies, la transition vers UTF8String pourrait poser des problème DOS basés sur les erreurs de chaînage de nom ou des traitement incorrecte de contraintes de nom.
- La section qui spécifie l'extension de certificat privateKeyUsagePeriod de la rfc 3280, mais déprécie son utilisant, a été supprimée. L'utilisation de cette extension standards ISO n'est plus dépréciée ni recommandée pour l'utilisation dans les PKI de l'Internet.
- La section Policy Mappings recommande de marquer l'extension de contraintes de stratégie comme critique. La rfc 3280 nécessitait que l'extension de mappage de stratégie soit marquée non critique.
- La section Policy Constraints nécessite que l'extension de contraintes de stratégie soit critique. la rfc 3280 permettait cette extension d'être critique ou non.
- L'extension de CRL AIA, comme spécifié dans la rfc 4325, a été ajoutée.
- Les sections extensions de CRL et extensions d'entrée de crl clarifient les règles pour manipuler les extensions de CRL et d'entrée de CRL non-reconnues, respectivement.
- La section qui spécifie l'extension d'entrée de CRL holdInstructionCode dans la rfc 3280 a été supprimée.
- L'algorithme de validation de chemin ne suit plus la criticité des extensions de stratégie de certificat dans une chaîne de certificats. Dans la rfc 3280, cette information était retourné à un tier de confiance.
- La section de considérations de sécurité adresse les risques de dépendances circulaires se produisant lors de l'utilisation de schémas https ou similaire dans les points de distribution de CRL, AIA, ou extension d'accès aux informations du sujet.
- La section de considérations de sécurité adresse les risques associés aves l'ambiguïté des noms
- La section de considérations de sécurité référence les rfc 4210 pour les procédures pour signaler les changements dans les opération de CA.

Pré-requis et hypothèses

   Le but de cette spécification est de développer un profil pour faciliter l'utilisation des certificats X.509 dans les applications Internet pour les communautés qui souhaitent utiliser la technologie X.509. De telles applications peuvent inclure WWW, les messageries électroniques, l'authentification utilisateur, et IPSec. Afin de soulager certains obstacles à l'utilisation des certificat X.509, cet document définis un profile pour promouvoir le développement de systèmes de gestion de certificat, le développement d'outils applicatifs, et d'interopérabilité déterminé par stratégie.

   Un utilisateur de certificat devrait revoir la stratégie de certificat générée par l'autorité de certification avant de faire confiance aux services d'authentification et de non-répudiation associés avec la clé publique dans un certificat particulier. À cette fin, ce standards ne prescrit pas de règles juridiques contraignantes ou de droits.

   Vu que les outils d'autorisation supplémentaires et de gestions d'attributs émergent, tels que les certificats d'attributs, il peut être approprié de limiter les attributs authentifiés qui sont inclus dans un certificat. Ces autres outils de gestion peuvent fournir des méthodes plus appropriés de transport de nombreux attributs authentifiés.

Communication et topologie

   Les utilisateurs de certificat vont opérer dans une grande variété d'environnements en respect de leur topologie de communication, spécialement les utilisateurs de messagerie électronique. Ce profile supporte les utilisateurs à faible bande passante, connectivité IP temps-réel, ou connexion à haute disponibilité. En plus, le profile permet la présence de firewall ou autre communication filtrée.

   Ce profil n'assume pas le déploiement d'un système d'annuaire X.500 ou LDAP. Le profile n'interdit pas leur utilisation; cependant, tout moyen de distribuer des certificats et CRL peut être utilisé.

Critère d'acceptabilité

   Le but d'une PKI est de répondre aux besoins de fonctions déterministes, d'identification automatisée, d'authentification, de contrôle d'accès, et d'autorisation. Le support pour cet services détermine les attributs contenus dans le certificat aussi bien que les information de contrôle auxiliaire dans le certificat tel que les données de stratégie et contraintes de chemin de certification.

Attentes des utilisateurs

   Les utilisateurs de PKI Internet sont des gens et des processus qui utilisent des clients logiciel et sont les sujets nommés dans les certificats. Ces utilisations incluent les lecteurs et rédacteurs de messages électroniques, les clients pour les navigateurs web, les serveurs web, et le gestionnaire de clé pour IPSec dans un routeur. Ce profile reconnaît les limitations des plate-formes que les utilisateurs utilisent et les limitations de la sophistication et de l'attention des utilisateurs eux-même. Cela se manifeste dans la responsabilité minimale de la configuration utilisateur (ex: les clé de CA de confiance, les règles), les contraintes d'utilisation des plate-formes explicites dans le certificat, les contraintes de chemin de certification qui protège l'utilisateur les actions malicieuses, et les applications qui automatise sensiblement les fonction de validation.

Attentes des administrateurs

   Comme avec les attentes des utilisateurs, le profile PKI de l'Internet est structuré pour supporter les individus qui opèrent généralement les CA. Fournir aux administrateurs des choix illimités augmente les chances qu'une erreur subtile d'administrateur de CA résulte en un large compromission. En outre, des choix illimités compliquent grandement le logiciel qui traite et valide les certificats crées par la CA.

Présentation de l'approche

   Ceci est une vue simplifiée du modèle architecturel assumé par les infrastructures à clé publique utilisant les spécification X.509 ( PKIX ). Les composants dans ce modèle sont:

end entity L'utilisateur de certificats PKI et/ou le système utilisateur final qui est le sujet d'un certificat.
CA Autorité de certification
RA Autorité d'enregistrement, ex. un système opérationnel pour lequel une CA délègue certaines fonctions de gestion.
CRL issuer Un système qui génère et signe les CRL
repository Un système ou une collection de systèmes distribués qui stockent les certificats et les CRL et sert de moyen de distribution aux end entity

   Les CA sont responsables de l'indication du statut de révocation des certificats qu'elles fournissent. Les informations de statut de révocation peuvent être fournis en utilisant OCSP, CRL, ou d'autres mécanismes. En général, quand les informations de statut de révocation sont fournis en utilisant les CRL, la CA est également le CRL issuer. Cependant, une CA peut déléguer cette responsabilité à une entité différente.

Noter qu'un Attribute Authority ( AA ) peut également choisir de déléguer la publication des CRL à un CRL issuer.
___+---+
___|_C_|_______________________+------------+
___|_e_|_‹--------------------›|_End_entity_|
___|_r_|_______Operational_____+------------+
___|_t_|_______transactions__________^
___|_i_|______and_management_________|__Management
___|_f_|_______transactions__________|__transactions________PKI
___|_i_|_____________________________|_____________________users
___|_c_|_____________________________v
___|_a_|_=======================__+--+------------+__==============
___|_t_|__________________________^_______________^
___|_e_|__________________________|_______________|_________PKI
___|___|__________________________v_______________|______management
___|_&_|_______________________+------+___________|_______entities
___|___|_‹---------------------|__RA__|‹----+_____|
___|_C_|__Publish_certificate__+------+_____|_____|
___|_R_|____________________________________|_____|
___|_L_|____________________________________|_____|
___|___|____________________________________v_____v
___|_R_|________________________________+------------+
___|_e_|_‹------------------------------|_____CA_____|
___|_p_|___Publish_certificate__________+------------+
___|_o_|___Publish_CRL_____________________^______^
___|_s_|___________________________________|______|__Management
___|_i_|________________+------------+_____|______|__transactions
___|_t_|_‹--------------|_CRL_Issuer_|‹----+______|
___|_o_|___Publish_CRL__+------------+____________v
___|_r_|______________________________________+------+
___|_y_|______________________________________|__CA__|
___+---+______________________________________+------+

Certificat X.509 Version 3

   Les utilisateurs d'une clé publique nécessitent la confidentialité de la clé privée associée qui est possédée par le bon sujet ( personne ou système ) avec laquelle un mécanisme de chiffrement ou de signature numérique sera utilisé. Cette confidentialité est obtenue via l'utilisation de certificats à clé publique, qui sont des structures de donnée qui lie des valeurs de clés publique à des sujets. La liaison est affirmée en ayant un CA de confiance qui signe numériquement chaque certificat. La CA peut baser cette affirmation sur les moyens techniques (ex: preuve de possession via un protocole de challenge/réponse), la présentation de la clé privée, ou sur une affirmation par le sujet. Un certificat a une durée de vie limitée, qui est indiquée dans son contenu signé. Parce que la signature du certificat et la du validité peuvent être vérifiés indépendamment par un client, les certificats peuvent être distribués via des communication et des systèmes serveurs non-sûres, et peuvent être mis en cache dans des stockages dans des systèmes non-sûres.

   l'ITU-T X.509 ou l'ISO/IEC 9594-8, qui a été publié en 1988 comme partie des recommandations des annuaires X.500, définis un format de certificat standard. Le format de certificat dans le standard 1988 est appelé le format version 1 (v1). Quand X.500 a été révisé en 1993, 2 champs ont été ajoutés, résultant en un format version 2 (v2).

   Les rfc PEM, publiés en 1993, incluent les spécifications pour une infrastructure à clé publique basés sur X.509 v1 (rfc 1422). L'expérience a montré que les déploiement rfc 1422 faits avec les formats v1 et v2 étaient défaillant dans de nombreux aspects. Plus important, de nombreux champs étaient nécessaires pour gérer les information que le concept et l'implémentation de PEM a démontré la nécessité. En réponse, l'ISO/IEC, l'ITU-T, et ANSI X9 on développés le format de certificat version 3 (v3). Il étend le format v2 en ajoutant les champs d'extension additionnels. Les types de champ d'extension particulier peuvent être spécifiés dans des standards ou peuvent être définis et enregistrés par une organisation ou une communauté. En Juin 1996, la standardisation du format de base v3 a été complété.

   L'ISO/IEC, l'ITU-T, et ANSI X9 ont également développés des extensions standard développés pour l'utilisation dans le champs d'extensions v3. Ces extensions peuvent transmettre des données telles des informations d'identification de sujet additionnels, des information d'attribut de clé, informations de stratégie, et de contraintes de chemin de certification.

   Cependant, les extensions standard e l'ISO/IEC, l'ITU-T, et de l'ANSI X9 étaient très générales dans leur utilisation. Pour développer des implémentations intéropérable des système X.509 v3 pour l'Internet, il est nécessaire de spécifier un profile pour utiliser les extensions X.509 v3 adaptés pour l'Internet. C'est un des objectifs de ce document pour spécifier un profile pour WWW, les messages électroniques, et les application IPSec. Les environnements avec les pré-requis additionnels peuvent construire par-dessus ce profil pour le remplacer.

Chemins de certification et confiance

   Un utilisateur d'un service de sécurité nécessitant la connaissance d'une clé publique, a besoin généralement d'obtenir et de valider un certificat contenant la clé publique requise. Si l'utilisateur de clé publique ne possède pas une copie fiable de la clé publique de la CA qui a signé le certificat, le nom de la CA et les information liées (tel que la période de validité, ou les contraintes de nom), alors il peut nécessiter un certificat additionnel pour obtenir la clé publique. En général, une chaîne de plusieurs certificats peuvent être nécessaires, comprenant un certificat du propriétaire de la clé publique ( l'entité finale) signée par une CA, et 0 ou plusieurs certificats de CA signés par d'autres CA. De telles chaînes, appelées chemin de certification, sont requis parce qu'un utilisateur de clé publique est seulement initialisé avec un nombre limité de clé publique de CA.

   Les CA peuvent être configurées de différentes manières pour que les utilisateurs de clé publique soient capable de trouver les chemins de certification. Pour PEM, la rfc 1422 définis une structure hiérarchique rigide de CA. Il y a 3 types d'autorité de certification PEM:

(a) Internet Policy Registration Authority (IPRA): cette autorité, qui opère sous les auspices de l'Internet Society, agit comme le niveau racine de la hiérarchie de certification PEM, au niveau 1. Il fournis des certificats uniquement pour le niveau suivant d'autorités, les PCA. Tous les chemins de certification commencent avec l'IPRA.
(b) Policy Certification Authorities (PCAs): les PCA sont au niveau 2 de la hiérarchie, chaque PCA est certifié par l'IPRA. Un PCA devrait établir et publier un état de sa stratégie, avec respect de certifier des utilisateurs ou des autorités de certification subordonnés. Des PCA distincts ont pour objectifs de satisfaire différents besoins utilisateurs. Par exemple, un PCA peut supporter les besoins de messages électroniques des organisations commerciales, et un autre PCA peut avoir une stratégie plus stricte conçue pour satisfaire les besoins légaux des signatures numériques.
(c) Les autorités de certification (CA): les CA sont au niveau 3 de la hiérarchie et peuvent également être à des niveaux inférieurs. Ceux de niveau 3 sont certifiés par les PCA. Les CA représentent, par exemple, des organisations particulières, les unités organisationelles particulières, ou des zones géographiques particulières.

   La rfc 1422 a en outre une règle de subordination de nom, qui nécessite qu'une CA peut seulement fournir des certificats pour des entités dont les noms sont subordonnés au nom de la CA elle-même, le trust associé avec un chemin de certification PEM est impliqueé par le nom du PCA. La règle de subordination de nom s'assure que les CA sous le PCA sont contraint sensiblement au jeu d'entité subordonnés qu'ils peuvent certifier. Les systèmes d'utilisateurs de certificat sont capable de vérifier mécaniquement que la règle de subordination de nom a été suivie.

   La rfc 1422 utilise le format de certificat X.509 v1. Les limitations de cette version impose de nombreuses restrictions structurelles pour associer clairement les information de stratégie ou restreindre l'utilité des certificats. Ces restrictions incluent:

(a) Un hiérarchie "top-down", avec tous les chemins de certifications commençant depuis IPRA
(b) Une règle de subordination de nom qui restreints les noms des sujets des CA
(c) L'utilisation du concept PCA, qui nécessite la connaissance de tous les PCA individuells pour construire la logique de vérification de la chaîne de certification.

   Avec X.509 v3, la plupart des pré-requis adressés par la rfc1422 peuvent être adressés en utilisant les extensions de certificats, sans avoir à restreindre les structures CA utilisées. En particulier, les extensions de certificat liées aux stratégies de certificat évitent les besoins de PCA et les extensions de contraintes évitent les besoins de règle de subordination de nom. En résultat, ce document supporte une architecture plus flexible, incluant:

(a) Les chemins de certification commencent avec une clé publique d'une CA dans le domaine de l'utilisateur, ou avec la clé publique de la racine d'une hiérarchie. Commencer avec la clé publique d'une CA dans le domaine de l'utilisateur a certains avantages. Dans certains environnements, le domaine local est le plus sûr.
(b) Les contraintes de nom peuvent être imposés via l'inclusion explicite d'une extension de contrainte de noms dans un certificat, mais n'est pas requis.
(c) Les extensions de stratégie et les mappages de stratégie remplacent le concept de PCA, qui permet un plus haut degré d'automatisation. L'application peut determiner si le chemin de certification est acceptable basé sur le contenu du certificat au lieu d'un connaissance à priori des PCA. Cela permet d'automatiser le traitement des chemins de certification.

   X.509 v3 inclus également une extension qui identifie le sujet d'un certificat comme étant une CA ou une entité finale, réduisant la dépendance sur les informations out-of-band démandé dans PEM.

   Cette spécification couvre 2 classes de certificats: les certificats CA et les certificats d'entité finale. Les certificats CA peuvent être divisés en 3 classes: cross-certificats, certificats auto-fournis et certificat auto-signés.

        Les Cross-certificats sont des certificats CA dans lequel le fournisseur et les sujets sont des entités différentes. Les Cross-certificats décrivent une relation de confiance entre les 2 CA.
        Les certificats auto-fournis sont des certificat CA dans lequel le fournisseur et le sujet sont la même entité. Les certificats auto-fournis sont générés pour supporter les changements dans la stratégie ou les opérations.
        Les certificats auto-signés sont des certificat auto-fournis où la signature numérique peut être vérifiée par la clé publique lié dans le certificat. Les certificats auto-signés sont utilisé pour transporter une clé publique à utiliser au début des chemins de certification.

   Les certificats d'entité finale sont fournis aux sujets qui ne sont pas autorisés à fournir de certificats.

Révocation

   Quand un certificat est fournis, il est prévu pour être utilisé pour toute sa période de validité. Cependant, diverses circonstances peuvent causer un certificat à devenir invalide avant l'expiration de la période de validité. De telles circonstances incluent le changement de nom, changement d'association entre le sujet et la CA (ex: un employé termine sont emploie avec une organisation ), et la compromission de la clé privée associée. Dans de telles circonstances, la CA doit révoquer le certificat.

   X.509 définis une méthode de révocation de certificat. Cette méthode implique que chaque CA fournis périodiquement une structure de données appelée une liste de statut de révocation. Une CRL est une liste horodatée identifiant les certification révoqués. qui est signée par une CA ou un fournisseur de CA et est librement accessible dans de dépôt publique. Chaque certificat révoqué est identifié dans une CRL par son numéro de série. Quand un système utilisant les certificats utilise un certificat ( par exemple pour vérifier la signature numérique d'un utilisateur ), ce système ne vérifie pas seulement la signature et la validité du certificat mais récupère également une CRL utilisable et récente et vérifie que le numéro de série n'est pas dans cette CRL

   La signification de "utilisable et récente" peut varier avec la stratégie locale, mais signifie généralement la plus récente CRL fournis. Une nouvelle CRL est fournie sur une base régulière. Une entrée est ajoutée à la CRL comme partie de la prochaine mise à jours suivant la notification de la révocation. Une entrée ne doit pas être supprimée de la CRL jusqu'à ce qu'elle apparaisse dans une dans une CRL régulière fournie au-delà de la période de validité du certificat.

   Un avantage de cette méthode de révocation est que les CRL peuvent être distribués exactement de la même manière que les certificats eux-mêmes, via des serveurs et des communications non-sûres.

   Une limitation de la méthode de révocation CRL, utilisant des communications et des serveurs non sûrs, et que la granularité de temps de révocation est limitée à la période d'émission de la CRL. Par exemple, si une révocation est reportée maintenant, cette révocation ne sera pas notifiée tant qu'une nouvelle CRL n'est pas générée.

   Comme avec le format de certificat X.509 v3, pour pouvoir faciliter l'interopérabilité des implémentation, le format de CRL v2 X.509 doit être profilé pour l'utilisation sur l'Internet. C'est un des objectifs de ce document. Cependant, ce profile ne nécessite pas l'émission des CRL. Les formats de message et les protocoles supportant les notification de révocation on-line sont définis dans d'autres spécifications PKIX. Les méthodes on-line de notification de révocation peuvent être applicables dans certains environnements comme une alternative à la CRL X.509. La vérification de révocation On-line peut significativement réduire la latence entre une révocation et la distribution de l'information. Une fois que la CA acceptes une révocation comme authentique et valide, toute requête au service on-line va refléter correctement l'information de révocation.

   Cependant, ces méthodes imposent de nouveaux pré-requis de sécurité: le validateur de certificat a besoin de faire confiance au service de validation on-line, alors que le dépôt n'a pas besoin de l'être.

Protocoles opérationnels

   Les protocoles opérationnels sont requis pour délivrer les certificats et les CRL ( ou les informations de statut ) aux système client qui utilisent les certificats. Des dispositions sont nécessaires pour divers moyens de délivrer des certificats et les CRL, incluant les procédures de distribution basées sur LDAP, HTTP, FTP, et X.500. Les protocoles opérationnels supportant ces fonctions sont définies dans d'autres spécification PKIX. Ces spécifications peuvent inclurent les définition de formats de message et des procédures pour supporter tous les environnements opérationnel, incluant les définitions et les référence aux types de contenu MIME appropriés.

Protocoles de gestion

   Les protocoles de gestion sont requis pour supporter les interactions on-line entre les utilisateurs de PKI et les entités de gestion. Par exemple, un protocole de gestion peut être utilisé entre une CA et un système client avec lequel une paire de clé est associée, ou entre 2 CA qui se cross-certifient entre-eux. Le jeu de fonctions qui nécessite potentiellement d'être supportés par les protocoles de gestion incluent:

(a) Enregistrement: c'est la procédure par laquelle un utilisateur se fait connaître à la CA ( directement, ou via un RA ), avec que la CA ne lui fournisse un ou plusieurs certificats.
(b) Initialisation: Avant qu'un système client puisse opérer de manière sécurisé, il est nécessaire d'installer les clés qui ont la relation appropriée avec les clés stockées ailleurs dans l'infrastructure. Par exemple, le client a besoin d'être initialisée de manière sécurisée avec la clé publique et d'autres informations des CA de confiance, pour être utilisées dans les validation de chemins de certification. De plus, un client a généralement besoin d'être initialisé avec ses propres paires de clés.
(c) Certification: C'est le processus dans lequel une CA fournie un certificat pour une clé publique de l'utilisateur, et retourne ce certificat au système client de l'utilisateur et/ou poste ce certificat dans un dépôt.
(d) Récupération de paire de clé: En option, les clés du client (ex: la clé privée de l'utilisateur ) peut être sauvegardée par une CA ou un système de sauvegarde de clé. Si un utilisateur a besoin de récupérer ces clés ( par exemple lors de la perte du mot de passe ou la perte de la clé ), un protocole d'échange on-line peut être nécessaire pour de telles récupérations.
(e) Mise à jours de paires de clé: toutes les paires de clé ont besoin d'être mises à jours régulièrement, par ex. remplacées avec une nouvelle paire de clé, et de nouveaux certificats fournis.
(f) Demandes de révocation: Une personne autorisée avertit une CA d'une situation anormale nécessitant la révocation d'un certificat.
(g) cross-certification: 2 CA échangent des informations utilisées pour établir une certification croisée. Un cross-certificat est un certificat fournis par une CA à une autre qui contient une clé de signature CA utilisée pour fournir des certificats.

   Noter que les protocoles on-line ne sont pas la seul manière d'implémenter les fonction ci-dessus. Pour toutes les fonctions, il y a des méthodes off-line pour accomplir de même résultat, et cette spécification ne mandate pas l'utilisation des protocoles on-line. Par exemple, quand des jetons hardware sont utilisés, beaucoup de fonctions peuvent être faites comme partie de la livraison du jeton physique. De plus, certaines fonctions ci-dessus peuvent être combinées dans un seul protocole d'échange. En particulier, les fonctions d'enregistrement, d'initialisation et de certification peuvent être combinés en un seul protocole d'échange.

   Les séries PKIX des spécifications définissent un jeu de formats de messages standard pour supporter les fonction ci-dessus. Les protocoles pour transporter ces messages dans différents environnement (ex: email, transfert de fichier, et www ) sont décris dans ces spécifications.

Profile de certificat et d'extensions de certificat

   Cette section présente un profile pour les certificats à clé publique qui favorisent l'interopérabilité et une PKI ré-utilisable. Cette section est basée sur le format de certificat X.509 v3 et les extensions de certificats standards définis dans X.509. Les document ISO/IEC et ITU-T utilisent la version 1997 de ASN.1; alors que ce document utilise la syntaxe ASN.1 1988, le certificat et les extensions standard encodés sont équivalents. Cette section définis également des extensions privées nécessaires pour supporter une PKI pour la communauté Internet.

   Les certificats peuvent être utilisés dans une grande variété d'applications et d'environnements couvrant un large spectre d'interopérabilité et de pré-requis opérationnel et d'assurance. Le but de ce document est d'établir une base commune pour des applications générique nécessitant une grande interopérabilité et des besoins spéciaux limités. En particulier, l'accent sera mis sur le support de l'utilisation des certificats X.509 v3 pour les messages électronique, IPSec, et les applications web.

Champs de certificat de base

La syntaxe de base des certificats X.509 v3 est comme suit. Pour le calcule de la signature, les données à signer sont encodés en utilisant DER. L'encodage DER ASN.1 est un système d'encodage de tag, longueur, et valeur pour chaque élément.
Certificate ::= SEQUENCE {
    tbsCertificate TBSCertificate,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING }
    
TBSCertificate ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    serialNumber CertificateSerialNumber,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
        -- Si présent, version doit être v2 ou v3.
    subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
        -- Si présent, version doit être v2 ou v3
    extensions [3] EXPLICIT Extensions OPTIONAL
        -- Si présent, version doit être v2 ou v3
}
    
    Version ::= INTEGER { v1(0), v2(1), v3(2) }
    
CertificateSerialNumber ::= INTEGER
    
Validity ::= SEQUENCE {
    notBefore Time,
    notAfter Time }
    
Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime }
    
UniqueIdentifier ::= BIT STRING
    
SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    subjectPublicKey BIT STRING }
    
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
    
Extension ::= SEQUENCE {
    extnID OBJECT IDENTIFIER,
    critical BOOLEAN DEFAULT FALSE,
    extnValue OCTET STRING
         -- contient l'encodé DER d'une valeur ASN.1 correspondant au type d'extension identifié par extnID
}

Champs de certificat

   Certificate est une séquence de 3 champs requis. Les champs sont décris en détail dans les section suivantes.

tbsCertificate Le champ contient les noms du sujet et du fournisseur, une clé publique associée avec le sujet, une période de validité, et d'autres informations associées. Les champs sont décris plus bas. tbsCertificate inclue généralement des extensions, qui sont décris plus bas également.
signatureAlgorithm Le champ signatureAlgorithm contient l'identifiant pour l'algorithme cryptographique utilisé par la CA pour signer ce certificat. les rfc 3279, rfc 4055, et rfc 4491 listent les algorithmes de signature supportés, mais d'autres algorithmes peuvent être également supportés.

Un identifiant d'algorithme est définis par la structure ASN.1 suivante:
AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER,
    parameters ANY DEFINED BY algorithm OPTIONAL }

   L'identifiant d'algorithme est utilisé pour identifier un algorithme cryptographique. L'identifiant d'objet identifie l'algorithme (tel que DSA avec SHA-1). Le contenu des paramètres optionnels varient en fonction de l'algorithme identifié. Ce champ doit contenir le même identifiant d'algorithme que le champ signature dans la séquence tbsCertificate.

signatureValue Le champ signatureValue contient une signature numérique calculée sur l'encodé DER ASN.1 de tbsCertificate, qui est utilisé en entrée de l'algorithme de la fonction de signature. Cette valeur de signature est encodée en chaîne de bits et inclus dans le champ signature. Les détails de ce processus sont spécifiés pour chaque algorithme listés dans les rfc3279, rfc4055, et rfc4491.

   En générant cette signature, une CA certifie la validité de l'information dans le champ tbsCertificate. En particulier, la CA certifie la liaison entre la clé publique et le sujet du certificat.

TBSCertificate

   La séquence TBSCertificate contient les informations associées avec le sujet du certificat et la CA qui l'a fournie. Tous TBSCertificate contient les noms du sujet et du fournisseur, une clé publique associée avec le sujet, une période de validité, un numéro de version, et un numéro de série; certains peuvent optionnellement contenir des champs d'identifiant unique. Le reste de cette section décris la syntaxe et les sémantiques de ces champs. Un TBSCertificate inclus généralement des extensions. Les extensions pour les PKI de l'Internet sont décris plus bas.

Version

   Ce champ décris la version du certificat encodé. Quand les extensions sont utilisée, comme prévu dans ce profile, la version doit être 3 (valeur 2). Si aucune extension n'est présente, mais qu'un UniqueIdentifier est présent, la version devrait être 2 (valeur 1); cependant, la version peut être 3. Si seul les champs de base sont présents, la version devrait être 1 ( la valeur est omise du certificat); cependant, la version peut être 2 ou 3.

   Les implémentations devraient être préparés à accepter n'importe quel numéro de version. Au minimum, les implémentations conformes doivent reconnaître la version 3. La génération de certificats version 2 n'est pas prévue pour les implémentations de ce profile.

Serial Number

   Le numéro de série doit être un entier positif assigné par la CA pour chaque certificat. Il doit être unique pour chaque certificat fournis par une CA donnée (ex: le nom du fournisseur et le numéro de série identifie un certificat de manière unique ). Les CA doivent forcer le serialNumber à être un entier non-négatif.

   Les numéros de série peuvent être prévus pour contenir des entiers long. Les utilisateurs de certificat doivent être capable de manipules des valeurs jusqu'à 20 octets. Les CA conformes ne doivent pas utiliser de valeur serialNumber supérieur à 20 octets.

   Note: les CA non-conforme peuvent fournir des certificats avec des numéro de série négatifs ou 0. Les utilisateurs de certificat devraient être préparés à manipuler de tels certificats.

Signature

   Ce champ contient l'identifiant d'algorithme pour l'algorithme utilisé par la CA pour signer le certificat. Ce champ doit contenir le même identifiant d'algorithme que le champ signatureAlgorithm dans la séquence Certificate. Le contenu du champ optionnel parameters varie en fonction de l'algorithme.

Issuer

Le champ issuer identifie l'entité qui a signé et fournis le certificat. Le champ issuer doit contenir un dn non-vide. Le champ issuer est définis comme nom de type X.501. Le nom est définis par les structures ASN.1 suivantes:
Name ::= CHOICE { -- un seul possible --
    rdnSequence RDNSequence }
    
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
    
RelativeDistinguishedName ::=
    SET SIZE (1..MAX) OF AttributeTypeAndValue
    
AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue }
    
AttributeType ::= OBJECT IDENTIFIER
    
AttributeValue ::= ANY -- DEFINED BY AttributeType
    
DirectoryString ::= CHOICE {
    teletexString TeletexString (SIZE (1..MAX)),
    printableString PrintableString (SIZE (1..MAX)),
    universalString UniversalString (SIZE (1..MAX)),
    utf8String UTF8String (SIZE (1..MAX)),
    bmpString BMPString (SIZE (1..MAX)) }

   Le nom décris un nom hiérarchique composé d'attributs, tel que le nom du pays, et les valeurs correspondantes, tel que US. Le type du composant AttributeValue est déterminé par le AttributeType; en général il sera un DirectoryString.

   Le type DirectoryString est définis comme choix de PrintableString, TeletexString, BMPString, UTF8String, et UniversalString. Les CA conformes à ce profile doivent utiliser l'encodage de DirectoryString soit PrintableString soit UTF8String, avec 2 exceptions. Quand les CA on précédemment fournis des certificats avec les champs issuer avec attributs encodés en utilisant TeletexString, BMPString, ou UniversalString, alors la CA peut continuer à utiliser ces encodages de DirectoryString pour préserver la compatibilité en arrière. Également, les nouvelles CA qui sont ajoutée à un domaine où des CA existantes fournissent des certificat avec les champs issuer avec des attribut utilisant TeletexString, BMPString, ou UniversalString peuvent encoder les attributs qu'ils partagent avec les CA existantes en utilisant les même encodages que les CA existantes.

   Comme mentionné plus haut, les dn sont composés d'attributs. Cette spécification ne restreint pas le jeu de type d'attribut qui peuvent apparaître dans le nom. Cependant, les implémentations conformes doivent être préparées à recevoir des certificats avec des noms de fournisseur contenant le jeu de type d'attributs définis ci-dessous. Cette spécification recommande le support pour des type d'attributs additionnels.

   Les jeux standard d'attributs ont été définis dans X.520. Les Implémentations de cette spécification doit être préparée à recevoir les types d'attribut standard suivant dans le noms de fournisseur et du sujet:

- country
- organization
- organizational unit
- distinguished name qualifier
- state or province name
- common name (ex: "Susan Housley")
- serial number

   En plus, les implémentations de cette spécification devraient être préparés à recevoir le type d'attributs standard suivant dans les noms de fournisseur et de sujet:

- locality
- title
- surname
- given name
- initials
- pseudonym
- generation qualifier (ex: "Jr.", "3rd", ou "IV")

   La syntaxe et les identifiant d'objets associés pour ces types d'attribut sont fournis dans les modules ASN.1 dans l'appendice A. En plus, les implémentations de cette spécification doivent être préparées à recevoir l'attribut domainComponent, comme définis dans la rfc4519. Le DNS founis un système de label de ressource hiérarchique. Cet attribut fournis un mécanisme pour les organisations qui souhaitent utiliser les DN en parallèle à leurs noms DNS. Ce n'est pas un remplacement pour le composant dNSName des extensions de nom alternative. Les implémentations ne sont pas obligés de convertir de tels noms en noms DNS. La syntaxe et OID associé pour cet type d'attribut sont fournis dans les modules ASN.1 dans l'appendice 1. Les règles pour l'encodage des noms de domaines internationalisés à utiliser avec le type d'attribut domainComponent sont spécifiés plus bas.

   Les utilisateurs de certificat doivent être préparés à traiter les champs issuer et subject pour effectuer un chaînage de nom pour la validation de chemin de certification. Le chaînage de noms est effectué en faisant correspondre le dn issuer dans un certificat avec le sujet dans un certificat CA. Les règles pour comparer les dn sont spécifiés plus loin dans ce document. Si les noms dans les champ issuer et subject dans un certificat correspond aux règles spécifiés plus bas, le certificat est auto-signé.

Validity

   La période de validité de certificat est un intervalle de temps durant lequel la CA garantie qu'elle va maintenir les informations sur le statut du certificat. Le champ est représenté comme séquence de 2 dates: la date à laquelle la période de validité commence (notBefore) et la date à laquelle la période de validité se termine (notAfter). Ces 2 dates peuvent être encodés en UTCTime ou GeneralizedTime.

   Les CA conformes à ce profile doivent toujours encoder les dates de validité de certificat jusqu'à l'année 2049 en UTCTime; les de date en 2050 ou ultérieur en GeneralizedTime. Les applications conformes doivent être capable de traiter les dates de validité qui sont encodés en UTCTime ou en GeneralizedTime.

   La période de validité pour un certificat est la période de temps depuis notBefore jusqu'à notAfter, inclus.

   Dans certaines situations, les périphériques donnent des certificats pour lesquels aucune date d'expiration correcte ne peut être assignée. Par exemple, un périphérique pourrait fournir un certificat qui lie son modèle et un numéro de série à sa clé publique; un tel certificat est prévu pour être utilisé pour toute la durée de vie du périphérique.

   Pour indiquer qu'un certificat n'a pas de date d'expiration, notAfter devrait être assigné à la valeur GeneralizedTime 99991231235959Z.

   Quand le fournisseur n'est pas capable de maintenir les informations de statut jusqu'à la date notAfter (incluant le cas où notAfter vaut 99991231235959Z), le fournisseur doit s'assurer qu'aucun chemin de certification valide n'existe pour le certificat après que la maintenance du statut d'information soit terminée. Cela peut être fait par l'expiration ou la révocation de tous les certificats CA contenant la clé publique utilisée pour vérifier la signature dans le certificat et d'arrêter d'utiliser la clé publique utilisée pour vérifier la signature dans le certificat.

UTCTime

   Le type de temps universelle UTCTime, est un type ASN.1 standard prévu pour représenter les dates et le temps. UTCTime spécifie l'année via 2 chiffres et le temps est spécifié avec une précision d'une minute ou une seconde. UTCTime inclus soit Z (pour Zulu, ou Greenwich Mean Time) ou un temps différentiel.

   Pour ce profile, les valeurs UTCTime doivent être exprimées en GMT ( Zulu ) et doivent inclurent les secondes ( YYMMDDHHMMSSZ ), même que le nombre de secondes est 0. Les systèmes conforme doivent interpréter le champ année comme suit:

- Si YY est supérieur ou égale à 50, l'année devrait être interprété comme 19YY.
- Si YY est inférieur à 50, l'année dervait être interprété comme 20YY.

GeneralizedTime

   Le type de temps généralisé, GeneralizedTime, est un type ASN.1 standard pour des représentation à précision variable du temps. Optionnellement, le champ GeneralizedTime peut inclure une représentation du temps différentiel entre GMT et la local.

   Pour ce profile, les valeurs GeneralizedTime doivent être exprimées en GMT (Zulu) et doivent inclure les secondes (YYYYMMDDHHMMSSZ), même si le nombre de secondes est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

Subject

   Le champ subject identifie l'entité associée avec la clé publique stockée dans le champ de clé publique. Le nom du sujet peut être placé dans le champ subject et/ou dans l'extension SubjectAltName. Si le sujet est une CA (ex: l'extension de contraintes de base et présent et la valeur de cA est TRUE), alors le champ subject doit être renseigné avec un dn non-vide corrspondant au contenu du champs issuer dans tous les certificats émis par la CA. Si le sujet est un fournisseur de CRL (ex: l'extension utilisation de clé est présent et la valeur de cRLSign est TRUE), alors le champ subject doit être populé avec un dn non-vide correspondant au contenu du champ issuer dans toutes les CRL émise par le fournisseur de CRL. Si les informations de nommage du sujet sont présent seulement dans l'extension subjectAltName ( ex: une clé liée seulement à une adresses email ou une URI), alors le sujet doit être une séquence vide et l'extension subjectAltName doit être critique.

   Quand il est non-vide, le champ subject doit contenir un dn X.500. Le dn doit être unique pour chaque entité sujet certifié par une CA comme définie dans le champ issuer. Une CA peut fournir plus d'un certificat avec le même dn à la même entité sujet.

   Le champ subject est définis comme nom de type X.501. Les pré-requis d'implémentation pour ce champ sont ceux définis pour le champ issuer. Les implémentations de cette spécification doivent être préparés à recevoir des noms de sujet contenant les types d'attributs requis pour le champ issuer. Les implémentations de cette spécification devraient être préparés à recevoir des noms de sujet contenant les types d'attributs recommandés pour le champ issuer. La syntaxe et les identifiant d'objet associés pour ces types d'attributs sont fournis dans les modules ASN.1 en appendice 1.

   Les implémentations de cette spécification peuvent utiliser les règles de comparaison pour traiter les types d'attributs non-familier (ex: pour le chaînage de noms) dont les valeurs d'attributs utilisent une des options d'encodage de DirectoryString. Les comparaisons binaires devraient être utilisées quand les type d'attribut non-familiers incluent des valeurs d'attribut avec des options d'encodage autre que ceux trouvés dans DirectoryString. Cela permet aux implémentations de traiter les certificats avec des attributs non-familier dans le sujet.

   En encodant des valeurs d'attribut de type DirectoryString, les CA conformes doivent utiliser PrintableString ou UTF8String, avec les exceptions suivant:

(a) Quand le sujet du certificat est une CA, le champ subject doit être encodé de la même manière que s'il est encodé dans le champ issuer dans tous les certificat qu'elle fournis. Donc, si la CA encode les attributs dans les champs issuer des certificat qu'elle fournis en utilisant TeletexString, BMPString, ou UniversalString, alors le champ subject des certificats fournis par cette CA doit utiliser le même encodage.
(b) Quand le sujet du certificat est un fournisseur de CRL, le champ subject doit être encodé de la même manière qu'il est encodé dans le champ issuer dans toutes les CRL fournies par le fournisseur de CRL.
(c) TeletexString, BMPString, et UniversalString sont inclus pour la compatibilité en arrière, et ne devraient pas être utilisés pour les certificats pour les nouveaux sujets. Cependant, ces types peuvent être utilisés dans les certificats où le nom a été précédemment établit, incluant les cas dans lequel un nouveau certificat est fournis à un nouveau sujet où les attributs à encoder ont été précédemment établis dans les certificats fournis à d'autres sujets. Les certificats utilisateur devraient être préparés à recevoir les certificats avec ces types.

   Les implémentations anciennes existent où une adresse de messagerie électronique est embarquée dans le sujet comme emailAddress (rfc2985). La valeur d'attribut pour emailAddress est de type IA5String pour permettre l'inclusion du caractère '@' qui ne fait pas partie du jeu de caractère PrintableString. Les valeurs de l'attribut emailAddress sont sont pas sensibles à la casse.

   Les implémentations conformes générant de nouveaux certificat avec des adresse email doivent utiliser le rfc822Name dans l'extension de nom alternative du sujet pour décrire de telles identités. L'inclusion simultanée de l'attribut emailAddress dans le sujet pour supporter les anciennes implémentations est dépréciée, mais permise.

Subject Public Key Info

   Ce champ est utilisé pour gérer la clé publique et identifier l'algorithme avec lequel la clé est utilisée (ex: RSA, DSA, ou DH). L'algorithme est identifié en utilisant la structure AlgorithmIdentifier. Les identifiant d'objet pour les algorithmes supportés et les méthodes pour l'encodage de la clé publique (clé publique et paramètres) sont spécifiés dans les rfc3279, rfc4055, et rfc4491.

Unique Identifiers

   Ces champs doivent seulement apparaître si la version est 2 ou 3. Les identifiant uniques du sujet et du fournisseur sont présent dans le certificat pour gérer la possibilité de réutiliser les noms du sujet et/ou fournisseur dans le temps. Ce profile recommande que les noms ne soient pas réutilisés pour différentes entités et que les certificats Internet n'utilisent pas les identifiant uniques. Les CA conformes à ce profile ne doivent pas générer de certificats avec des identifiants uniques. Les applications conformes à ce profile doivent être capable de lire les certificats qui incluent des identifiants uniques, mais il n'y a pas de pré-requis de traitement associés avec les identifiant uniques.

Extensions

   Ce champ doit seulement apparaître si la version est 3. Si présent, ce champ est une séquence d'une ou plusieurs extensions de certificat.

Extensions de certificat

   Les extension définies pour les certificats X.509 v3 fournissent une méthode pour associer des attributs additionnels avec les utilisateurs ou les clés publiques et pour gérer les relations entre les CA. Le format de certificat X.509 v3 permet également aux communautés de définir des extensions privées pour gérer l'unicité des informations de ces communautés. Chaque extension dans un certificat peut être soit critique soit non-critique. Un système utilisant les certificats doit rejeter le certificat s'il rencontre une extension critique qu'il ne reconnaît pas ou une extension critique qui contient des informations qu'il ne peut pas traiter. Une extension non-critique peut être ignorée si elle n'est pas reconnue, mais doit être traitée si elle est reconnue. Les section suivantes présentent les extensions recommandées utilisée avec les certificats Internet et les emplacements standards pour les informations.

   Les communautés peuvent choisir d'utiliser des extensions additionnels, cependant, la prudence doit être de mise en adoptant des extension critiques dans les certificats qui peuvent empêcher leur utilisation dans un contexte général.

   Chaque extension inclus un OID et une structure ASN.1. Quand une extension apparaît dans un certificat, l'OID apparaît comme champ extnID et l'a structure encodée DER ASN.1 est la valeur de la chaîne d'octets extnValue. Un certificat ne doit pas inclure plus d'une instance d'une extension particulière. Par exemple, un certificat peut contenir seulement une extension d'identifiant de clé d'autorité. Une extension inclus le booléen critical, avec une valeur par défaut à FALSE. Le texte pour chaque extension spécifie les valeurs acceptable pour le champ critical pour les CA conformes à ce profile.

   Les CA conformes doivent supporter les identifiant de clé, les contraintes de base, l'utilisation de clé, et les stratégie de certificat. Si les CA fournissent des certificats avec une séquence vide pour le champ sujet, la CA doit supporter l'extension de noms alternatifs du sujet. Le support pour les extensions restantes est optionnel. Les CA conformes peuvent supporter les extension qui ne sont pas identifiés dans cette spécification; les fournisseurs de certificats sont prévenus que marquer de telles extensions comme critique peut inhiber l'interopérabilité.

   Au minimum, les applications conformes à ce profile doivent reconnaître les extensions suivantes: utilisation de clé, stratégie de certificat, contraintes de base, contraintes de nom, contraintes de stratégie, utilisation de clé étendue, et inhibit anyPolicy. En plus, les applications conformes à ce profile devraient reconnaître les extensions d'identifiant de clé du sujet et de l'autorité, et les mappages de stratégie.

Extensions standard

Cette section identifie les extensions de certificat standard définis dans X.509 pour l'utilisation dans les PKI de l'Internet. Chaque extension est associée avec un OID définis dans X.509. Ces OID sont membres de id-ce arc, qui est définis:
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

Authority Key Identifier

   L'extension d'identifiant de clé de l'autorité fournis un moyen d'identifier la clé publique correspondant à la clé privée utilisée pour signer un certificat. Cette extension est utilisée où un fournisseur a plusieurs clé de signature (soit dû à plusieurs paires de clé concurrentes, soit à cause d'un changement de clé). L'identification peut être basée sur l'identifiant de clé ( le subject key identifier dans le certificat du fournisseur ) ou le nom du fournisseur et un numéro de série.

   Le champ keyIdentifier de l'extension authorityKeyIdentifier doit être inclus dans tous les certificats générés par les CA conformes pour faciliter la construction de chemin de certification. Il y a une exception: là où une CA distribue sa clé publique sous la forme d'un certificat auto-signé, l'identifiant de clé d'autorité peut être omise. La signature d'un certificat auto-signé est générée avec la clé privée associée avec la clé publique du sujet du certificat. Dans ce cas, le sujet et les identifiants de clé d'autorité seraient identiques, mais seul l'identifiant de clé du sujet est nécessaire pour construire le chemin de validation.

   La valeur du champ keyIdentifier devrait être dérivé de la clé publique utilisée pour vérifier la signature du certificat ou une méthode qui génère des valeurs uniques. 2 méthodes communes pour générer des identifiant de clé depuis une clé publique sont décris dans la section suivante. Là où un identifiant de clé n'a pas été précédemment établis, cette spécification recommande l'utilisation d'une de ces méthodes pour générer les keyIdentifiers ou l'utilisation de méthodes similaires qui utilisent un algorithme de hashage différent. Là où un identifiant de clé a été précédemment établis, la CA devrait utiliser l'identifiant établis précédemment.

Ce profile recommande le support pour la méthode d'identifiant de clé par tous les utilisateurs de certificat. Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
    
AuthorityKeyIdentifier ::= SEQUENCE {
    keyIdentifier [0] KeyIdentifier OPTIONAL,
    authorityCertIssuer [1] GeneralNames OPTIONAL,
    authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
    
KeyIdentifier ::= OCTET STRING

Subject Key Identifier

   L'extension d'identifiant de clé du sujet fournis un moyen d'identifier les certificats qui contiennent une clé publique particulière.

   Pour simplifier la construction de chemin de certification, cette extension doit apparaître dans tous certificats CA conformes, c'est à dire, tous les certificats incluant l'extension de contraintes de base où la valeur de cA est TRUE. Dans les certificats de CA conformes, la valeur de l'identifiant de clé du sujet doit être la valeur placée dans le champ d'identifiant de clé de l'extension de clé d'autorité des certificats fournis par le sujet de ce certificat. Les applications ne sont pas obligées de vérifier que les identifiants de clé correspondent en validant le chemin de certification.

   Pour les certificats de CA, les identifiants de clé du sujet devraient être dérivés de la clé publique ou une méthode qui génère des valeurs uniques. 2 méthodes communes pour générer des identifiant de clé depuis la clé publique sont:

(1) keyIdentifier est composé d'un hash SHA-1 160-bits de la valeur de la chaîne de bits subjectPublicKey (excluant le tag, longueur et le nombre de bits non-utilisé).
(2) keyIdentifier est composé d'un champ de type 4-bits avec la valeur 0100, suivis par au moins 60bits de hash SHA-1 de la valeur de la chaîne de bits subjectPublicKey (excluant le tag, longueur et le nombre de bits non-utilisé).

   D'autres méthodes pour générer des nombres uniques sont également acceptables.

   Pour un certificat d'entité finale, l'extension d'identifiant de clé du sujet fournis un moyen d'identifier les certificats contenant la clé publique particulière utilisée dans une application. Quand une entité finale a obtenu plusieurs certificats, spécialement depuis plusieurs CA, l'identifiant de clé du sujet fournis un moyen de rapidement identifier le jeu de certificats contenant une clé publique particulière. Pour assister les applications à identifier le bon certificat, cette extension devrait être incluse dans tous les certificats d'entité finale.

   Pour les certificats d'entité finale, les identifiants de clé du sujet devraient être dérivés de la clé publique. 2 méthodes communes pour générer des identifiants de clé depuis la clé publique sont identifiés ci-dessus.

   Quand un identifiant de clé n'a pas été établis précédemment, cette spécification recommande l'utilisation d'une de ces méthodes pour générer les keyIdentifiers ou utiliser une méthodes similaire qui utilise un algorithme de hash différent. Quand un identifiant de clé a été précédemment établis, la CA devrait utilise cet identifiant.

Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
    
SubjectKeyIdentifier ::= KeyIdentifier

Key Usage

   L'extension d'utilisation de clé définis le but (ex: le chiffrement, la signature, signature de certificat) de la clé contenue dans le certificat. La restriction d'utilisation peut être employée quand une clé qui pourrait être utilisée pour plus d'une opération doit être restreindre. Par exemple, quand une clé RSA devrait être utilisée seulement pour vérifier les signatures sur des objets autre que des certificats à clé publique et les CRL, les bits digitalSignature et/ou nonRepudiation devraient être mis. De même, quand une clé RSA devrait être utilisée seulement pour la gestion de clé, le bit keyEncipherment devrait être mis.

   Les CA conformes doivent inclure cette extension dans les certificats qui contiennent des clés publiques qui sont utilisée pour valider les signatures numériques dans d'autre certificats à clé publique ou des CRL. Quand il est présent, les CA conformes devraient marquer cette extension comme critique.


id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
    
KeyUsage ::= BIT STRING {
    digitalSignature (0),
    nonRepudiation (1), -- Les éditions récentes de X.509 ont renommé ce bis en contentCommitment
    keyEncipherment (2),
    dataEncipherment (3),
    keyAgreement (4),
    keyCertSign (5),
    cRLSign (6),
    encipherOnly (7),
    decipherOnly (8) }

digitalSignature est mis quand la clé publique du sujet est utilisée pour vérifier les signatures numériques, autre que les signature des certificats et des CRL, telles que celles utilisées dans les services d'authentification d'entité, services d'authentification de l'origine des données, et/ou services d'intégrité.
nonRepudiation est mis quand la clé publique du sujet est utilisée pour vérifier les signatures numérique, autre que les signatures des certificats et des CRL, utilisé pour fournir un service de non-répudiation qui protège contre l'entité signataire niant à tord certaines actions. Dans le cas de conflits ultérieurs, un tiers de confiance peut déterminer l'authenticité des données signées.
keyEncipherment est mis quand la clé publique du sujet est utilisée pour chiffrer des clés secrètes ou privée, par exemple, pour le transport de clé. Par exemple, ce bit devrait être mis quand une clé publique RSA est utilisée pour chiffrer une clé de déchiffrement de contenu symétrique ou une clé privée asymétrique.
dataEncipherment est mis quand la clé publique du sujet est utilisée pour chiffrer directement les donnée brutes de l'utilisateur sans l'utilisation de clé symétrique intermédiaire. Noter que l'utilisation de ce bit est extrêmement peu commun; la plupart des applications utilisent le transport de clé pour l'agrément de clé pour établir une clé symétrique.
keyAgreement est mis quand la clé publique est utilisée pour la gestion de clé. Par exemple, quand une clé Diffie-Hellman est utilisée pour la gestion de clé, alors ce bit est mis.
keyCertSign Est mis quand la clé publique est utilisée pour vérifier les signatures des certificats à clé publique. Si keyCertSign est mis, alors le bit cA dans l'extension de contrainte de base doit également être mis.
cRLSign est mis quand la clé publique est utilisée pour vérifier les signatures dans les listes de révocation de certificat.
encipherOnly la signification de ce bit est indéfinis en l'absence du bit keyAgreement. Quand ces 2 bits sont mis, la clé publique du sujet peut être utilisée seulement pour chiffrer les données en effectuant un agrément de clé.
decipherOnly la signification de ce bit est indéfinis en l'absence du bit keyAgreement. Quand ces 2 bits sont mis, la clé publique du sujet peut être utilisée seulement pour déchiffrer les données en effectuant un agrément de clé.

   Si l'extension keyUsage est présent, alors la clé publique du sujet ne doit pas être utilisée pour vérifier les signatures dans le certificats ou les CRL à moins que les bits correspondants ne soient mis. Si la clé publique du sujet est seulement utilisée pour vérifier les signatures dans les certificats et/ou les CRL, alors les bits digitalSignature et nonRepudiation ne devraient pas être mis. Cependant, digitalSignature et/ou nonRepudiation peuvent être mis en plus de keyCertSign et/ou cRLSign si la clé publique du sujet est utilisée pour vérifier les signatures dans les certificats et/ou les CRL et également dans d'autres objets.

   Combiner le bit nonRepudiation dans l'extension de certificat keyUsage avec d'autres bits d'utilisation de clé peut avoir des implications de sécurité en fonction du contexte dans lequel le certificat est utilisé. D'autres distinction entre digitalSignature et nonRepudiation peuvent être fournis dans des stratégies de certificat spécifiques.

   Ce profil ne restreins pas les combinaisons de bits qui peuvent être mis dans une extension keyUsage. Cependant, des valeurs appropriées pour keyUsage pour des algorithmes particuliers sont spécifiés dans les rfc3279, rfc4055, et rfc4491. Quand l'extension keyUsage apparaît dans un certificat, au moins un bit doit être mis.

Certificate Policies

   L'extension de stratégie de certificat contient une séquence d'un ou plusieurs termes d'informations de stratégie, chacun consistant d'un identifiant d'objet et d'un qualifiant optionnel. Les qualifiants optionnel, qui peuvent être présents, ne sont pas prévus pour changer la définition de la stratégie. Un OID de stratégie de certificat ne doit pas apparaître plus d'une fois dans une extension de stratégie de certificat.

   Dans un certificat d'entité finale, ces informations de stratégie indique la stratégie sous laquelle le certificat a été émis et le but pour lequel le certificat peut être utilisé. Dans un certificat CA, ces stratégies limitent le jeu de stratégie pour les chemins de certification qui incluent ce certificat. Quand une CA ne souhaite pas limiter le jeu de stratégies pour les chemins de certification qui incluent ce certificat, elle peut indiquer une stratégie spéciale anyPolicy, qui a la valeur { 2 5 29 32 0 }.

   Les applications avec des besoins de stratégie spécifiques sont censés avoir une liste de ces stratégies qu'elles vont accepter et pour comparer les OID de stratégie dans le certificat à cette liste. Si cette extension est critique, le logiciel de validation de chemin doit être capable d'interpréter cette extension (incluant le qualifiant optionnel), ou doivent rejeter le certificat.

   Pour promouvoir l'interopérabilité, ce profile recommande que les termes d'informations de stratégie consistent de seulement un OID. Quand un OID seul n'est pas suffisant, ce profile recommande fortement que l'utilisation des qualifiants soient limités à ceux identifiés dans cette section. Quand les qualifiants sont utilisé avec le stratégie spéciale anyPolicy, ils doivent être limités aux qualifiants identifés dans cette section. Seul ces qualifiants retournés en résultat de la validation de chemin sont considérés.

   Cette spécification définis 2 types de qualifiants de stratégie à utiliser avec les concepteurs de stratégie de certificat. Les types de qualifiants sont le CPS Pointer et User Notice.

   Le CPS Pointer contient un pointer vers un Certification Practice Statement ( CPS ) publié par la CA. Le pointeur est sous la forme d'un URI. Les pré-requis de traitement pour ce qualifiant sont définis localement. Aucune action n'est mandatée par cette spécification sans regarder la criticité de cette extension.

   User notice est prévu pour afficher un tier de confiance quand un certificat est utilisé. Seuls les consignes utilisateurs retournés en résultat de la validation de chemin sont prévus pour l'affichage à l'utilisateur. Si une consigne est dupliqué, seul une copie est affichée. Pour empêcher une telle duplication, ce qualifiant devrait seulement être présent dans les certificats d'entité finaux et les certificats de CA fournis à d'autres organisations.

   La consigne utilisateur a 2 champs optionnels: noticeRef et explicitText. Les CA conformes ne devraient pas utiliser l'option noticeRef.

   Le champ noticeRef, si utilisé, nomme une organisation et identifie, par un nombre, une déclaration textuelle particulière préparée par cette organisation. Par exemple, il peut identifier l'organisation "CertsRUs" et un numéro de consigne 1. Dans une implémentation typique, l'application aura un fichier de consigne contenant le jeu de textes dans un fichier et l'affichera. Les messages peuvent être multi-langue.

   Le champ explicitText inclus la déclaration textuel directement dans le certificat. Ce champ est une chaîne avec un maximum de 200 caractères. Les CA conformes devraient utiliser l'encodage UTF8String, mais peuvent utiliser IA5String. Les CA conformes ne doivent pas encoder explicitText en VisibleString ou BMPString. La chaîne explicitText ne devrait pas inclure de caractères de contrôle. Encodé en UTF8String, toutes les séquences de caractère devraient être normalisés en accord avec Unicode Normalization form C (NFC).

   Si les 2 options sont inclues dans un qualifiant et si l'application peut localiser le texte indiqué par noticeRef, alors ce texte devrait être affiché; sinon, la chaîne explicitText devrait être affichée.

   Note: bien que explicitText a une taille maximum de 200 caractères, certaines CA non-conformes dépassent cette limite. Cependant, les utilisateurs de certificat devrait gérer ce champ avec plus de 200 caractères.


id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
    
    anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
    
    certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
    
    PolicyInformation ::= SEQUENCE {
        policyIdentifier CertPolicyId,
        policyQualifiers SEQUENCE SIZE (1..MAX) OF
         PolicyQualifierInfo OPTIONAL }
    
    CertPolicyId ::= OBJECT IDENTIFIER
    
    PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId PolicyQualifierId,
        qualifier ANY DEFINED BY policyQualifierId }
    
    -- policyQualifierIds for Internet policy qualifiers
    
    id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
    id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
    id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
    
    PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
    
    Qualifier ::= CHOICE {
        cPSuri CPSuri,
        userNotice UserNotice }
    
    CPSuri ::= IA5String
    
    UserNotice ::= SEQUENCE {
        noticeRef NoticeReference OPTIONAL,
        explicitText DisplayText OPTIONAL }
    
    NoticeReference ::= SEQUENCE {
        organization DisplayText,
        noticeNumbers SEQUENCE OF INTEGER }
    
    DisplayText ::= CHOICE {
        ia5String IA5String (SIZE (1..200)),
        visibleString VisibleString (SIZE (1..200)),
        bmpString BMPString (SIZE (1..200)),
        utf8String UTF8String (SIZE (1..200)) }

Policy Mappings

   Cette extension est utilisée dans les certificats CA. Elle liste une ou plusieurs paires d'OID; chacune incluant un issuerDomainPolicy et un subjectDomainPolicy. Le jumelage indique que la CA émettrice considère son issuerDomainPolicy équivalent au subjectDomainPolicy de la CA.

   Les utilisateurs de la CA émettrice peuvent accepter un issuerDomainPolicy pour certaines applications. Le mappage de stratégie définie la liste des stratégies associées avec le sujet CA qui peuvent être acceptés comme comparable à issuerDomainPolicy.

   Chaque issuerDomainPolicy nommé dans l'extension de mappage de stratégies devrait également être mis dans une extension de stratégie de certificat dans le même certificat. Les stratégies ne doivent pas être mappés soit pour ou depuis la valeur spéciale anyPolicy.

   En général, les stratégies de certificat qui apparaissent dans le champ issuerDomainPolicy de l'extension de mappage de stratégie ne sont pas considérées comme stratégie acceptable pour l'inclusion dans le certificats sous-jacents dans le chemin de certification. Dans certaines circonstances, une CA peut souhaiter mapper une stratégie (p1) à une autre (p2), mais veut que le issuerDomainPolicy (p1) soit considéré comme acceptable pour l'ajout dans les certificat sous-jacents. Cela peut se produire, par exemple, si la CA est dans le processus de transition d'e l'utilisation de la stratégie p1 vers l'utilisation de la stratégie p2 et a des certificats valides qui ont été émis sous chaque stratégie. Une CA peut indiquer cela en incluant 2 mappage de stratégie dans les certificats CA qu'elle fournis. Chaque mappage de stratégie aura un issuerDomainPolicy de p1; un mappage de stratégie aura subjectDomainPolicy de p1 et l'autre aura le subjectDomainPolicy de p2.

Cette extension peut être supportée par les CA et/ou les applications. Les CA conformes devraient marquer cette extension comme critique.
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
    
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    issuerDomainPolicy CertPolicyId,
    subjectDomainPolicy CertPolicyId }

Subject Alternative Name

   L'extension subject alternative name permet aux identités d'être liées au sujet du certificat. Ces identités peuvent être inclues en plus ou à la place e l'identité dans le champ subject du certificat. Les options définies incluent une adresse de messagerie électronique, un nom DNS, une adresse IP, et une URI. D'autres options existent, incluant les définitions complètement locales. Plusieurs formes de nom, et plusieurs instances de chaque forme de nom peuvent être inclus. Quand de telles identités sont liées dans un certificat, l'extension subject alternative name (ou issuer alternative name) doit être utilisée; cependant, un nom DNS peut également être représenté dans le champ subject en utilisant l'attribut domainComponent. Noter que quand de tels noms sont représentés dans le champ subject, les implémentation ne sont pas obligées de les convertir en noms DNS.

   Puisque le nom alternatif du sujet est considéré comme lié définitivement à la clé publique, toutes les parties doivent être vérifiés par la CA.

   De plus, si la seul identité du sujet inclue dans le certificat est une forme de nom alternative, alors le nom distinct du sujet doit être vide, et l'extension subjectAltName doit être présent. Si le champ subject contient une séquence vide, alors la CA émettrice doit inclure une extension subjectAltName marquée comme critique. En incluant l'extension subjectAltName dans un certificat qui a un sujet non-vide, les CA conformes devraient marque l'extension subjectAltName comme non-critique.

   Quand l'extension subjectAltName contient une adresse email, cette adresse doit être stockée dans le rfc822Name. Le format d'un rfc822Name est un Mailbox comme définis dans la rfc 2821. Une Mailbox a la forme "local-part@Domain". Noter qu'une Mailbox n'a pas de phrase (cet un nom commun) avant lui, et n'est pas entouré de "‹" et "›". Les règles d'encodage des adresses email qui incluent des noms de domaines internationalisés sont spécifiés plus bas.

   Quand l'extension subjectAltName contient une iPAdress, l'adresse doit être stockée dans la chaîne d'octets dans "network byte order", comme spécifié dans la rfc791. Le LSB de chaque octet est le LSB de l'octet correspondant dans l'adresse réseau. Pour les IPv4, comme spécifié dans la rfc791, la chaîne d'octets doit contenir exactement 4 octets. Pour la version IPv6, comme spécifié dans la rfc2460, la chaîne d'octets doit contenir exactement 16 octets.

   Quand l'extension subjectAltName contient un nom de domaine, le nom de domaine doit être stocké dans le dNSName ( un IA5String ). Le nom doit être en "preferred name syntax", comme spécifié dans la rfc1034 et modifié dans la rfc1123. Noter que bien que les lettres majuscules et minuscules sont permises dans les noms de domaines, la casse n'est pas prise en compte. En plus, alors que la chaîne " " est un nom de domaine légal, les extensions subjectAltName avec un dNSName de " " ne doivent pas être utilisé. Finalement, l'utilisation de la représentation DNS pour les adresses mail ne doivent pas être utilisées, de telles identités sont encodées en rfc822Name. Les règles pour l'encodage des noms de domaine internationalisés sont spécifiés plus bas.

   Quand l'extension subjectAltName contient une URI, le nom doit être stocké dans un uniformResourceIdentifier (un IA5String). Le nom ne doit pas être une URI relative, et doit suivre la syntaxe URI et les règles d'encodage spécifiés dans la rfc3986. Le nom doit inclure à la fois un schéma (ex: http ou ftp) et une partie spécifique au schéma. Les URI qui incluent une autorité doivent inclure un nom pleinement qualifié ou une adresse IP comme hôte. Les règles pour l'encodage des Internationalized Resource Identifiers (IRI) sont spécifiées plus bas.

   Comme spécifié dans la rfc3986, le schema n'est pas sensible à la casse ( ex: http est équivalent à HTTP ). La partie hôte, si présent, est également insensible à la casse, mais les autres composant de la partie spécifique au schéma peut être sensible à la casse. Les règles pour comparer les URI sont spécifiées plus bas.

   Quand l'extension subjectAltName contient un DN dans le directoryName, les règles d'encodage sont les mêmes qui ceux spécifiés pour le champ issuer. Le DN doit être unique pour chaque entité sujet certifiée par une CA comme définie par le champ issuer. Une CA peut émettre plus d'un certificat vec le même DN au même sujet.

   Le subjectAltName peut gérer des types de noms additionnel via l'utilisation du champ otherName. Le format et les sémantiques de nom sont indiqués via l'identifiant d'objet dans le champ type-id. Le nom lui-même est acheminé comme valeur de champ dans otherName. Par exemple un OID de nom principal Kerberos peut être encodé comme séquence du Realm et du PrincipalName.

   Les noms alternatifs du sujet peuvent être contraints de la même manière que les noms distinct du sujet en utilisant une extension de contrainte de nom.

   Si l'extension subjectAltName est présent, la séquence doit contenir au moins une entrée. À la différence du champ subject, les CA conformes ne doivent pas fournir de certificats avec un subjectAltName contenant des champs GeneralName vides. Par exemple, un rfc822Name est représenté en IA5String. Alors qu'une chaîne vide est un IA5String valide, un tel rfc822Name n'est pas permis par ce profile. Le comportement des client qui rencontrent un tel certificat en traitant un chemin de certification n'est pas définis par ce profile.

   Finalement, les sémantiques des noms alternatifs du sujet qui incluent des caractères wilcards ne sont pas adressés par cette spécification. Les applications avec des requis spécifiques peuvent utiliser de tels noms, mais elles doivent définir les sémantiques.


id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
    
SubjectAltName ::= GeneralNames
    
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
    
GeneralName ::= CHOICE {
    otherName [0] OtherName,
    rfc822Name [1] IA5String,
    dNSName [2] IA5String,
    x400Address [3] ORAddress,
    directoryName [4] Name,
    ediPartyName [5] EDIPartyName,
    uniformResourceIdentifier [6] IA5String,
    iPAddress [7] OCTET STRING,
    registeredID [8] OBJECT IDENTIFIER }
    
OtherName ::= SEQUENCE {
    type-id OBJECT IDENTIFIER,
    value [0] EXPLICIT ANY DEFINED BY type-id }
    
EDIPartyName ::= SEQUENCE {
    nameAssigner [0] DirectoryString OPTIONAL,
    partyName [1] DirectoryString }

Issuer Alternative Name

Comme pour la section précédente, cette extension est utilisée pour associer des identité de style Internet avec des fournisseurs de certificats. Le nom alternatif du fournisseur doit être encodé comme dans la section précédente. Les noms alternatifs du fournisseur ne sont pas traités comme partie de l'algorithme de validation de chemin de certification. ( ils ne sont pas utilisé dans le chaînage et les contraintes de noms ne sont pas forcées ). Quand présent, les CA conformes devraient marquer cette extension non-critique.
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
    
IssuerAltName ::= GeneralNames

Subject Directory Attributes

L'extension d'attributs d'annuaires du sujet est utilisée pour transmettre des attributs d'identification (ex: nationalité) du sujet. L'extension est définie comme une séquence d'un ou plusieurs attributs. Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
    
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Basic Constraints

   L'extension de contraintes de base identifie si le sujet du certificat est une CA et la profondeur maximale des chemins de certification valides qui incluent ce certificat.

   Le booléen cA indique si la clé publique certifiée peut être utilisée pour vérifier le signatures de certificat. Si le booléen cA n'est pas présent, alors le bit keyCertSign de l'extension d'utilisation de clé ne doit pas être présent. Si l'extension de contraintes de base n'est pas présent dans un certificat v3, ou l'extension est présent mais le booléen cA n'est pas mis, alors la clé publique certifiée ne doit pas être utilisée pour vérifier les signatures de certificat.

   Le champ pathLenConstraint a une signification seulement si cA est mis et l'extension d'utilisation de clé, si présent, à le bit keyCertSign mis. Dans ce cas, il donne le nombre maximum de certificats intermédiaires non auto-fournis qui peuvent suivre ce certificat dans le chemin de certification. ( Note: le dernier certificat dans le chemin de certification n'est pas un certificat intermédiaire, et n'est pas inclus dans cette limite. Généralement, le dernier certificat est un certificat d'entité finale, mais peut être un certificat de CA). Un pathLenConstraint de 0 indique qu'aucun certificat de CA intermédiaire non auto-fournis ne peut suivre dans un chemin de certification valide. Quand il apparaît, le champ pathLenConstraint doit être supérieur ou égal à 0. Quand pathLenConstraint n'apparaît pas, aucune limite n'est imposée.

   Les CA conformes doivent inclure cette extension dans tous les certificats CA qui contiennent une clé publique utilisée pour valider les signatures numérique dans les certificat et doivent marquer cette extension comme critique. Cette extension peut apparaître comme critique ou non dans les certificats CA qui contiennent des clés publiques utilisée exclusivement pour d'autres but que la validation des signatures numérique dans les certificats. De tels certificats de CA incluent ceux qui contiennent des clé publique utilisées exclusivement pour valider les signatures numérique dans les CRL et ceux qui contiennent des clés publique de gestion de clé utilisées avec les protocoles d'inscription de certificat.

Les CA ne doivent pas inclure le champ pathLenConstraint sauf si le booléen cA est mis et que l'extension d'utilisation ed clé a le bit keyCertSign mis.
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
    
BasicConstraints ::= SEQUENCE {
    cA BOOLEAN DEFAULT FALSE,
    pathLenConstraint INTEGER (0..MAX) OPTIONAL }

Name Constraints

   L'extension de contrainte de noms, qui doit être utilisé seulement dans un certificat de CA, indique un espace de noms dans lequel tous les noms de sujet dans les certificats sous-jacent dans un chemin de certification doivent être localisés. Les restrictions d'appliquent aux dn du sujet et aux noms alternatifs du sujet. Les restrictions s'appliquent seulement quand la forme de nom spécifié est présente. Si aucun nom du type n'est dans le certificat, le certificat est acceptable.

   Les contraintes de nom ne sont pas appliquées aux certificats auto-fournis ( à moins que le certificat est un certificat final dans le chemin ). ( Cela peut empêcher les CA qui utilisent les contraintes de noms d'employer des certificats auto-fournis pour implémenter du remplacement de clé).

   Les restrictions sont définies en termes de subtrees de noms permis ou exclus. Tout nom correspondant à une restriction dans le champ excludedSubtrees est invalide sans regarder les informations apparaîssant dans permittedSubtrees. les CA conformes doivent marquer cette extension comme critique et ne devraient pas imposer de contraintes de nom sur les formes de noms x400Address, ediPartyName, ou registeredID. Les CA conformes ne doivent pas fournir de certificats où les contraintes de nom est une séquence vide, le champ permittedSubtrees ou excludedSubtrees doit être présent.

   Les applications conformes à ce profile doivent être capable de traiter les contraintes de noms qui sont imposées dans le forme de nom directoryName et devraient être capable de traiter les contraintes de nom qui sont imposées dans les formes de nom rfc822Name, uniformResourceIdentifier, dNSName, et iPAddress. Si une extension de contraintes de nom qui est marqué critique impose des contraintes sur une forme de nom particulier, et une instance de cette forme de nom apparaît dans le champ subject ou dans l'extension subjectAltName. d'un certificat sous-jacent, alors l'application doit traiter la contrainte ou rejeter le certificat.

   Dans ce profile, les champs minimum et maximum ne sont pas utilisé pour les formes de nom, donc, le minimum doit être 0, et maximum doit être absent. Cependant, si une application rencontre une extension de contraintes de noms critique qui spécifie d'autres valeurs pour minimum et maximum pour une forme de nom qui apparaît dans un certificat sous-jacent, l'application doit traiter ces champs ou rejeter le certificat.

   Pour les URI, la contrainte s'applique à la partie hôte du nom. La contrainte doit être spécifiée en fqdn et peut spécifier un hôte ou un domaine. Quand la contrainte commance avec un point, elle peut être étendue avec un ou plusieurs labels. Par exemple, ".example.com" est satisfait par host.example.com, et my.host.example.com. Cependant, la contrainte .example.con n'est pas satisfait par example.com. Quand la contrainte ne commence pas avec un point, elle spécifie un hôte. Si une contrainte est appliquée à une forme de nom URI et qu'un certificat sous-jacent inclue une extension subjectAltName avec une URI qui n'inclue pas un composant d'autorité avec un nom d'hôte spécifié en fqdn, alors l'application doit rejeter le certificat.

   Une contrainte de nom pour les adresses email de l'Internet peut spécifier une boîte mail particulière, toutes les adresses dans un hôte particulier, ou toutes les boîtes mail dans un domaine. Pour indiquer une boîte mail particulière, la contrainte est l'adresse mail complète. Pour indiquer toutes les adresses mail dans un hôte particulier, la contrainte est spécifiée comme nom d'hôte. Pour spécifier toutes les adresse mail dans un domaine, la contrainte est spécifiée avec un point, comme avec une URI ( .example.com indique toutes les adresse mail du domaine example.com, mail pas les adresses internet de l'hôte example.com ).

   Les restrictions des noms DNS sont exprimées en host.example.com. Tous nom DNS qui peut être construit en ajoutant simplement 0 ou plusieurs labels à la partie gauche du nom satisfont la contrainte de nom. Par exemple, www.host.example.com satisfait la contrainte mais pas host1.example.com.

   Les anciennes implémentations existent où une adresse mail est embarquée dans le sujet dans une attribut de type emailAddress. Quand les contraintes sont imposée sur la forme de nom rfc822Name, mais que le certificat n'inclut pas une extension subjecAltName, la contrainte rfc822Name doit être appliquée à l'attribut de type emailAdress dans le sujet. La syntaxe ASN.1 pour emailAddress et l'OID correspondant sont fournis en appendix A.

   Les restrictions de la forme directoryName doivent être appliqués au champ subject dans le certificat ( quand le certificat inclus un champ de sujet non-vide ). et à tous noms de type directoryName dans l'extension subjectAltName. Les restrictions de la form x400Address doivent être appliquées à tous les noms de type x400Address dans l'extension subjectAltName.

   La syntaxe de iPAddress doit être comme décris précédemment avec les ajouts suivant spécifiquement pour les contraintes de noms. Pour les adresses IPv4, le champ IPv4 de GeneralName doit contenir 8 cotets, encodés dans le style rfc4632 (CIDR) opur représenter une plage d'adresses. Pour les adresses IPv6, le champ iPAddress doit contenir 32 octets encodés similairement. Par exemple, une contrainte de nom un sous-réseaux de classe C 192.0.2.0 est représenté pas les octets C0 00 02 00 FF FF FF 00, représentant la notation CIDR 192.0.2.0/24.

   Des règles additionnelles pour l'encodage et le traitement des contraintes de noms sont spécifiées plus bas. La syntaxe et les sémantiques pour les contraintes de noms pour otherName, ediPartyName, et registeredID ne sont pas définies par cette spécification. Cependant, la syntaxe et les sémantiques pour les contraintes de nom pour d'autres formes de nom peuvent être spécifiés dans d'autres documents.


id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
    
NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees [1] GeneralSubtrees OPTIONAL }
    
    GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
    
GeneralSubtree ::= SEQUENCE {
    base GeneralName,
    minimum [0] BaseDistance DEFAULT 0,
    maximum [1] BaseDistance OPTIONAL }
    
BaseDistance ::= INTEGER (0..MAX)

Policy Constraints

   L'extension de contrainte de stratégie peut être utilisée dans les certificats fournis aux CA. Cette extension contraint la validation de chemin de 2 manières. Elle peut être utilisée pour interdire le mappage de stratégie ou nécessiter que chaque certificat dans le chemin contienne un identifiant de stratégie acceptable.

   Si le champ inhibitPolicyMapping est présent, la valeur indique le nombre de certificats additionnels qui peuvent apparaître dans le chemin avant que le mappage de stratégie ne soit plus permis. Par exemple, une valeur indique que le mappage de stratégie peut être traitée dans les certificats fournis par le sujet de ce certificat, mais pas dans les certificats additionnels dans le chemin.

   Si le champ requireExplicitPolicy est présent, sa valeur indique le nombre de certificats additionnels qui peuvent apparaître dans le chemin avant qu'une stratégie explicite soit requise pour tous le chemin. Quand une stratégie explicite est requise, il est nécessaire pour tous les certificats dans le chemin de contenir un identifiant de stratégie acceptable dans l'extension de stratégie de certificat. Un identifiant de stratégie acceptable est l'identifiant d'une stratégie requise par l'utilisateur du chemin de certification ou l'identifiant d'une stratégie qui a été déclarée équivalente via le mappage de stratégie.

   Les applications conformes doivent être capable de traiter le champ requireExplicitPolicy et devraient être capable de traiter le champ inhibitPolicyMapping. Les application qui supportent le champ inhibitPolicyMapping doivent également implémenter le support pour l'extension policyMappings. Si l'extension policyConstraints est marquée critique et que le champ inhibitPolicyMapping est présent, les applications qui n'implémentent pas le support pour inhibitPolicyMapping doivent rejeter le certificat.

   Les CA conformes ne doivent pas fournir de certificats où la contrainte de stratégie est une séquence vide. inhibitPolicyMapping ou requireExplicitPolicy doit être présent. Le comportement des clients qui rencontrent un champ de contrainte de stratégie vide n'est pas adressé dans ce document.

Les CA conformes doivent marquer cette extension critique.
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
    
PolicyConstraints ::= SEQUENCE {
    requireExplicitPolicy [0] SkipCerts OPTIONAL,
    inhibitPolicyMapping [1] SkipCerts OPTIONAL }
    
SkipCerts ::= INTEGER (0..MAX)

Extended Key Usage

Cette extension indique un ou plusieurs buts pour lequel la clé publique certifiées peut être utilisée, en plus ou à la place de l'extension d'utilisation de clé. En général, cette extension apparaît seulement dans les certificats d'entité finales. Cette extension est définie:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
    
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
    
KeyPurposeId ::= OBJECT IDENTIFIER

   Les identifiants d'objet utilisés pour identifier le but de clé doivent être assignés en accord avec les recommandations de l'IANA ou l'ITU-T X.660. Cette extension peut être critique ou non.

   Si l'extension est présente, alors le certificat doit seulement être utilisé pour un des buts indiqué. Si plusieurs buts sont indiqués l'application n'a pas besoin de reconnaître tous les buts indiqués, tant que le but prévus est présent. Les applications utilisant les certificats peuvent nécessiter que l'extension d'utilisation de clé soit présente et qu'un but particulier soit indiqué pour que le certificat soit accepté par l'application.

   Si une CA inclus les utilisations de clé pour satisfaire de telles applications, mais ne souhaite pas restreindre les utilisations de clé, la CA peut inclure le KeyPurposeId spécicial anyExtendedKeyUsage en plus des buts particuliers requis par les applications. Les CA conformes ne devraient pas maquer cette extension critique si anyExtendedKeyUsage est présent. Les applications qui nécessitent la présence d'un but particulier peuvent rejeter les certificats qui incluent anyExtendedKeyUsage mais par l'OID particulier attendus pour l'application.

   Si un certificat contient à la fois l'extension d'utilisation de clé et une extension d'utilisation de clé étendue, les 2 extensions doivent être traitées indépendamment et le certificat doit seulement être utilisé pour un but consistant avec les 2 extensions. S'il n'y a pas de but consistant avec les 2 extensions, alors le certificat ne doit pas être utilisé.

Les buts d'utilisation de clé suivants sont définis:
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
    
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
    
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
    -- Authentification serveur www TLS
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, keyEncipherment ou keyAgreement
    
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
    -- Authentification client www TLS
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, et/ou keyAgreement
    TLS WWW client authentication
    
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
    -- Signature de codes exécutables téléchargeables
    -- Utilisations de clé qui peuvent être consistant: digitalSignature
    
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
    -- Protection d'email
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, nonRepudiation, et/ou (keyEncipherment ou keyAgreement)
    
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
    -- Lier le hash d'un objet à une date
    -- Utilisations de clé qui peuvent être consistant: digitalSignature et/ou nonRepudiation
    
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
    -- Signature de réponses OCSP
    - Utilisations de clé qui peuvent être consistant: digitalSignature et/ou nonRepudiation

CRL Distribution Points

   L'extension de point de distribution de CRL identifie comment les informations de CRL sont obtenus. L'extension devrait être non-critique, mais ce profile recommande le support pour cette extension par les CA et les application.

   L'extension cRLDistributionPoints est une séquence de DistributionPoint. Un DistributionPoint consiste de 3 champs, chacun d'entre-eux est optionnels: distributionPoint, reasons, et cRLIssuer. Bien que chacun de ces champs est optionnel, un DistributionPoint ne doit pas consister du seul champ reasons; distributionPoint ou cRLIssuer doit être présent. Si le fournisseur de certificat n'est pas le fournisseur de CRL, alors le champ cRLIssuer doit être présent et contient le nom du fournisseur de CRL. Si le fournisseur de certificat est également le fournisseur de CRL, les CA conformes doivent omettre le champ cRLIssuer et doivent inclure le champ distributionPoint.

   Quand le champ distributionPoint est présent, il contient soit une séquence de noms ou une simple valeur, nameRelativeToCRLIssuer. Si le DistributionPointName contient plusieurs valeurs, chaque nom décris un mécanisme différent pour obtenir la même CRL. Par exemple, la même CRL pourrait être disponible via LDAP et HTTP.

   Si le champ distributionPoint contient un directoryName, l'entrée pour ce directoryName contient la CRL courante pour les raisons associées et la CRL est fournie par le cRLIssuer associé. La CRL peut être stockée dans soit certificateRevocationList ou authorityRevocationList. La CRL est obtenus par l'application en fonction de la configuration locale du serveur d'annuaire. Le protocole que l'application utilise pour accéder à l'annuaire et un choix local.

   Si DistributionPointName contient un nom général de type URI, les sémantiques suivante doivent être assumées: l'URI est un pointer vers la CRL courante pour les raisons associées et sera fournis par le cRLIssuer associé. Quand les schémas d'URI HTTP ou FTP sont utilisés, l'URI doit pointer vers une CRL simple encodé DER comme spécifié dans la rfc2585. Les implémentations de serveur HTTP accèdés via l'URI devraient spécifier le type de media application/pkix-crl dans le champ d'en-tête content-type de la réponse.

   Quand le schéma d'URI LDAP est utilisé, l'URI doit inclure un champ dn contenant le nom distinct de l'entrée maintenant la CRL, doit inclure un simple attrdesc qui contient une description d'attribut appropriée pour l'attribut qui maintient la CRL (rfc4523), et devrait inclur un hôte (ex: ‹ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?certificateRevocationList;binary›). Omettre l'hôte (ex: ‹ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary›) implique de s'appuyer sur la connaissance du client du serveur approprié. Quand présent, DistributionPointName devrait inclure au moins une URI LDAP ou HTTP.

   Si DistributionPointName contient un simple valeur nameRelativeToCRLIssuer, la valeur fournis un fragment de nom distinct. Le fragment est ajouté au nom distinct X.500 du fournisseur de CRL pour obtenir le nom du point de distribution. Si le champ cRLIssuer dans le DistributionPoint est présent, alors le fragment est ajouté au nom distinct qu'il contient, sinon le fragment est ajouté au nom distinct du fournisseur de certificat. Les CA conformes ne devraient pas utiliser nameRelativeToCRLIssuer pour spécifier les noms des points de distributions. Le DistributionPointName ne doit pas utiliser un nameRelativeToCRLIssuer relatif quand cRLIssuer contient plus d'un nom distinct.

   Si DistributionPoint omet le champ reasons, la CRL doit inclure des informations de révocation pour toutes les raisons. Ce profile recommande d'éviter la segmentation de CRL par code de raison. Quand une CA conforme inclus une extension cRLDistributionPoints dans un certificat, elle doit inclure au moins un DistributionPoint qui pointe vers une CRL qui couvre le certificat pour toutes les raisons.

   cRLIssuer identifie l'entité qui signe et fournis la CRL. Si présent, cRLIssuer doit seulement contenir le nom distinct du champ issuer de la CRL pointé par le DistributionPoint. L'encodage du nom dans le champ cRLIssuer doit être exactement le même que l'encodage dans le champ issuer de la CRL. Si le champ cRLIssuer est inclus et le dn dans ce champ ne correspond par à une entrée X.500 ou LDAP où la CRL est localisée, alors les CA conformes doivent inclure le champ distributionPoint.


id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
    
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
    
DistributionPoint ::= SEQUENCE {
    distributionPoint [0] DistributionPointName OPTIONAL,
    reasons [1] ReasonFlags OPTIONAL,
    cRLIssuer [2] GeneralNames OPTIONAL }
    
DistributionPointName ::= CHOICE {
    fullName [0] GeneralNames,
    nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
    
ReasonFlags ::= BIT STRING {
    unused (0),
    keyCompromise (1),
    cACompromise (2),
    affiliationChanged (3),
    superseded (4),
    cessationOfOperation (5),
    certificateHold (6),
    privilegeWithdrawn (7),
    aACompromise (8) }

Inhibit anyPolicy

   L'extension inhibit anyPolicy peut être utilisée dans les certificats fournis aux CA. Elle indique que l'OID spéciale anyPolicy { 2 5 29 32 0 }, n'est pas considérée comme une correspondance explicite pour les autres stratégies de certificat excepté quand elle apparaît dans un certificat CA auto-fournis intermédiaire. La valeur indique le nombre de certificats non auto-fournis additionnels qui peuvent apparaître dans le chemin avant que anyPolicy ne soit plus permis. Par exemple, une valeur de 1 indique que anyPolicy peut être traitée dans les certificats fournis par le sujet de ce certificat, mais pas dans les certificats additionnels dans le chemin.

Les CA conformes doivent marquer cette extension critique
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
    
InhibitAnyPolicy ::= SkipCerts
    
SkipCerts ::= INTEGER (0..MAX)

Freshest CRL

l'extension freshest CRL identifie comment les informations de CRL delta sont obtenus. Cette extension doit être marquée non critique. La même syntaxe est utilisée pour cette extension et l'extension cRLDistributionPoints. Les même conventions d'appliquent aux 2 extensions
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
    
FreshestCRL ::= CRLDistributionPoints

Extensions Internet privées

   Cette section définis 2 extensions à utiliser dans les infrastructures à clé publique de l'Internet. Ces extensions peuvent être utilisées pour diriger les applications vers des informations en ligne sur le fournisseur ou le sujet. Chaque extension contient une séquence de méthodes d'accès et d'emplacements d'accès. La méthode d'accès est un identifiant d'objet qui indique le type d'informations qui sont disponibles. L'emplacement d'accès est un GeneralName qui spécifie implicitement l'emplacement et le format des informations et la méthode pour obtenir ces informations.

Les identifiants d'objet sont définis pour les extensions privées. Les identifiants d'objet associés avec les extensions privées sont définies sous l'arc id-pe dans l'arc id-pkix. Toutes extensions futures définies pour la PKI Internet seront définis également sous cet arc id-pe.
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
    
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

Authority Information Access

   L'extension d'accès aux informations d'autorité indique comment accéder aux informations et services pour le fournisseur du certificat dans lequel l'extension apparaît. Les informations et services peuvent inclure des services de validation en ligne et les données de stratégie de CA. ( L'emplacement des CRL n'est pas spécifié dans cette extension). Cette extension peut être inclus dans les certificat d'entité finale ou de CA. Les CA conformes doivent marquer cette extension non-critique.


id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
    
AuthorityInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF AccessDescription
    
AccessDescription ::= SEQUENCE {
    accessMethod OBJECT IDENTIFIER,
    accessLocation GeneralName }
    
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
    
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
    
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   Chaque entrée dans la séquence AuthorityInfoAccessSyntax décris le format et l'emplacement d'informations additionnelles fournies par le fournisseur du certificat dans lequel cette extension apparaît. Le type et le format des informations sont spécifiées par le champ accessMethod; le champ accessLocation spécifie l'emplacement des informations. Le mécanisme de récupération peut être déduit par accessMethod ou spécifié par accessLocation.

   Ce profile définis 2 OID d'accessMethod: id-ad-caIssuers et id-ad-ocsp.

   Dans un certificat à clé publique, l'OID id-ad-caIssuers est utilisé quand les informations additionnelles listent les certificats qui ont été fournis à la CA qui a fournis le certificat contenant cette extension. La description de fournisseurs CA référencés est destiné à aider les utilisateurs de certificat dans la sélection d'un chemin de certification qui se termine au point validé par le certificat utilisateur.

   Quand id-ad-caIssuers apparaît comme accessMethod, le champ accessLocation décris le serveur de description référencé et le protocole d'accès pour obtenir la description référencée. Le champ accessLocation est définis en GeneralName, qui peut prendre de nombreuses formes.

   Quand accessLocation est un directoryName, l'information est obtenu par l'application en fonction du serveur d'annuaire configuré localement. L'entrée pour le directoryName contient les certificats CA dans les attributs crossCertificatePair et/ou cACertificat comme spécifié dans la rf4523. Le protocole que les applications utilisent pour accéder à l'annuaire est une décision locale.

   Quand l'information est disponible via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI LDAP doit inclure un champ dn contenant le dn de l'entrée maintenant les certificats, doit inclure un champ attribute qui maintient la liste des descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paire le cross-certificats, et devraient inclure un hôte ( ex ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary›). Omettre l'hôte (ex: ‹ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary›) implique que le client connaisse le serveur approprié à contacter.

   Quand les informations sont disponibles via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer sur soit un simple certificat encodé DER comme spécifié dans la rfc2585, ou une collection de certificats dans message CMS "certs-only" encodé DER ou BER, comme spécifié dans la rfc2797.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificats encodés DER individuels et devraient être capable d'accepter les message CMS "certs-only".

   Les implémentations serveur HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert (rfc2585) dans l'en-tête content-type de la réponse pour un simple certificat encodé DER et devrait spécifier le type de média application/pkcs7-mime (rfc2797) dans le champ d'en-tête content-type de la réponse pour les messages CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir le suffix ".cer" (rfc2585), et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir l'extension ".p7c" (rfc2797). Les clients peuvent utiliser le type de média ou l'extension de fichier, mais ne devraient pas dépendre uniquement de la présence du type de média ou de l'extension de fichier correcte dans la réponse du serveur.

   Les sémantiques pour d'autres formes de noms d'accessLocation id-ad-caIssuers ne sont pas définis.

   Une extension authorityInfoAccess peut inclure plusieurs instances de l'accessMethod id-ad-caIssuers. Les différentes instances peut spécifier différentes méthodes d'accès à la même information ou peut pointer vers différentes informations. Quant l'accessMethod id-ad-caIssuers est utilisé, au moins une instance devrait spécifier un accessLocation qui est une URI HTTP ou LDAP.

   L'OID id-ad-ocsp est utilisé quand les informations de révocation pour le certificat contenant cette extension est disponible en utilisant OCSP (rfc2560). Quand id-ad-ocsp apparaît comme accessMethod, le champ accessLocation est l'emplacement du répondeur OCSP, en utilisant les conventions spécifiées dans la rfc2560.

   Des descripteurs d'accès additionnels peuvent être définis dans d'autres spécification PKIX.

Subject Information Access

   L'extension d'accès aux informations du sujet indique comment accéder aux informations et services pour le sujet du certificat dans lequel l'extension apparaît. Quand le sujet est une CA, les informations et services peuvent inclure des services de validation de certificat et une donnée de stratégie CA. Quand le sujet est une entité finale, les informations décrivent le type de services offerts et comment y accéder. Dans ce cas, le contenu de cette extension est définis dans les spécifications du protocole pour les services supportés. Cette extension peut être inclue dans des certificats CA ou d'entité finale. Les CA conformes doivent marquer cette extension non-critique.


id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
    
SubjectInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF AccessDescription
    
AccessDescription ::= SEQUENCE {
    accessMethod OBJECT IDENTIFIER,
    accessLocation GeneralName }

   Chaque entrée dans la séquence SubjectInfoAccessSyntax décris le format et l'emplacement des informations additionnelles fournies par le sujet du certificat dans lequel cette extension apparaît. Le type et le format de l'information sont spécifiés par le champ accessMethod; le champ accessLocation spécifie l'emplacement de l'information. Le mécanisme de récupération peut être implicite via accessMethod ou accessLocation.

   Ce profile définis une méthode d'accès à utiliser quand le sujet est une CA et une méthode d'acces utilisée quand le sujet est une entité finale. Des méthodes d'accès additionnels peuvent être définis dans de futures spécification de protocole pour d'autres services.

   L'OID id-ad-caRepository est utilisé quand le sujet est une CA qui publie les certificat quelle fournis dans un annuaire. Le champ accessLocation est définis en GeneralName, qui peut prendre de nombreuses formes.

   Quand accessLocation est un directoryName, l'information est obtenue par l'application depuis le serveur d'annuaire configuré localement. Quand l'extension est utilisée pour pointer vers des certificats CA, l'entrée pour le directoryName contient les certificats CA dans les attributs crossCertificatePair et/ou cACertificat comme spécifiés dans la rfc4523. Le protocole que l'application utilise pour accéder à l'annuaire est un choix local.

   Quand les informations sont disponible via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI ldap doit inclure un champ dn contenant le dn de l'entrée maintenant les certificats, doit inclure un champ attribute qui liste les descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paires de cross-certificats, et devraient inclure un hôte. ( ex: ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary› ). Omettre l'hôte implique que le client connaît le serveur approprié à contacter.

   Quand l'information est disponible via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer soit vers un simple certificat encodé DER ou une collection de certificats dans un message CMS "certs-only" encodés DER ou BER.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificat encodés DER individuels et devraient être capable d'accepter les message CMS "certs-only".

   Les implémentations de serveur HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert (rfc2585) dans l'en-tête content-type de la réponse pour un simple certificat encodé DER et devrait spécifier le type de média application/pkcs7-mime (rfc2797) dans le champ d'en-tête content-type de la réponse pour les messages CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir le suffix ".cer" (rfc2585), et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir l'extension ".p7c" (rfc2797). Les clients peuvent utiliser le type de média ou l'extension de fichier, mais ne devraient pas dépendre uniquement de la présence du type de média ou de l'extension de fichier correcte dans la réponse du serveur.

   Les sémantiques pour d'autres formes de nom accessLocation id-ad-caRepository ne sont pas définies.

   Une extension subjectInfoAccess peut inclure plusieurs instances de accessMethod id-ad-caRepository. Les instances différentes peuvent spécifier des méthodes différentes pour accéder à la même information ou peuvent pointer vers différentes informations. Quand accessMethod id-ad-caRepository est utilisé, au moins une instance devrait spécifier un accessLocation qui est une URI HTTP ou LDAP.

   L'OID id-ad-timeStamping est utilisé quand le sujet offre des services de timestamping utilisant le TSP (rfc3161). Quand les services de timestamping sont disponibles via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier. Quand les services de timestamping sont disponibles via les messages électroniques, accessLocation doit être un rfc822Name. Quand les services de timestamping sont disponibles en utilisant TCP/IP, les formes de noms dNSName ou iPAddress peuvent être utilisés. Les sémantiques d'autres formes de nom de accessLocation (quand accessMethod est id-ad-timeStamping) ne sont pas définis par cette spécification.

Des descripteurs d'accès additionnels peuvent être définis dans d'autres spécifications PKIX.
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
    
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
    
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

Profile de CRL et d'extensions de CRL

   Comme discuté plus haut, un des but de ce profile de CRL X.509 v2 est de favoriser la création d'une ICP Internet interopérable et réutilisable. Pour cela, des lignes directrices pour l'utilisation des extensions sont spécifiée, et certaines hypothèses sont faites sur la nature des informations inclues dans la CRL.

   Les CRL peuvent être utilisée dans un grande variété d'applications et d'environnement couvrant un large spectre de pré-requis opérationnels et d'assurance. Ce profile établis une ligne de base commune pour les applications génériques nécessitant une grande interopérabilité. Ce profile définis un jeu d'informations qui peuvent être prévus dans toutes les CRL. Également, le profile définis des emplacements communs dans la CRL pour les attributs fréquemment utilisés et les représentations communes pour ces attributs.

   Les fournisseurs de CRL fournissent les CRL. Le fournisseur de CRL est soit la CA ou une entité qui a été autorisée par la CA pour fournir les CRL. Les CA publient les CRL pour fournir des informations de statut sur les certificats qu'elles émettent. Cependant, une CA peut déléguer cette responsabilité à une autre autorité de confiance.

   Chaque CRL a un périmètre particulier. Le scope de CRL est le jeu de certificats qui peuvent apparaître dans une CRL donnée. Par exemple, le scope pourrait être "tous les certificats émis par la CA X", "Tous les certificats de CA fournis par la CA X", "tous les certificats émis par la CA X qui ont été révoqués pour une raison de compromission de clé et de CA compromise", ou un jeu de certificats basés sur des informations locales arbitraire, tels que "tous les certificats fournis aux employés NIST localisé à Boulder.

   Une CRL complète liste tous les certificat non-expirés, dans son scope, qui ont été révoqués pour une des raisons de révocation couverts par le scope de la CRL. Une CRL pleine et complète liste tous les certificats non-expirés fournis par une CA qui a été révoqué pour une raison. (Noter que vu que les CA et les fournisseurs de CRL sont identifiés par nom, le scope d'une CRL n'est pas affectée par la clé utilisée pour signer la CRL ou les clés utilisées pour signer les certificats).

   Si le scope de la CRL inclus un ou plusieurs certificats fournis par une entité autre que le fournisseur de CRL, alors c'est une CRL indirecte. Le scope d'une CRL indirect peut être limitée aux certificats fournis par une simple CA ou peut inclure les certificats fournis par plusieurs CA. Si le fournisseur de la CRL indirecte est une CA, alors le scope de la CRL indirecte peut également inclure les certificats inclus par le fournisseur de cette CRL.

   Le fournisseur de CRL peut également générer des CRL delta. Une CRL delta liste seulement les certificats, dans son scope, dont le statut de révocation a changé depuis l'émission de la dernière CRL de complète référencée. Le scope d'une CRL delta doit être la même que a CRL de base qu'elle référence.

   Ce profile définis une extension de CRL Internet privée mais ne définis pas d'extensions d'entrée de CRL privée.

   Les environnements avec de besoins spéciaux ou additionnels peuvent se baser sur ce profile ou le remplacer.

   Les CA conformes ne sont pas obligés de fournir des CRL si d'autre mécanismes de statut de révocation ou de certificat sont fournis. Quand les CRL sont fournis, les CRL doivent être des CRL v2, doivent inclure la date à laquelle la prochaine CRL sera fournie dans le champ nextUpdate, doivent inclure l'extension de numéro de CRL, et doivent inclure l'extension d'identifiant de clé d'autorité. Les applications conformes qui supportent les CRL doivent traiter les CRL v1 et v2 qui fournissent des informations de révocation pour tous les certificats fournis par une CA. Les applications conformes ne sont pas obligés de supporter le traitement des CRL delta, des CRL indirect, ou des CRL avec un scope autre que tous les certificats fournis par une CA.

Champs de CRL

La syntaxe de CRL X.509 v2 est la suivante. Pour le calcule de signature, la donnée qui est signée est encodée ASN.1 DER. Un encodage ASN.1 DER est un système d'encodage ayant un tag, une longueur, et une valeur pour chaque élément.
CertificateList ::= SEQUENCE {
    tbsCertList TBSCertList,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING }
    
TBSCertList ::= SEQUENCE {
    version Version OPTIONAL, -- si présent, doit être 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 être v2
    } OPTIONAL,
    crlExtensions [0] EXPLICIT Extensions OPTIONAL -- si présent, doit être v2
}
    
-- Version, Time, CertificateSerialNumber, et les Extensions
-- sont tous définis dans la section "champs de certificat de base"
-- AlgorithmIdentifier est décris dans la section signatureAlgorithm

Champs CertificateList

   CertificateList est une séquence de 3 champs requis. Les champs sont décris en détail ci-dessous.

tbsCertList

   Le premier champ dans la séquence est le tbsCertList. Ce champ est lui-même une séquence contenant le nom du fournisseur, une date d'émission, une date d'émission de la prochaine liste, la liste optionnelle des certificats révoqués, et les extensions de CRL optionnels. Quand il n'y a pas de certificats révoqués, la liste des certificats révoqués est absent. Quand un ou plusieurs certificats sont révoqués, chaque entrée dans la liste de certificat révoqués est définie par une séquence de numéro de série de certificat utilisateur, d'une date de révocation, et des extensions d'entrée de CRL optionnels.

signatureAlgorithm

   Le champ signatureAlgorithme contient l'identifiant pour l'algorithme utilisé par le fournisseur de CRL pour signer le CertificateList. Le champ est de type AlgorithmIdentifier, mais d'autres algorithmes de signatures peuvent être supportés. Ce champ doit contenir le même identifiant d'algorithme que le champ signature dans la séquence tbsCertList.

signatureValue

   Le champ signatureValue contient une signature numérique calculée sur le tbsCertList encodé DER ASN.1, qui est utilisé en entrée de la fonction de signature. Cette valeur de signature est encodée en chaîne de bits et inclus dans le champ signatureValue de la CRL. Les détails de ce processus sont spécifiés pour chacun des algorithmes supportés dans les rfc3279, rfc4055, et rfc 4491.

   Les CA qui sont également fournisseurs de CRL peuvent utiliser une seul clé privée pour signer numériquement les certificats et les CRL, ou peuvent utiliser des clé privées séparées. Quand des clés privées séparés sont utilisées, chaque clé publique associée avec les clés ces clés privée sont placées dans un certificat séparé, une avec le bit keyCertSign mis dans l'extension d'utilisation de clé, et une avec le bit cRLSign mis dans l'extension d'utilisation de clé. Quand des clés privée séparés sont utilisés, les certificats émis par la CA contiennent un seul identifiant de clé d'autorité, et les CRL correspondantes contiennent un identifiant de clé d'autorité différent.

   L'utilisation de certificats CA séparés pour la validation des signature de certificat et de CRL peut offrir de caractéristiques de sécurité améliorés; cependant, cela impose une charge dans les applications, et peut limiter l'interopérabilité. De nombreuses application construisent un chemin de certification, puis le valide. La vérification de CRL nécessite un chemin de certification séparé pour la validation de la signature de la CRL. Les applications qui vérifient la CRL doivent supporter la validation de chemin de certification quand les certificats et les CRL sont signés numériquement avec la même clé privée, et devraient supporter la validation de chemin de certification quand les certificats et les CRL sont signés numériquement avec des clé différentes.

Certificate List To Be Signed

   La liste de certificat signée, ou TBSCertList, est une séquence de champs requis et optionnels. Les champs requis identifient le fournisseur de la CRL, l'algorithme utilisé pour signer la CRL, et la date d'émission de la CRL.

   Les champs optionnels incluent la date à laquel le fournisseur de CRL va émettre la prochaine CRL, les listes de certificats révoqués, et les extensions de CRL. La liste de certificats révoqués est optionnel pour supporter le cas où une CA n'a pas de certificats révoqué. Ce profile nécessite que les fournisseurs de CRL conformes incluent le champ nextUpdate et les extensions de CRL d'identifiant de clé d'autorité et de numéro.

Version

   Ce champ optionnel décris la version de la CRL encodée. Quand les extensions sont utilisées, comme requis par ce profile, ce champ doit être présent et doit spécifier la version 2 (valeur 1).

Signature

   Ce champ contient l'identifiant d'algorithme pour l'algorithme utilisé pour signier la CRL. la rfc3279, rfc4055, et rfc 4491 listent les OID pour les algorithmes de signature les plus populaires utilisés dans les PKI de l'Internet.

Issuer Name

   Le nom du fournisseur identifie l'entité qui a signé et fournis la CRL. L'identité du fournisseur est placé dans le champ issuer. Les formes de noms Alternatives peuvent également apparaître dans l'extension issuerAltName. Le champ issuer doit contenir un DN X.500 non-vide. Le champ issuer est définis comme nom de type X.501, et doit suivre les rêgles d'encodage pour le champs du nom du fournisseur dans le certificat.

This Update

   Ce champ indiques la date d'émission de cette CRL. thisUpdate peut être encodé en UTCTime ou GeneralizedTime. Les fournisseurs de CRL conformes à ce profile doivent encoder thisUpdate en UTCTime pour les dates avant 2050. Les fournisseurs de CRL conformes à ce profile doivent encoder thisUpdate en GeneralizedTime pour des dates après 2049. Les application conformes doivent être capable de traiter les dates qui sont encodé en UTCTime ou GeneralizedTime.

   Quand encodé en UTCTime, thisUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section UTCTime). Quand encodé en GeneralizedTime, thisUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section GeneralizedTime).

Next Update

   Ce champ indique la date à laquelle la prochaine CRL sera fournie. La prochaine CRL pourrait être fournie avant cette date, mais ne sera pas fournis après cette date. Les fournisseurs de CRL devraient fournir les CRL avec un temps nextUpdate égale à ou supérieurs à tous les CRL précédentes. nextUpdate peut être encodé en UTCTime ou GeneralizedTime.

   Les fournisseurs de CRL conformes doivent inclure le champ nextUpdate dans toutes les CRL. Noter que la syntaxe ASN.1 de TBSCertList décris ce champ comme optionnel, qui est consistant avec la structure ASN.1 définis dans X.509. Le comportement des clients traitant les CRL qui omettent nextUpdate n'est pas définis par ce profile.

   Les fournisseurs de CRL conformes à ce profile doivent encoder nextUpdate en UTCTime pour les dates avant 2050 et en GeneralizedTime pour les dates après 2049. Les application conformes doivent être capable de traiter les dates encodés en UTCTime ou GeneralizedTime.

   Quand encodé en UTCTime, nextUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section UTCTime). Quand encodé en GeneralizedTime, nextUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section GeneralizedTime).

Revoked Certificates

   Quand il n'y a pas de certificats révoqués, la liste des certificats révoqué doit être absent. Sinon, les certificats révoqués sont listés par leur numéro de série. Les certificats révoqués par la CA sont identifiés de manière unique par ce numéro de série. La date à laquelle la révocation se produit est spécifiée. La date pour revocationDate doit être exprimée comme décris dans la section thisUpdate. Des informations additionnelles peuvent être fournis dans les extensions d'entrée de CRL.

Extensions

   Ce champ peut seulement apparaître si la version est 2. Si présent, ce champ est une séquence d'une ou plusieurs extensions de CRL.

Extensions de CRL

   Les extensions définis par ANSI X9, ISO/IEC, et l'ITU-T pour les CRL X.509 v2 fournissent des méthodes pour associer des attributs additionnels avec les CRL. Le format de CRL X.509 v2 permet également des extensions privées. Chaque extension dans une CRL peut être conçue comme critique ou non. Si une CRL contient une extension critique que l'application en peut pas traiter, alors l'application ne doit pas utiliser cette CRL pour déterminer le statut des certificats. Cependant, les applications peuvent ignorer les extensions non-critiques non reconnus. Les sections suivantes présentent ces extensions utilisées avec les CRL de l'internet. Les communautés peuvent choisir d'inclure des extensions dans les CRL qui ne sont pas définies dans cette spécification. Cependant, une attention particulière doit être faite pour l'adoptions d'extensions critiques dans les CRL qui pourraient être utilisées dans un contexte général.

   Les fournisseurs de CRL conformes doivent inclure les extensions d'identifiant de clé d'autorité et de numéro de CRL dans toutes les CRL émises.

Authority Key Identifier

   L'extension d'identifiant de clé d'autorité fournis un moyen d'identifier la clé publique correspondante à la clé privée utilisée pour signer une CRL. L'identification peut être basée sur l'identifiant de clé (l'identifiant de clé du sujet dans le certificat du signataire de la CRL) ou le nom et le numéro de série du fournisseur. Cette extension est spécialement utile où un fournisseur a plus d'une clé de signature, soit dû à plusieurs paires de clé concurrentes, ou dû à un changement.

   Les fournisseurs de CRL conformes doivent utiliser la méthode d'identifiant de clé, et doivent inclure cette extension dans toutes les CRL émise. La syntaxe pour cette extension de CRL est définie dans la section Authority Key Identifier.

Issuer Alternative Name

   L'extension de nom alternatif de fournisseur permet d'associer des identités alternatives avec le fournisseur de CRL. Les options définies incluent une adresse de messagerie électronique (rfc822Name), un nom DNS, une adresse IP, et une URI. Plusieurs instances d'une forme de nom et plusieurs formes de noms peuvent être inclus. Quand de telles identités sont utilisées, l'extension de nom alternatif de fournisseur doit être utilisé; cependant, un nom DNS peut être représenté dans le champ issuer en utilisant l'attribut domainComponent décris dans la section Issuer.

   Les fournisseurs de CRL conformes devraient marquer l'extension issuerAltName comme non-critique. L'OID et la syntaxe pour cette extension de CRL sont définis dans la section Issuer Alternative Name précédente.

CRL Number

   Le numéro de CRL est une extension de CRL non-critique qui transmet un numéro de séquence croissant monotone pour un scope de CRL et un fournisseur de CRL donné. Cette extension permet aux utilisateurs de facilement déterminer quand une CRL particulière remplace une autre CRL. Les numéros de CRL supportent également l'identification de CRL complètes et de CRL delta complémentaires. Les fournisseurs de CRL conformes à ce profile doivent inclure cette extension dans toutes les CRL et doivent marquer cette extension non-critique.

   Si un fournisseur de CRL génère des CRL delta en plus de CRL complètes pour un scope donné, les CRL complète et delta doivent partager une séquence de numéro. Si une CRL delta et une CRL couvrant le même scope sont émis en même temps, elles doivent avoir le même numéro de CRL et fournir la même information de révocation. C'est à dire, la combinaison de la CRL delta et une CRL complète acceptable doivent fournir la même information de révocation que la CRL complète.

   Si un fournisseur de CRL génère 2 CRL ( 2 CRL complètes, 2 CRL delta, ou une CRL complète et une CRL delta) pour le même scope à des moments différents, les 2 CRL ne doivent pas avoir le même numéro de CRL, c'est à dire, si le champ thisUpdate dans les 2 CRL ne sont pas identiques, les numéros de CRL doivent être différents.

En considération, les numéro de CRL peuvent être de long entiers. Les vérificateurs de CRL doivent être capable de gérer des valeur CRLNumber jusqu'à 20 octets. Les fournisseurs de CRL conformes ne doivent pas utiliser de valeurs CRLNumber plus long que 20 octets.
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
    
CRLNumber ::= INTEGER (0..MAX)

Delta CRL Indicator

   L'indicateur de CRL delta est une extension de CRL critique qui identifie qu'une CRL est une CRL delta. Les CRL delta contiennent des mises à jours d'information de révocation précédemment distribuée. L'utilisation de CRL delta peut significativement réduire la charge réseaux et le temps de traitement dans certains environnements. Les CRL delta sont généralement plus petites que les CRL qu'elles mettent à jours, donc les applications qui obtiennent les CRL delta consomment moins de bande passante que les applications qui obtiennent les CRL complètes correspondantes. Les applications qui stockent les informations de révocation dans un format autre que la structure CRL peuvent ajouter les nouvelles information de révocation dans la base locale sans retraiter les informations.

   L'extension d'indication de CRL delta contient une valeur simple de type BaseCRLNumber. Le numéro de CRL identifie la CRL, complète pour un scope donné, qui a été utilisé comme point de départ dans la génération de cette CRL delta. Un fournisseur de CRL conforme doit publier la CRL de base référencée ou une CRL complète. La CRL delta contient toutes les mises à jours de statut de révocation pour ce même scope. La combinaison d'une CRL delta et de la CRL de base référencée est équivalente à une CRL complète, pour le périmètre applicable, au moment de la publication de la CRL delta.

   Quand un fournisseur de CRL conforme génère une CRL delta, la CRL delta doit inclure une extension d'indication de CRL delta.

   Quand une CRL delta est émise, elle doit couvrir le même jeu de raisons et le même jeu de certificats qui sont couverts par la CRL de base qu'elle référence. C'est à dire que le scope de la CRL delta doit être le même que le scope de la CRL complète référencée comme base. La CRL de base référencée et la CRL delta doivent omettre l'extension de point de distribution d'émission ou doivent contenir des extensions de point de distribution d'émission identique. De plus, le fournisseur de CRL doit utiliser la même clé privée pour signer la CRL delta et toute CRL complète qui peut être utilisée pour les mises à jours.

   Une application qui supporte les CRL delta peuvent construire une CRL qui est complète pour un scope donné en combinant une CRL delta pour ce scope avec soit une CRL émise qui est complète pour ce scope ou une CRL construite localement, qui est complète pour ce scope.

   Quand une CRL delta est combinée avec une CRL complète ou une CRL construite localement, la CRL construite localement résultante a le numéro de CRL spécifié dans l'extension de numéro de CRL trouvé dans la CRL delta utilisée dans sa construction. En plus, le CRL construite localement résultante a les temps thisUpdate et nextUpdate spécifiés dans les champs correspondant de la CRL delta utilisés dans sa construction. En plus, la CRL construite localement hérite du point de distribution d'émission de la CRL delta.

   Une CRL complète et une CRL delta peuvent être combinés si les 4 conditions suivantes sont satisfaites:

(a) La CRL complète et la CRL delta ont le même fournisseur
(b) La CRL complète et la CRL delta ont le même périmètre. Les 2 CRL ont le même périmètre si une des conditions suivantes est satisfaite:

        (1) L'extension issuingDistributionPoint est omis de la CRL complète et de la CRL delta
        (2) L'extension issuingDistributionPoint est présente dans la CRL complète et la CRL delta est sont identiques.

(c) Le numéro de CRL de la CRL complète est égale ou supérieur au BaseCRLNumber spécifié dans la CRL delta. C'est à dire que la CRL complète contient (au minimum) toutes les informations de révocation maintenus par la CRL de base référencée.
(d) Le numéro de CRL de la CRL complète est inférieur au numéro de CRL de la CRL delta. C'est à dire, la CRL delta suit la CRL complète dans la séquence de numérotation.

   Les fournisseurs de CRL doivent s'assurer que la combinaison d'une CRL delta et toute CRL complète appropriée réflète précisément le statut de révocation. Le fournisseur e CRL doit inclure une entrée dans la CRL delta pour chaque certificat dans le scope de la CRL delta dont le status a changé depuis la génération de la CRL de base référencée:

(a) Si le certificat est révoqué pour une raison inclue dans le scope de la CRL, liste le certificat révoqué.
(b) Si le certificat est valide et a été listé dans la CRL de base référencée ou toute CRL suivantes avec un code de raison certificatHold est inclus dans le scope de la CRL, liste le certificat avec le code de raison removeFromCRL.
(c) Si le certificat est révoqué pour une raison hors du scope de la CRL, mais que le certificat a été listé dans la CRL de base référencée ou toute CRL suivante avec un code de raison inclus dans le scope de cette CRL, liste le certificat comme révoqué mais omet le code de raison.
(d) Si le certificat est révoqué pour une raison hors du scope de la CRL est que le certificat n'est ni listé dans la CRL de référence ni dans les CRL suivantes avec un code un code de raison inclus dans le scope de cette CRL, ne pas lister le certificat dans cette CRL.

   Le statut d'un certificat est considéré comme ayant changé s'il est révoqué (pour n'importe quelle raison, incluant certificateHold), s'il est libéré de l'attente, ou si sa raison de révocation change.

   Il est approprié de lister un certificat avec un code de raison removeFromCRL dans une CRL delta même si le certificat n'était pas en attente dans la CRL de base référencée. Si le certificat a été placé en attente dans une CRL émise après la base mais avant cette CRL delta puis relachée, il doit être listé dans le CRL delta avec une raison de révocation removeFromCRL.

   Un fournisseur de CRL peut optionnellement lister un certificat dans une CRL delta avec le code de raison removeFromCRL si le temps notAfter spécifié dans le certificat précède le temps thisUpdate spécifié dans la CRL delta et que le certificat était listé dans la CRL de base référencée. ou dans toute CRL émise après la base mais avant cette CRL delta.

   Si une révocation de certificat apparaît dans une CRL delta, il est possible pour que la période de validité du certificat expire avant la prochaine CRL complète pour le même scope. Dans ce cas, La notification de révocation doit être inclue dans toutes les CRL delta suivantes jusqu'à ce que la notification de révocation soit inclue dans au moins une CRL complète émise pour ce scope.

   Une application qui supporte les CRL delta doit être capable de construire une CRL complète courante en combinant une CRL complète et la CRL delta la plus récente. Une application qui supporte les CRL delta peut également être capable de construire une CRL complète courante en combinant une CRL complète construite localement et la CRL delta courante. Une CRL delta est considérée courante si le date courante est entre les temps contenus dans thisUpdate et nextUpdtae. Sous certaines circonstances, le fournisseur de CRL peut publier une ou plusieurs CRL avant le temps indiqué par le champ nextUpdate. Si plus d'une CRL delta courante est rencontré pour un scope donné, l'application devrait être considérée celle ayant la valeur thisUpdate la plus récente comme courante.


id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
    
BaseCRLNumber ::= CRLNumber

Issuing Distribution Point

   Le point de distribution d'émission est une extension de CRL critique qui identifie le point de distribution de CRL et le scope pour une CRL particulière, et indique si la CRL couvre la révocation des certificat d'entités finaux uniquement, des certificats CA uniquement, ou un jeu limité de codes de raisons. Bien que cette extension soit critique, les implémentations conformes ne sont pas obligés de supporter cette extension. Cependant, les implémentations qui ne supportent pas cette extension doivent soit traiter le statut des certificats non listés dans cette CRL comme inconnu ou localiser une autre CRL qui ne contient pas d'extensions critique non-reconnues.

   La CRL est signée en utilisant la clé privée du fournisseur. Les points de distribution de CRL n'ont pas leur propre paires de clé. Si la CRL est stockée dans un annuaire X.500, elle est stockée dans l'entrée d'annuaire correspondant au point de distribution e CRL, qui peut être différent de l'entrée d'annuaire du fournisseur de CRL.

   Les codes de raison associées avec un point de distribution doivent être spécifiés dans onlySomeReasons. Si onlySomeReasons n'apparaît pas, le point de distribution doit contenir les révocation pour tous les codes de raison. Les CA peuvent utiliser les points de distribution de CRL pour partitionner la CRL sur la base de révocation de routine et de compromission. Dans ce cas, les révocations avec le code de raison keyCompromise, cACompromise, et aACompromise apparaissent dans un point de distribution, et les révocations avec d'autres codes de raison apparaissent dans un autre point de distribution.

   Si une CRL inclus une extension issuingDistributionPoint avec onlySomeReasons présent, alors tout certificat dans le scope de la CRL qui est révoqué doit être assigné à un code de raison autre qui unspecified. La raison de révocation assignées est utilisée pour déterminer dans quelle CRL lister le certificat révoqué, cependant, il n'est pas requis d'inclure l'extension d'entrée de CRL reasonCode dans l'entrée de CRL correspondant.

   La syntaxe et les sémantiques pour le champ distributionPoint sont les même que pour le champ distributionPoint dans l'extension cRLDistributionPoints. Si le champ distributionPoint est présent, alors il doit inclure au moins un des noms du distributionPoint correspondant de l'extension cRLDistributionPoints de tout certificat qui est dans le scope de cette CRL. L'encodage identique doit être utilisé dans les champs distributionPoint du certificat et de la CRL.

   Si le champ distributionPoint est absent, le CRL doit contenir des entrées pour tous les certificats révoqués non-expirés fournis par le fournisseur de CRL, dans le scope de la CRL.

   Si le scope de la CRL inclus uniquement les certificats émis par le fournisseur de CRL, alors le booléen indirectCRL doit être FALSE. Sinon, si le scope de la CRL inclus des certificats fournis par une ou plusieurs autres autorités, indirectCRL doit être à TRUE. L'autorité responsable pour chaque entrée est indiquée par le fournisseur de certificat de l'extension d'entrée de CRL.

   Si le scope de la CRL inclus uniquement des certificats à clé publique d'entité final, alors onlyContainsUserCerts doit être à TRUE. Si le scope de la CRL inclus seulement des certificats CA, alors onlyContainsCACerts doit être à TRUE. Si onlyContainsUserCerts ou onlyContainsCACerts est à TRUE, alors le scope de la CRL ne doit pas inclure de certificats version 1 ou version 2. Les fournisseurs de CRL conformes doivent définir le booléen onlyContainsAttributeCerts à FALSE.

   Les fournisseurs de CRL conformes ne doivent pas émettre de CRL où l'encodage DER de l'extension de point de distribution du fournisseur est une séquence vide. C'est à dire que si onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, et onlyContainsAttributeCerts sont à FALSE, alors soit le champ distributionPoint soit le champ onlySomeReasons doit être présent.


id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
    
IssuingDistributionPoint ::= SEQUENCE {
    distributionPoint [0] DistributionPointName OPTIONAL,
    onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
    onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
    onlySomeReasons [3] ReasonFlags OPTIONAL,
    indirectCRL [4] BOOLEAN DEFAULT FALSE,
    onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
    
     -- au moins un parmis onlyContainsUserCerts, onlyContainsCACerts, et onlyContainsAttributeCerts doit être à TRUE.

Freshest CRL

   L'extension freshest CRL identifie comment les informations de CRL delta pour cette CRL complète est obtenue. Les fournisseurs conformes doivent marquer cette extension non-critique. Cette extension ne doit pas apparaître dans les CRL delta.

   La même syntaxe est utilisée pour cette extension que dans l'extension de certificat cRLDistributionPoints. Cependant, seul le champ de point de distribution est significatif dans ce contexte. Les champs raison et cRLIssuer doivent être omis de cette extension de CRL.

Chaque nom de point de distribution fournis l'emplacement auquel une CRL delta pour cette CRL complète peut être trouvée. Le scope de ces CRL delta doit être le même que le scope de la CRL complète. Le contenu de cette extension de CRL est seulement utilisé pour localiser les CRL delta; le contenu n'est pas utilisé pour valider la CRL ou les CRL delta.
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
    
    FreshestCRL ::= CRLDistributionPoints

Authority Information Access

   Cette section définis l'utilisation de l'extension d'accès aux informations d'autorité dans une CRL. La syntaxe et les sémantiques définis pour l'extension de certificat du même nom sont également utilisé pour l'extension de CRL. Cette extension de CRL doit être marquée non-critique.

   Quand présent dans une CRL, cette extension doit inclure au moins un AccessDescription spécifiant l'id-ad-caIssuers comme accessMethod. L'OID id-ad-caIssuers est utilisé quand l'information disponible liste les certificats qui peuvent être utilisés pour vérifier la signature dans la CRL (par exemple, les certificats qui ont un nom de sujet qui correspond à la clé privée utilisé pour signer la CRL). Les types de méthode d'accès autre que id-ad-caIssuers ne doivent pas être inclus. Au moins une instance de AccessDescription devrait spécifier un URI accessLocation HTTP ou LDAP.

   Quand l'information est disponible via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer vers soit un simple certificat encodé DER soit une collection de certificats dans une message CMS "certs-only" encodé en DER ou BER.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificats individuels encodés DER et devraient être capable d'accepter les messages CMS "certs-only".

   Les implémentations de serveurs HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert dans le champ dans le champ d'en-tête content-type de la réponse pour un simple certificat encodé DER et devraient spécifier le type de média application/pkcs7-mime dans le champ d'en-tête content-type de la réponse pour les message CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir un suffix ".cer" et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir le suffix ".p7c". Les client peuvent utiliser le type de média ou l'extension de fichier comme indicateur de contenu, mais ne devraient pas s'en contenter.

   Quand accessLocation est un directoryName, l'information est obtenu par l'application via le serveur configuré localement. Quand une clé publique de CA est utilisée pour valider les signatures dans les certificats et CRL, le certificat de CA désiré est stocké dans les attributs crossCertificatePair et/ou cACertificate. quand différentes clé publique sont utilisées pour valider les signatures dans les certificats et les CRL, le certificat désiré est stocké dans l'attribut userCertificate. Donc, les implémentations qui supportent la forme directoryName de accessLocation doivent être préparés à trouver le certificat nécessaire dans n'importe lequel de ces attributs. Le protocole qu'une application utilise pour accéder à l'annuaire est un choix local.

   Quand les informations sont disponibles via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI LDAP doit inclure un champ dn contenant de nom distinct de l'entrée maintenant les certificats, doit inclure un champ attributes qui liste les descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paires de cross-certificats, et devrait inclure un hôte (ex: ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary›). Omettre l'hôte (ex: ‹ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary›) implique que le client connaisse le serveur approprié à contacter.

CRL Entry Extensions

   Les extensions d'entrée de CRL définis par l'ISO/IEC, ITU-T, et ANSI X9 pour les CRL X.509 v2 fournissent des méthodes pour associer des attributs additionnels avec des entrées de CRL. Le format de CRL X.509 v2 permet également aux communautés de définir des extensions d'entrée de CRL privées pour gérer les informations spécifiques de ces communautés. Chaque extension dans une entrée de CRL peut être désignée comme critique ou non. Si une CRL contient une extension d'entrée de CRL critique qui l'application ne peut pas traiter, alors l'application ne doit pas utiliser cette CRL pour déterminer le statut des certificats. Cependant, les applications peuvent ignorer les extensions d'entrées de CRL non-critique non reconnus.

   Le support pour les extensions d'entrée de CRL définis dans cette spécification est optionnel pour les fournisseurs de CRL et les applications conformes. Cependant, les fournisseurs de CRL devraient inclure des codes de raison et des dates d'invalidité quand cette information est disponible.

Reason Code

   Le reasonCode est une extension d'entrée de CR non-critique qui identifie la raison pour la révocation du certificat. Les fournisseurs de CRL sont fortement encouragés à inclure des codes de raison significatifs dans les entrées de CRL. Cependant, l'extension d'entrée de CRL de code de raison devrait être absent au lieu d'utiliser la valeur reasonCode unspecified.

   La valeur de reasonCode removeFromCRL peut seulement apparaître dans les CRL delta, et indique qu'un certificat à été supprimé de la CRL soit parce qu'il a expiré, soit parce qu'il n'est plus en attente. Toutes les autres raisons peuvent apparaître dans les CRL et indique que le certificat spécifié devrait être considéré révoqué.


id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
    
    -- reasonCode ::= { CRLReason }
    
CRLReason ::= ENUMERATED {
    unspecified (0),
    keyCompromise (1),
    cACompromise (2),
    affiliationChanged (3),
    superseded (4),
    cessationOfOperation (5),
    certificateHold (6),
    -- La valeur 7 n'est pas utilisée
    removeFromCRL (8),
    privilegeWithdrawn (9),
    aACompromise (10) }

Invalidity Date

   La date d'invalidité est une extension d'entrée de CRL non-critique qui fournis la date à laquelle on sait, ou on suspecte qui la clé privée a été compromise ou que le certificat est devenu invalide. Cette date peut être antérieur à la date de révocation dans l'entrée de CRL, qui est la date à laquelle la CA a procédé à la révocation. Quand une révocation est postées d'abord par un fournisseur de CRL dans une CRL, la date d'invalidité peut précéder la date d'émission des premières CRL, mais la date de révocation ne devrait pas précéder la date d'émission des premières CRL. Quand cette information est disponible, les fournisseurs de CRL sont fortement encouragés à la partager avec les utilisateurs de CRL.

Les valeurs GeneralizedTime inclus dans ce champ doit être exprimés en GMT, et doivent être spécifiés et interprétés comme définis dans la section "GeneralizedTime".
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
    
InvalidityDate ::= GeneralizedTime

Certificate Issuer

   Cette extension d'entrée de CRL identifie le fournisseur de certificat associé avec une entrée dans une CRL indirecte, c'est à dire, une CRL qui a l'indicateur indirectCRL mis dans sont extension de point de distribution d'émission. Quand présent, l'extension d'entrée de CRL de fournisseur de certificat inclus un ou plusieurs noms du champ issuer et/ou de l'extension de noms alternatif du sujet du certificat qui correspond à l'entrée de la CRL. Si cette extension n'est pas présente dans la première entrée dans une CRL indirecte, le fournisseur de certificat par défaut est le fournisseur de CRL. Dans les entrées suivantes, si cette extension n'est pas présente, le fournisseur de certificat pour l'entrée est la même que pour l'entrée précédente. Ce champ est définis comme suit:


id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
    
CertificateIssuer ::= GeneralNames

   Les fournisseurs de CRL conformes doivent inclure dans cette extension le dn du champ issuer du certificat qui correspond à cette entrée de CRL. L'encodage du DN doit être identique à l'encodage utilisé dans le certificat.

   Les fournisseurs de CRL doivent marquer cette extension critique vu que l'implémentation qui ignore cette extension ne peut pas correctement attribuer les entrées de CRL aux certificats. Cette spécification recommande que les implémentations reconnaissent cette extension.

Validation de chemin de certification

   Les procédures de validation de chemin de certification pour les PKI de l'Internet sont basés sur l'algorithme fournis dans X.509. Le traitement des chemins de certification vérifie la liaison entrée le nom distinct du sujet et/ou le nom alternatif du sujet et la clé publique du sujet. La liaison est limitée par les contraintes qui sont spécifiées dans les certificats qui comprennent le chemin et les entrées qui sont spécifiés par les tiers de confiance. Les extensions de contraintes de base et de contraintes de stratégie permettent à la logique de traitement de chemin de certification d'automatiser le processus de prise de décision.

   Cette section décris un algorithme pour valider les chemins de certification. Les implémentations conformes de cette spécification ne sont pas obligés d'implémenter cet algorithme, mais doivent fournir une fonctionnalité équivalente au fonctionnement résultant de cette procédure. Tout algorithme peut être utilisé par une implémentation particulière tant qu'elle dérive le résultat correcte.

   Dans la section suivante, le texte décris la validation basique de chemin . Les chemins valides commencent avec des certificats fournis par une entité de confiance. L'algorithme nécessite la clé publique de la CA, le nom de la CA, et toutes les contraintes sur le jeu de chemins qui peuvent être validés en utilisant cette clé.

   La sélection d'une entité de confiance est une décision de stratégie locale: il peut être le CA supérieur dans une PKI hiérarchique, la CA qui a fournis le certificat du vérificateur, ou toute autre CA dans le réseau PKI. La procédure de validation de chemin est la même quelque soit l'entité de confiance. En plus, différentes applications peuvent faire confiance à plusieurs entités, ou peuvent accepter des chemins qui commencent avec un jeu d'entité de confiance.

Validation de chemin basique

   Ce texte décris un algorithme pour le traitement de chemin X.509. Une implémentation conforme doit inclure une procédure de traitement de chemin X.509 qui est fonctionnellement équivalente à la sortie de cet algorithme. Cependant, le support pour certains extensions de certificat traités dans cet algorithme sont optionnels pour les implémentations conformes. Les clients qui ne supportent pas ces extensions peuvent omettre les étapes correspondantes dans l'algorithme de validation de chemin.

   Par exemple, les clients ne sont pas obligés de supporter l'extension de mappage de stratégie. Les clients qui ne supportent pas cette extension peuvent omettre les étapes de validation de chemin où le traitement du policy mappings sont traités. Noter que les clients doivent rejeter le certificat s'il contient une extension critique non-supportée.

   Bien que les profiles de certificat et de CRL spécifiés dans ce document spécifient des valeurs pour les champs et les extensions de certificat et de CRL considérés appropriés pour les PKI de l'Internet, l'algorithme présenté dans cette section n'est pas limité à accepter les certificats et CRL qui se conforment à cet profiles. Cependant, l'algorithme inclus uniquement les vérifications de chemint de certification valide en accord avec X.509 et n'inclus pas les vérifications de conformité des certificats et CRL avec ce profile. Bien que l'algorithme pourrait être étendu pour inclure des vérifications de conformité avec les profiles de ce document, ce profile recommande de ne pas inclure de telles vérification.

   L'algorithme présenté dans cette section valide le certificat en respectant l'horodatage courant. Un application conforme peut également supporter la validation en respectant un point dans le passé. Noter que les mécanismes ne sont pas disponible pour valider un certificat en dehors de sa période de validité.

   L'entité de confiance est une entrée de l'algorithme. Il n'y a pas d'obligation que la même entité de confiance soit utilisée pour valider tous les chemins de certification. Plusieurs entités de confiance peuvent être utilisés pour valider différents chemins.

   Le but premier de la validation de chemin est de vérifier le lien entre un nom distinct du sujet ou un nom alternatif du sujet et la clé publique du sujet, tel que représenté dans le certificat cible, basé sur la clé publique de l'entité de confiance. Dans la plupart des cas, le certificat cible sera un certificat d'entité finale, mais le certificat cible peut être un certificat de CA tant que la clé publique du sujet est utilisée dans un but autre que vérifier la signature dans certificat à clé publique. Vérifier le lien entre le nom et la clé publique nécessite d'obtenir une séquence de certificats qui supportent ce lien. La procédure effectuée pour obtenir cette séquence de certificat est hors du scope de cette spécification.

   Dans ce but, le processus de validation de chemin vérifie, entre autre, qu'un chemin de certification éventuel ( une séquence de n certificats ) satisfait les conditions suivantes:

(a) Pour tout x dans { 1, ..., n-1 }, le sujet des certificats x est le fournisseur du certificat x+1
(b) le certificat 1 est fournis par l'entité de confiance
(c) Le certificat n est le certificat à valider
(d) Pour tout x dans { 1, ..., n }, le certificat était valide à l'époque en question

   Un certificat ne doit pas apparaître plus d'une fois dans une chemin de certification éventuel.

   Quand l'entité de confiance est fournis sous la forme d'un certificat auto-signé, ce certificat n'est pas inclus comme partie du chemin de validation éventuel. Les informations sur l'entité de confiance est fournis en entrée de l'algorithme de validation de chemin de certification.

   Un chemin de validation de certification particulier ne peut pas, cependant, être approprié pour toutes les applications. Une application peut augmenter cet algorithme pour limiter le jeu de stratégie de certificat qui sont valides pour ce chemin, basé sur l'extension de stratégies de certificat, l'extension de mappage de stratégie, l'extension de contraintes de stratégie, et inhiber l'extension anyPolicy. Pour accomplir cela, l'algorithme de validation de chemin construit une arborescence de stratégie valide. Si le jeu de stratégies de certificat qui sont valides pour ce chemin n'est pas vide, alors le résultat sera une arborescence de stratégie valide de profondeur n, sinon le résultat sera une arborescence de stratégie valide null.

   Un certificat est auto-fournis si le même DN apparaît dans les champs sujets et fournisseur. En général, le fournisseur et le sujet des certificat qui constituent un chemin sont différents pour chaque certificat. Cependant, une CA peut fournir un certificat à elle-même pour supporter le changement de clé ou de stratégies de certificat. Ces certificats auto-fournis ne sont pas comptés dans l'évaluation de la longueur de chemin ou les contraintes de nom.

   Cette section présente l'algorithme en 4 étapes de base: initialisation, traitement de certificats de base, préparation pour le certificat suivant, et la conclusion. Les étapes 1 et 4 sont effectuées exactement 1 seule fois, l'étape 2 est effectuée pour tous les certificats dans le chemin, et l'étape 3 est effectuée pour tous les certificats dans le chemin excepté le certificat final. La figure suivante fournis une vue générale de cet algorithme:


___________________________+- - - -+
___________________________|_START_|
___________________________+- - - -+
_______________________________|
_______________________________V
_______________________+- - - - - - - - +
_______________________|_Initialization_|
_______________________+- - - - - - - - +
_______________________________|
_______________________________+‹- - - - - - - - - - +
_______________________________|_____________________|
_______________________________V_____________________|
_______________________+- - - - - - - - +____________|
_______________________|__Process_Cert__|____________|
_______________________+- - - - - - - - +____________|
_______________________________|_____________________|
_______________________________V_____________________|
_______________________+================+____________|
_______________________|__IF_Last_Cert__|____________|
_______________________|____in_Path_____|____________|
_______________________+================+____________|
_________________________|____________|______________|
____________________THEN_|____________|_ELSE_________|
_________________________V____________V______________|
______________+- - - - - - - - +_+- - - - - - - - +__|
______________|____Wrap_up_____|_|__Prepare_for___|__|
______________+- - - - - - - - +_|___Next_Cert____|__|
______________________|__________+- - - - - - - - +__|
______________________V_______________|______________|
__________________+- - - -+___________+- - - - - - - +
__________________|_STOP__|
__________________+- - - -+

Entrées

   Cet algorithme assume que les 9 entrées suivantes sont fournis au traitement de chemin:

(a) Une chemin de certification éventuel de longueur n
(b) La date et heure courante
(c) user-initial-policy-set, nommant les stratégies qui sont acceptables pour l'utilisateur de certificat. Le user-initial-policy-set contient la valeur spéciale any-policy si l'utilisateur n'est pas concerné par les stratégies de certificat.
(d) Informations de l'entité de confiance qui incluent:

        (1) Le nom du fournisseur de confiance
        (2) L'algorithme de clé publique de confiance
        (3) La clé publique de confiance
        (4) Optionnellement, les paramètres de clé publique associés à la clé publique.

   Les informations de l'entité de confiance peuvent être fournis à la procédure de traitement de chemin sous la forme d'un certificat auto-signé. Quand les information de l'entité de confiance sont fournies sous la fourme d'un certificat, le nom dans le champ subject est utilisé comme nom de fournisseur de confiance et le contenu du champ subjectPublicKeyInfo est utilisé comme source de l'algorithme de clé publique de confiance et la de clé publique de confiance. Les informations d'entité de confiance sont de confiance parce qu'elles ont été délivrées à la procédure de traitement de chemin par une procédure digne de confiance. Si l'algorithme de clé publique de confiance nécessite des paramètres, alors les paramètres sont fournis avec la clé publique de confiance.

(e) initial-policy-mapping-inhibit, qui indique si le mappage de stratégie est permis dans le chemin de certification.
(f) initial-explicit-policy, qui indique si le chemin doit être valide pour au moins une des stratégie de certificat dans le user-initial-policy-set.
(g) initial-any-policy-inhibit, qui indique si l'OID anyPolicy devrait être traité s'il est inclus dans un certificat
(h) initial-permitted-subtrees, qui indique pour chaque type de nom un jeu de sous-arborescences dans lequel tous les noms du sujet dans tous les certificats dans le chemin de certification doivent aller. Cette entrée doit inclure un jeu pour chaque type de nom. Pour chaque type de nom, le jeu peut consister d'une simple sous-arborescence qui inclus tous les noms de ce type de nom ou une ou plusieurs sous-arborescence qui chacune spécifie un sous-jeu de noms de ce type de nom, ou le jeu peut être vide. Si le jeu pour un type de nom est vide, alors le chemin de certification sera considéré invalide dans tous les certificats dans le chemin de certification qui inclus un nom de ce type de nom.
(i) initial-excluded-subtrees, qui indique pour chaque type de nom un jeu de sous-arborescence dans lequel aucun nom du sujet dans les certificats du chemin de certification ne peut aller. Cette entrée inclus un jeu pour chaque type de nom. Pour chaque type de nom, le jeu peut être vide ou peut consister d'une ou plusieurs sous-arborescences qui spécifient chacun un sous-jeu des noms de ce type de nom. Si le jeu pour un type de nom est vide, aucun nom de ce type de nom n'est exclus.

Initialization

   Cette phase d'initialisation établis 11 variables d'état basés sur les 9 entrées:

(a) valid_policy_tree: Une arborescence de stratégies de certificats avec leurs qualifiants optionnels; chaque branche de l'arborescence représente une stratégie valide à ce stade de la validation du chemin de certification. Si des stratégie valides existent à ce stade dans la validation du chemin de certification, la profondeur de l'arbre est égal au nombre de certificats dans la chaîne qui a été traitée. Si des stratégies valides n'existent pas à ce stade, l'arbre est null. Une fois l'arbre mis à NULL, le traitement de stratégie s'arrête.

        (1) valid_policy est un simple OID de stratégie représentant une stratégie valide pour le chemin de longueur x.
        (2) qualifier_set est un jeu de qualifiants de stratégie associés avec la stratégie valide dans le certificat x.
        (3) expected_policy_set contient un ou plusieurs OID de stratégie qui satisferait cette stratégie dans le certificat x+1.

   La valeur initiale de valid_policy_tree est un nœud simple avec pour valid_policy anyPolicy, un qualifier_set vide, et un expected_policy_set avec la seule valeur anyPolicy. Ce nœud a une profondeur de 0.

La figure suivante est une représentation graphique de l'état initial de valid_policy_tree. Les figures additionnelles vont utiliser ce format pour décrire les changement dans le valid_policy_tree durant le traitement du chemin.
______________+- - - - - - - - +
______________|___anyPolicy____|___‹- - _valid_policy
______________+- - - - - - - - +
______________|_______{}_______|___‹- - _qualifier_set
______________+- - - - - - - - +
______________|__{anyPolicy}___|___‹- - _expected_policy_set
______________+- - - - - - - - +

(b) permitted_subtrees: un jeu de noms racine pour chaque type de nom définissant un jeu de sous-arborescence dans lequel tous les noms du sujet dans les certificats suivant dans le chemin de certificat doivent tomber. Cette variable inclus un jeu pour chaque type de nom, et la valeur initiale est initial-permitted-subtrees.
(c) excluded_subtrees: un jeu de noms racines pour chaque type de nom définissant un jeu de sous-arborescence dans lequel aucun nom du sujet dans les certificats suivant dans le chemin de certification ne peut tomber. Cette valiable inclus un jeu pour chaque type de nom, et la valeur initiale est initial-excluded-subtrees.
(d) explicit_policy: Un entier qui indique si un valid_policy_tree non-null est requis. L'entier indique le nombre de certificats non auto-fournis à traiter avant que ce requis soit imposé. Une fois définis, cette variable peut être décrémentée, mais ne peut pas être incrémentée. C'est à dire, si un certificat dans le chemin requière un valid_policy_tree non-null, un certificat ultérieur ne peut pas supprimer ce requis. Si initial-explicit-policy est mis, alors la valeur initiale est 0, sinon la valeur initiale est n+1.
(e) inhibit_anyPolicy: un entier qui indique si l'identifiant de stratégie anyPolicy est considéré comme un match. L'entier indique le nombre de certificats non auto-fournis à traiter avant que l'OID anyPolicy, si indiqué dans un certificat autre qu'un certificat intermédiaire auto-fournis, est ignoré. Une fois mis, cette variable peut être décrémentée, mais ne peut pas être incrémentée. C'est à dire, si un certificat dans le chemin inhibe le traitement de anyPolicy, un certificat ultérieur ne peut pas le permettre. Si initial-any-policy-inhibit est mis, alors la valeur initial est 0, sinon la valeur initial est n+1.
(f) policy_mapping: un entier qui indique si le mappage de stratégie est permis. L'entier indique le nombre de certificat non auto-fournis à traiter avant que le mappage de stratégie soit inhibé. Une fois mis, cette variable peut être décrémentée, mais ne peut pas être incrémenté. C'est à dire,, si un certificat dans le chemin spécifie que le mappage de stratégie n'est pa permis, il ne peut pas écrasé par un certificat ultérieur. Si initial-policy-mapping-inhibit est mis, la valeur initiale est 0, sinon la valeur est n+1.
(h) working_public_key: La clé publique utilisée pour vérifier la signature d'un certificat. working_public_key est initialiée depuis la clé publique de confiance fournis dans les informations de l'entité de confiance.
(i) working_public_key_parameters: Les paramètres associés avec la clé publique courante qui peut être requise pour vérifier une signature ( en fonction de l'algorithme). working_public_key_parameters est initialisée avec les paramètres de clé publique de confiance fournis dans les informations de l'entité de confiance.
(j) working_issuer_name: Le dn du fournisseur prévu dans le prochain certificat dans la chaîne. working_issuer_name est initialisé avec le dn du founisseur fournis la les informations de l'entité de confiance.
(k) max_path_length: Cet entier est initialisé à n, est décrémenté pour chaque certificat non auto-fournis dans le chemin, et peut être réduit à la valeur dans le champ de contrainte de longueur de chemin dans l'extension de contraintes de base d'un certificat de CA.

   Une fois ces étapes d'initialisation complétées, effectue les étapes de traitement de certificat de base.

Traitement de certificat de base

   Les actions de traitement de chemin de base à effectuer pour le certificat i ( pour tout i dans [1..n] ) sont les suivantes:

(a) Vérifie les informations de certificat de base. Le certificat doit satisfaire chacun des points suivants:

        (1) La signature dans le certificat peut être vérifié en utilisant working_public_key_algorithm, working_public_key, et working_public_key_parameters.
        (2) La période de validité du certificat inclus l'heure courante
        (3) Actuellement, le certificat n'est pas révoqué. Cela peut être déterminé en obtenant le CRL appropriée, par information de statut, ou par des mécanismes tiers.
        (4) Le nom du fournisseur de certificat est le working_issuer_name.

(b) Si le certificat i est auto-fournis et n'est pas le certificat final dans le chemin, saute cette étape pour le certificat i. Sinon, vérifie que le nom du sujet est dans un des permitted_subtrees pour les noms distincts X.500, et vérifie que chaque noms alternatifs dans l'extension subjectAltName (critique ou non-critique) est dans un des permitted_subtrees pour ce type de nom.
(c) Si le certificat i est auto-fournis et n'est pas le certificat final dans le chemin, saute cette étape pour le certificat i. Sinon, vérifie que le nom du sujet n'est pas dans le excluded_subtrees pour les noms distincts X.500, et vérifie que chaque noms alternatifs n'est pas dans un des excluded_subtrees pour ce type de nom.
(d) Si l'extension de stratégies de certificats est présent dans le certificat et le valid_policy_tree n'est pas null, traite les information de stratégie en effectuant les étapes suivantes dans l'ordre:

        (1) Pour chaque stratégie P non égal à anyPolicy dans l'extension de stratégie de certificat, P-OID dénote l'OID pour la stratégie P et P-Q dénote le jeu de qualifiant pour la stratégie P. Effectue les étapes suivantes dans l'ordre:

                (i) Pour chaque nœud de profondeur i-1 dans le valid_policy_tree où P-OID est dans le expected_policy_set, crée un nœud enfant comme suit: définis valid_policy à P-OID, définis qualifier_set à P-Q, et définis expected_policy_set à {P-OID}.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où expected_policy_set est {Gold, White}. Les stratégies de certificat Gold et Silver apparaissent dans l'extension de stratégie de certificat du certificat i. La stratégie Gold est matchée, mais la stratégie Silver ne l'est pas. Cette règle va générer un nœud enfant de profondeur i pour la stratégie Gold:
_____________________________+- - - - - - - - -+
_____________________________|_______Red_______|
_____________________________+- - - - - - - - -+
_____________________________|_______{}________|
_____________________________+- - - - - - - - -+___node_of_depth_i-1
_____________________________|__{Gold,_White}__|
_____________________________+- - - - - - - - -+
______________________________________|
______________________________________|
______________________________________|
______________________________________V
_____________________________+- - - - - - - - -+
_____________________________|______Gold_______|
_____________________________+- - - - - - - - -+
_____________________________|_______{}________|
_____________________________+- - - - - - - - -+___node_of_depth_i
_____________________________|_____{Gold}______|
_____________________________+- - - - - - - - -+

                (ii) S'il n'y avait pas de correspondance dans l'étape (i) et valid_policy_tree incluais un nœud de profondeur i-1 avec valid_policy anyPolicy, génère un nœud enfant avec les valeurs suivantes: définis valid_policy à P-OID, définis qualifier_set à P-Q, et définis expected_policy_set à {P-OID}.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où valid_policy est anyPolicy. Les stratégie de certificat Gold et Silver apparaîssent dans l'extension de stratégies de certificat du certificat i. La stratégie Gold n'a pas de qualifiant, mais la stratégie Silver a le qualifiant Q-Silver. Si Gold et Silver ne correspondent pas dans (i), cette règle va générer 2 nœuds enfants de profondeur i, une pour chaque stratégie:
__________________________________+- - - - - - - - -+
___________________________________|____anyPolicy____|
___________________________________+- - - - - - - - -+
___________________________________|_______{}________|
___________________________________+- - - - - - - - -+_node_of_depth_i-1
___________________________________|___{anyPolicy}___|
___________________________________+- - - - - - - - -+
______________________________________/___________\
_____________________________________/_____________\
____________________________________/_______________\
___________________________________/_________________\
_____________________+- - - - - - - - -+__________+- - - - - - - - -+
_____________________|______Gold_______|__________|_____Silver______|
_____________________+- - - - - - - - -+__________+- - - - - - - - -+
_____________________|_______{}________|__________|___{Q-Silver}____|
_____________________+- - - - - - - - -+_nodes_of_+- - - - - - - - -+
_____________________|_____{Gold}______|_depth_i__|____{Silver}_____|
_____________________+- - - - - - - - -+__________+- - - - - - - - -+

        (2) Si l'extension de stratégies de certificat inclus la stratégie anyPolicy avec le qualifiant AP-Q et soit (a) inhibit_anyPolicy est plus grand que 0 ou (b) i‹n et le certificat est auto-fournis, alors: Pour chaque nœud dans valid_policy_tree de profondeur i-1, pour chaque valeur dans expected_policy_set (inclant anyPolicy) qui n'apparaît pas dans un nœud enfant, crée un nœud enfant avec les valeurs suivantes: définis valid_policy à la valeur de expected_policy_set dans le nœud parent, définis qualifier_set à AP-Q, et définis expected_policy_set à la valeur dans valid_policy de ce nœud.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où expected_policy_set est {Gold, Silver}. anyPolicy apparaît dans l'extension de stratégie de certificat i sans qualifiant de stratégie, mais Gold et Silver n'apparaît pas. Cette règle va générer 2 nœuds enfant de profondeur i, une pour chaque stratégie:
_______________________________+- - - - - - - - -+
_______________________________|______Red________|
_______________________________+- - - - - - - - -+
_______________________________|_______{}________|
_______________________________+- - - - - - - - -+_node_of_depth_i-1
_______________________________|__{Gold,_Silver}_|
_______________________________+- - - - - - - - -+
__________________________________/___________\
_________________________________/_____________\
________________________________/_______________\
_______________________________/_________________\
_________________+- - - - - - - - -+__________+- - - - - - - - -+
_________________|______Gold_______|__________|_____Silver______|
_________________+- - - - - - - - -+__________+- - - - - - - - -+
_________________|_______{}________|__________|_______{}________|
_________________+- - - - - - - - -+_nodes_of_+- - - - - - - - -+
_________________|_____{Gold}______|_depth_i__|____{Silver}_____|
_________________+- - - - - - - - -+__________+- - - - - - - - -+

        (3) S'il y a un nœud dans valid_policy_tree de profondeur i-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ait plus de nœud de profondeur i-1 ou moins dans enfant. Par exemple, on considère valid_policy_tree ci-dessous. Les 2 nœuds à la profondeur i-1 qui sont marqués avec un 'X' n'ont pas d'enfant, et sont supprimés. Appliquer cette règle à l'arbre résultant va cause le nœud à la profondeur i-2 qui est marqué avec un 'Y' d'être supprimé. Dans l'arbre résultant, il n'y a pas de nœuds de profondeur i-1 ou moins dans enfant, et cette étape est complète.

(e) Si l'extension de stratégies de certificat n'est pas présent, définis valid_policy_tree à NULL.
(f) Vérifie que soit explicit_policy est supérieur à 0 soit valid_policy_tree n'est pas égal à NULL

   Si une des étapes (a), (b), (c), ou (f) échoue, la procédure se termine, retournant une erreur indiquant un raison appropriée.

Si i n'est pas égal à n, continue en effectuant le étapes préparatoires listées dans la section suivante. Si i est égal à f, effectue les étapes listés dans la section d'après.
_________________________________+- - - - - -+
_________________________________|___________|_node_of_depth_i-3
_________________________________+- - - - - -+
_________________________________/_____|_____\
________________________________/______|______\
_______________________________/_______|_______\
___________________+- - - - - -+_+- - - - - -+_+- - - - - -+
___________________|___________|_|___________|_|_____Y_____|_nodes_of
___________________+- - - - - -+_+- - - - - -+_+- - - - - -+_depth_i-2
___________________/___\_______________|_____________|
__________________/_____\______________|_____________|
_________________/_______\_____________|_____________|
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+_nodes_of
______|___________|_|_____X_____|_|___________|_|____X______|__depth
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+___i-1
____________|______________________/____|____\
____________|_____________________/_____|_____\
____________|____________________/______|______\
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+_nodes_of
______|___________|_|___________|_|___________|_|___________|__depth
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+___i

Préparation pour le certificat i+1

   Pour préparer le traitement du certificat i+1, effectuer les étapes suivantes pour le certificat i:

(a) Si une extension de mappage de stratégie est présente, vérifie que la valeur spéciale anyPolicy n'apparaît pas comme un issuerDomainPolicy ou un subjectDomainPolicy.
(b) Si une extension de mappage de stratégie est présente, pour chaque issuerDomainPolicy ID-P dans l'extension de mappage de stratégie:

        (1) Si la variable policy_mapping est supérieur à 0, pour chaque nœud dans valid_policy_tree de profondeur i où ID-P est le valid_policy, définis expected_policy_set au jeu de valeurs subjectDomainPolicy qui sont spécifiées comme équivalent à ID-P par l'extension de mappage de stratégie.
        Si aucun nœud de profondeurs i dans valid_policy_tree n'a un valid_policy à anyPolicy, génère un nœud enfant du nœud de profondeur i-1 qui a un valid_policy de anyPolicy comme suit:

                (i) Définis valid_policy à ID-P
                (ii) Définis qualifier_set au jeu de qualifiant de stratégie anyPolicy dans l'extension de stratégie de certificat du certificat i
                (iii) Définis expected_policy_set au jeu de valeurs subjectDomainPolicy qui sont spécifiés comme équivalent à ID-P par l'extension de mappage de stratégie.

        (2) Si policy_mapping est égal à 0:

                (i) Supprime chaque nœud de profondeur i dans valid_policy_tree où ID-P est le valid_policy
                (ii) S'il y a un nœud dans valid_policy_tree de profondeur i-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ait plus de nœuds de profondeur i-1 ou moins sans enfant.

(c) Assigne le nom du sujet du certificat au working_issuer_name
(d) Assigne le subjectPublicKey du certificat au working_public_key
(e) Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec des paramètres non-null, assigne les paramètres à la variable working_public_key_parameters. Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec des paramètres null ou les paramètres sont omis, compare l'algorithme subjectPublicKey au working_public_key_algorithm. Si l'algorithme subjectPublicKey du certificat et le working_public_key_algorithm sont différent, définis working_public_key_parameters à null.
(f) Assigne l'algorithme de subjectPublicKey du certificat à la variable working_public_key_algorithm
(g) Si une extension de contrainte de noms est inclue dans le certificat, modifie permitted_subtrees et excluded_subtrees comme suit:

        (1) Si permittedSubtrees est présent dans le certificat, définis la variable d'état permitted_subtrees à l'intersection de sa précédente valeur et de la valeur indiquée dans le champ de l'extension. Si permittedSubtrees n'inclus pas un type de nom particulier, la variable d'état permitted_subtrees est inchangée pour ce type de nom. Par exemple, l'intersection de example.com et foo.example.com est foo.example.com. Et l'intersection de example.com est example.net est un jeu vide.
        (2) Si excludedSubtrees est présent dans le certificat, définis la variable d'état excluded_subtrees à l'union de sa valeur précédente valeur et la valeur indiquée dans le champ de l'extension. si excludedSubtrees n'inclus par un type de nom particulier, la variable d'état excluded_subtrees n'est pas changée pour ce type de nom. Par exemple, l'union de l'espace de nom example.con et foo.example.com est example.com. Et l'union de example.com et example.net est les 2 espaces de nom.

(h) Si le certificat i n'est pas auto-fournis:

        (1) Si explicit_policy n'est pas 0, décrémente de 1
        (2) Si policy_mapping n'est pas 0, décrémente de 1
        (3) Si inhibit_anyPolicy n'est pas 0, décrémente de 1

(i) Si une extension de containte de stratégie est inclue dans le certificat, modifie les variables d'état explicit_policy et policy_mapping comme suit:

        (1) Si requireExplicitPolicy est présent et est inférieur à explicit_policy, définis explicit_policy à la valeur de requireExplicitPolicy
        (2) Si inhibitPolicyMapping est présent et est inférieur à policy_mapping, définis policy_mapping à la valeur de inhibitPolicyMapping

(j) Si l'extension inhibitAnyPolicy est inclus dans le certificat et est inférieur à inhibit_anyPolicy, définis inhibit_anyPolicy à la valeur de inhibitAnyPolicy
(k) Si le certificat i est un certificat v3, vérifie que l'extension basicConstraints est présent et que cA est mis à TRUE. ( Si le certificat i est un v1 ou v2, l'application doit vérifier que le certificat i est un certification CA via un moyen externe ou rejeter le certificat. Les implémentations conformes peuvent choisir de rejeter tous les certificat intermédiaire v1 et v2)
(l) Si le certificat n'est pas auto-fournis, vérifie que max_path_length est supérieur à 0 et le décrémente de 1
(m) Si pathLenConstraint est présent dans le certifiat et est inférieur à max_path_length, définis max_path_length à la valeur de pathLenConstraint
(n) Si une extension d'utilisation de clé est présente, vérifie que le bit keyCertSign est mis.
(o) Reconnaît et traite toute autre extension critique présent dans le certificat. Traite tout autre extension non critique présente dans le certificat qui a sont importance dans le traitement du chemin.

   Si les vérification (a), (k), (l), (n), ou (o) échouent, la procédure se termine, retournant une indication d'erreur et une raison appropriée.

  si (a), (k), (l), (n), et (o) sont complétées avec succès, incrémente i et effectue le traitement de certificat de base spécifié dans la section précédente.

Procédure Wrap-Up

   Pour compléter le traitement du certificat cible, effectue les étapes suivantes pour le certificat n:

(a) Si explicit_policy n'est pas 0, décrément explicit_policy de 1
(b) Si une extension de contrainte de stratégie est inclue dans le certificat et requireExplicitPolicy est présent et a une valeur de 0, définis la variable d'état explicit_policy à 0.
(c) Assigne le certificat subjectPublicKey à working_public_key
(d) Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec un paramètre non-null, assigne les paramètres à la variable working_public_key_parameters.
Si le champ subjectPublicKeyInfo du certificat contient un champ algorithm avec des paramètre null ou des paramètre omis, compare l'algorithme subjectPublicKey avec working_public_key_algorithm. S'ils sont différents, définis working_public_key_algorithm à nul.
(e) Assigne l'algorithme subjectPublicKey à la variable working_public_key_algorithm.
(f) Reconnaît et traite toute autre extension critique présente dans le certificat n. Traite tout autre extension non critique présente qui a sont importance dans le traitement du chemin.
(g) Calcule l'intersection de valid_policy_tree et user-initial-policy-set, comme suit:

        (i) si valid_policy_tree est null, l'intersection est null.
        (ii) Si valid_policy_tree n'est pas null et que user-initial-policy-set est any-policy, l'intersection est tout le valid_policy_tree
        (iii) Si valid_policy_tree n'est pas null et que user-initial-policy-set est any-policy, calcule l'intersection de valid_policy_tree et de user-initial-policy-set comme suit:

                1. Détermine le jeu de nœuds de stratégies dont les nœuds parent ont un valid_policy à anyPolicy. C'est le valid_policy_node_set.
                2. Si valid_policy d'un nœud dans valid_policy_node_set n'est pas dans le user-initial-policy-set et n'est pas anyPolicy, supprime ce nœud et tous ses enfants.
                3. Si valid_policy_tree inclus un nœuds de profondeur n avec valid_policy anyPolicy et user-initial-policy-set n'est pas any-policy, effectue les étapes suivantes:

                        a. Définis P-Q au qualifier_set dans le nœud de profondeur n avec valid_policy anyPolicy
                        b. Pour chaque P-OID dans user-initial-policy-set qui n'est pas le valid_policy d'un nœud dans valid_policy_node_set, crée un nœud enfant dont le parent est le nœud de profondeur n-1 avec valid_policy anyPolicy. Définis les valeurs dans le nœud enfant comme suit: définis valid_policy à P-OID, définis le qualifier_set à P-Q, et définis le jeu expected_policy à {P-OID}.
                        c. Supprime le nœud de profondeur n avec le valid_policy anyPolicy.

                4. S'il y a un nœud dans valid_policy_tree de profondeur n-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ai plus de nœud de profondeur n-1 ou moins sans enfant.

   Si (1) la valeur de explicit_policy est supérieur à 0 ou (2) valid_policy_tree n'est pas null, le traitement du chemin a réussit.

Sorties

   Si le traitement du chemin réussit, la procédure se termine, retournant une indication de succès avec la valeur finale de valid_policy_tree, working_public_key, working_public_key_algorithm, et working_public_key_parameters.

Utiliser l'algorithme de validation de chemin

   L'algorithme de validation de chemin décris le processus de validation d'un simple chemin de certification. Bien que chaque chemin de certification commence avec une ancre de confiance, il n'y a pas de pré-requis pour tous les chemins de certification validés par un système particulier qui partage une seul ancre de confiance. La sélection d'une ou plusieurs CA de confiance comme ancre de confiance est une décision locale. Un système peut fournir une de ses CA de confiance comme ancre de confiance pour un chemin particulier. L'entrée dans l'algorithme de validation de chemin peut être différent pour chaque chemin. Les entrées utilisées pour traiter un chemin peuvent refléter des pré-requis spécifique à une application ou les limitations dans la confiance accordée à une ancre de confiance particulière. Par exemple, une CA de confiance peut seulement être approuvée pour une stratégie de certificat particulier. Cette restriction peut être exprimée via les entrées de la procédure de validation de chemin.

   Une implémentation peut augmenter l'algorithme présenté plus haut pour limiter le jeu de chemins de certification valide qui commencent avec une ancre de confiance particulière. Par exemple, une implémentation peut modifier l'algorithme pour appliquer une contrainte le longueur de chemin pour une ancre de confiance spécifique durant la phase d'initialisation, ou l'application peut nécessite la présence d'une forme de nom alternative particulière dans le certificat cible, ou l'application peut imposer des pré-requis dans les extensions spécifiques à l'application. L'algorithme de validation de chemin présenté dans ce document définis les conditions minimum pour qu'un chemin soit considéré valide.

   Quand une CA distribut des certificat auto-signés pour spécifier des informations d'ancre de confiance, les extensions de certificat peuvent être utilisé pour spécifier les entrées recommandées à la validation de chemin. Par exemple, une extension de contrainte de stratégie pourrait être inclus dans le certificat auto-signé pour indiquer que le chemin commençant avec cet ancre de confiance devrait être validé seulement pour les stratégies spécifiées. Similairement, une extension de contrainte de nom pourrait être inclus pour indiquer que les chemins commençant avec cet ancre de confiance devraient être validés seulement pour les espaces de nom spécifiés. L'algorithme de validation de chemin présenté dans ce document n'assume pas que les informations de l'ancre de confiance est fournie dans des certificats auto-signés et ne spécifie pas les règles de traitement pour les informations additionnelles inclus dans de tels certificats.

   Cependant, la rfc 5914 définis de nombreux formats pour représenter des informations d'ancre de confiance, incluant des certificats auto-signés, et la rfc 5937 fournis un exemple sur comment de telles informations peuvent être utilisées pour initialiser les entrées de validation de chemin. Les implémentations sont libre d'utiliser les informations additionnelles qui sont inclus dans la représentation de l'ancre de confiance, ou des les ignorer.

Validation de CRL

   Cette section décris les étapes nécessaires pour déterminer is un certificat est révoqué quand les CRL sont le mécanisme de révocation utilisé par le fournisseur de certificat. Les implémentations conformes qui supportent les CRL ne sont pas obligés d'implémenter cet algorithme, mais elles doivent être fonctionnellement équivalente à cette procédure. Tout algorithme peut être utilisé par une implémentation tant qu'elle dérive un résultat correcte.

   Cet algorithme assume que toutes les CRL nécessaire sont disponible dans un cache local. De plus, si le temps nextUpdate d'une CRL a passé, l'algorithme assume un mécanisme pour chercher une CRL courante et la placer dans le cache de CRL local.

   Cet algorithme définis un jeu d'entrées, un jeu de variables d'états, et des étapes de traitement qui sont effectués pour chaque certificat dans le chemin. La sortie de l'algorithme est le statut de révocation du certificat.

Entrées de révocation

   Pour supporter le traitement de la révocation, l'algorithme nécessite 2 entrées:

(a) certificate: l'algorithme nécessite le numéro de série du certificat et le nom du fournisseur pour déterminer si un certificat est dans une CRL particulière. L'extension basicConstraints est utilisé pour déterminer si le certificat fournis est associé avec un CA ou une entité finale. Si présent, l'algorithme utilise les extensions cRLDistributionPoints et freshestCRL pour déterminer de statut de révocation.
(b) use-delta: ce booléen détermine si des CRL delta sont appliquées aux CRL.

Variables d'état d'initialisation et de révocation

   Pour supporter le traitement des CRL, l'algorithme nécessite les variable d'état suivants:

(a) reasons_mask: Cette variable contient le jeu de raisons de révocation supportés par les CRL et les CRL délta. Les membres légaux de ce jeu sont les valeurs de raison possible moins ceux non-spécifiés: La valeur spéciale all-reasons est utilisée pour dénoter le jeu de tous les membres légaux. Cette variable est initialisée à un jeu vide.
(b) cert_status: cette variable contient le statut du certificat. Cette variable peut être assignée à une des valeurs suivantes: unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, la valeur spéciale UNREVOKED, ou la valeur spéciale UNDETERMINED. Cette variable est initialisée à UNREVOKED.
(c) interim_reasons_mask: contient le jeu de raisons de révocation supportés par le CRL ou la CRL delta actuellement traitée.

   Note: Dans certains environnements, il n'est pas nécessaire de vérifier tous les codes de raison. Par exemple, certains environnement sont seulement concernés par cACompromise et keyCompromise pour les certificats CA. Cet algorithme vérifie tous les codes de raison. Un traitement et des variables d'état additionnel peuvent être nécessaires pour limiter la vérification d'un sous-jeu de codes de raison.

Traitement de CRL

   Cet algorithme commence par supposer que le certificat n'est pas révoqué. L'algorithme vérifie une ou plusieurs CRL jusqu'à ce que soit le statut du certificat est déterminé être révoqué soit que suffisamment de CRL ont été vérifiée pour couvrir tous les codes de raison.

   Pour chaque point de distribution dans l'extension de points de distribution de CRL du certificat, pour chaque CRL correspondant dans le cache de CRL local, tant que ((reasons_mask n'est pas all-reasons) et (cert_status est UNREVOKED)), effectue les étapes suivantes:

(a) Met à jour le cache de CRL local en obtenant une CRL complète, une CRL delta, ou les 2:

        (1) Si la date courante est après la valeur du champ nextUpdate de la CRL, effectue une des étapes suivantes:

                (i) Si use-deltas et mis et que soit le certificat ou la CRL contient l'extension freshest CRL, obtient une CRL delta avec la valeur nextUpdate qui est après la date courante et peut être utilisée pour mettre à jours la CRL en cache local.
                (ii) Met à jour le cache de CRL local avec une CR complète courante, vérifie que la date courante est avant le champ nextUpdate dans la nouvelle CRL. Si use-deltas est mis et soit le certificat soit la CRL contient l'extension freshest CRL, obtient la CRL delta courante qui peut être utilisée pour mettre à jours la nouvelle CRL complète en cache.

        (2) Si la date courante est avant la valeur du champ nextUpdate, use-deltas est mis, et soit le certificat ou la CRL contient l'extension freshest CRL, puis obtient la CRL delta courante qui peut être utilisée pour mettre à jour la CRL complète en cache.

(b) Vérifie le fournisseur et le scope de la CRL complète comme suit:

        (1) Si le point de distribution (DP) inclus cRLIssuer, alors vérifie que le champ issuer dans la CRL complète correspond au cRLIssuer dans le DP et que la CRL complète contient une extension de point de distribution de fournisseur avec le booléen indirectCRL inséré. Sinon, vérifie que le fournisseur de CRL correspond au fournisseur de certificat.
        (2) Si la CRL complète inclus une extension de point de distribution de fournisseur (IDP), vérifie les étapes suivante:

                (i) Si le nom du point de distribution est présent dans l'extension de CRL IDP et que le champ de distribution est présent dans le DP, alors vérifie qu'un des noms dans le IDP correspond à un des noms dans le DP. Si le point de distribution est présent dans l'extension de CRL IDP et que le champ distribution est omis du DP, vérifie qu'un des noms dans le IDP correspond à un des noms dans le champ cRLIssuer du DP.
                (ii) Si le booléen onlyContainsUserCerts est mis dans l'extension de CRL IDP, vérifie que le certificat n'inclus pas l'extension de contrainte de base avec le booléen cA mis.
                (iii) Si le booléen onlyContainsCACerts est mis dans l'extension de CRL IDP, vérifie que le certificat inclus l'extension de contraintes de base avec le booléen cA mis.
                (iv) Vérifie que le booléen onlyContainsAttributeCerts n'est pas mis.

(c) Si use-deltas est mis, vérifie le fournisseur et le scope de la CRL delta comme suit:

        (1) Vérifie que le fournisseur de CRL delta correspond au fournisseur de CRL complète.
        (2) Si la CRL complète inclus une extension de CRL IDP, vérifie que la CRL delta contient une extension de CRL IDP correspondant à l'extension de CRL IDP. Si la CRL complète omet une extension de CRL IDP, vérifie que la CRL delta omet également une extension de CRL IDP.
        (3) Vérifie que l'extension d'identifiant de clé d'autorité de CRL delta correspond à l'extension d'identifiant de clé d'autorité de la CRL complète.

(d) Calcule interim_reasons_mask pour cette CRL comme suit:

        (1) Si l'extension de CRL IDP est présent et inclu onlySomeReasons et que DP inclus des raisons, définis interim_reasons_mask à l'intersection des raisons dans le DP et onlySomeReasons dans l'extension de CRL IDP.
        (2) Si l'extension de CRL IDP inclus onlySomeReasons mais que DP omet les raisons, alors définis interim_reasons_mask à la valeur de onlySomeReasons dans l'extension de CRL IDP.
        (3) Si l'extension de CRL IDP n'est pas présente ou omet onlySomeReasons mais que DP inclus des raisons, définis interim_reasons_mask à la valeur de reasons DP.
        (4) Si l'extension de CRL IDP n'est pas présente ou omet onlySomeReasons et que DP omet les raisons, définis onlySomeReasons à la valeur spéciale all-reasons.

(e) Vérifie que interim_reasons_mask inclus une ou plusieurs raisons qui ne sont pas inclus dans le reasons_mask.
(f) Obtient et valide le chemin de certification pour le fournisseur de CRL complète. L'ancre de confiance pour le chemin de certification doit être la même que l'ancre de confiance utilisée pour valider le certificat cible. Si une extension d'utilisation de clé est présente dans le certificat du fournisseur de CRL, vérifie que le bit cRLSign est mis.
(g) Valide la signature dans le CRL complète en utilisant la clé publique validée dans l'étape (f).
(h) Si use-delta est mis, valide la signature dans la CRL delta en utilisant la clé publique validée dans l'étape (f)
(i) Si use-deltas et mis, alors recherche le certificat dans la CRL delta. Si une entrée est trouvée qui correspond au fournisseur de certificat et numéro de série, met la variable cert_status à la raison indiquée comme suit:

        (1) Si l'extension d'entrée de CRL de code de raison est présent, définis la variable cert_status à la valeur de l'extension d'entrée de CRL de code de raison.
        (2) Si l'extension d'entrée de CRL de code de raison n'est pas présent, définis va variable cert_status à la valeur unspecified.

(j) Si (cert_status est UNREVOKED), alors cherche le certificat dans la CRL complète. Si une entrée est trouvée qui correspond au fournisseur et numéro de série du certificat, définis la variable cert_status à la raison indiquée comme décris dans l'étape (i).
(k) Si (cert_status est removeFromCRL), définis cert_status à UNREVOKED.
(l) Définis la variable d'état reasons_mask à l'union de ses précédentes valeurs et de la valeur de la variable d'état interim_reasons_mask.

   Si ((reason_mask est all-reasons) OU (cert_status n'est pas UNREVOKED)), le status de révocation a été determiné, donc retourne cert_status.

   Si le status de révocation n'a pas été déterminé, répète le processus avec toutes les CRL disponible non spécifiées dans un point de distribution, mais fournis par le fournisseur e certificat. Pour le traitement de telles CRL, assume un DP avec champs reasons et cRLIssuer omis et un nom de point de distribution du fournisseur de certifiat. C'est à dire la séquence de noms dans fullName est générée depuis le champ issuer du certificat aussi bien que l'extension issuerAltName du certificat. Après traitement de telles CRL, si le status de révocation n'a pas été déterminé, retourne cert_status à UNDETERMINED.

Traitement des règles pour les noms internationalisés

   Les noms internationalisés peuvent être rencontrés dans de nombreux champs et extensions de certificat et de CRL, incluant des noms distinct, noms de domaine internationalisés, adresses de messagerie électronique, et IRI. Le stockage, comparaison, et présentation de tels noms nécessite un attention particulière. Certains caractères peuvent être encodés de plusieurs manières. Les même nom peuvent être représentés dans plusieurs encodage. Cette section établis les pré-requis de conformité pour le stockage ou la comparaison de chacune de ces formes de nom.

Noms internationalisés dans les noms distinct

   Les attribut de nommage standard tels les noms communs, employent le type DirectoryString, qui supporte les noms internationalisés via une variété d'encodage de langues. Les implémentation conformes doivent supporter UTF8String et PrintableString. La rfc3280 requière seulement une comparaison binaire des valeurs d'attributs encodés en UTF8String, cependant, cette spécification requière une manipulation plus compréhensible. Les implémentations peuvent rencontrer des certificats et des CRL avec des noms encodés en utilisant TeletexString, BMPString, ou UniversalString, mais leur support est optionnel.

   Les implémentations conformes doivent utiliser le profile LDAP StringPrep (rfc4518) comme base pour la comparaison des attributs de noms distinct encodés avec PrintableString ou UTF8String. Les implémentations conforme doivent supporter la comparaison de noms en utilisant caseIgnoreMatch. Le support pour les types d'attributs qui utilisent d'autres règles de correspondance d'égalité est optionnel.

   Avant de comparer les noms en utilisant la règle de correspondance caseIgnoreMatch, les implémentation doivent effectuer l'algorithme de conformité en 6 étapes décrit dans la rfc4518 pour chaque attribut de type DirectoryString, avec les clarifications suivantes:

- Dans l'étape 2, le mapparge devrait inclure de cas spécifié dans la rfc3454 Appendix B.2.
- Dans l'étape 6, La suppression des caractères insignifiant, effectue la compression des espaces blanc comme spécifié dans la section Insignificant Space Handling de la rfc 4518.

   En effectuant l'algorithme de préparation de chaîne, les attributs doivent être traités comme valeurs stockées.

   2 attributs de nommage correspondent si les types d'attributs sont les même et les valeurs des attributs sont un exact match après traitement avec l'algorithme de préparation de chaîne. 2 noms distincts relatifs RDN1 et RDN2 correspondent s'ils ont le même nombre d'attributs de nommage pour chaque attribut de nommage dans RDN1, il y a un attribut de nommage correspondant dans RDN2, et les RDN apparaissent dans le même ordre. Un DN1 est dans le subtree définis dans DN2 si DN1 contient au moins autant de RDN que DN2, et DN1 et DN2 correspondent quand les DNS restants dans DN1 sont ignorés.

Noms de domaine internationalisés dans GeneralName

   Les noms de domaine internationalisés (IDN) peuvent être inclus dans les certificats et les CRL dans les extensions subjectAltName et issuerAltName, les extensions de contraintes de nom, extensions d'accès aux informations d'autorité, extensions d'accès aux informations du sujet, extensions de point de distribution de CRL, et les extensions de point de distribution de fournisseur. Chacune de ces extensions utilise le type GeneralName; Un choix dans GeneralName est le champ dNSName, qui est définis comme type IA5String.

   IA5String est limité au jeu de caractères ASCII. Pour adapter les noms de domaine internationalisés dans la structure courante, les implémentations conformes doivent convertir les noms de domaine internationalisés au format ASCII Compatible Encoding (ACE) comme spécifié dans la rfc 3490 avant de stocker le champ dNSName. Spécifiquement, les implémentations conformes doivent effectuer les opérations de conversion spécifiés dans la rfc 3490, avec les clarifications suivantes:

- Dans l'étape 1, le nom de domaine devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.
- Dans l'étape 3, définis le flag appelé "UseSTD3ASCIIRules"
- Dans l'étape 4, traite chaque label avec l'opération "ToASCII"
- Dans l'étape 5, change tous les séparateurs de label à U+002E.

   En comparant les noms DNS pour l'égalité, les implémentations conforme doivent effectuer une correspondance sensible à la casse exacte sur tout le nom DNS. En évaluant les contraintes de nom, les implémentations conformes doivent effectuer une correspondance sensible à la casse exacte sur une base label par label. Comme spécifié dans la section "name constraints", tous nom DNS que peut être construit en ajoutant des labels à gauche du nom de domaine donné comme contrainte est considéré être dans le subtree indiqué.

   Les implémentations devraient convertir les IDN en Unicode avant affichage. Spécifiquement, les application conformes devraient effectuer l'opération de conversion spécifiée dans la rfc3490, avec les clarifications suivante:

- Dans l'étape 1, le nom de domaine devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.
- Dans l'étape 3, définis le flag appelé "UseSTD3ASCIIRules"
- Dans l'étape 4, traite chaque label avec l'opération "ToUnicode"
- Saute l'étape 5.

   Note: les implémentations doivent autoriser l'augmentation de l'espace requis pour les IDN. Un label IDN ACE va commencer avec les 4 caractères additionnels "xn--" et peut nécessiter jusqu'à 5 caractères ASCII pour spécifier un simple caractère internationalisé.

Noms de domaine internationalisés dans les noms distincts

   Les noms de domaine peuvent également être représentés en noms distinct, en utilisant des composantes domaine dans le champ subject, issuer, l'extension subjectAltName, ou issuerAltName. Comme avec dNSName dans le type GeneralName, la valeur de cet attribut est définis comme IA5String. Chaque attribut domainComponent représente un simple lable. Pour représenter un label depuis un IDN en nom distinct, l'implémentation doit effectuer la conversion de label "ToASCII" spécifié dans la rfc3490. Le label devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.

   Les implémentations conformes devraient convertir les labels ACE en Unicode avant affichage. Spécifiquement, les implémentations conformes devraient effectuer l'opération de conversion "ToUnicode" spécifiée dans la rfc3490, sur chaque label ACE avant affichage.

Identifiants de ressources internationalisés

   Les IRI sont le complément internationalisé des URI. Les IRI sont des séquences de caractères Unicode, alors que les URI sont des séquences de caractères ASCII. La rfc3987 définis un mappage des IRI en URI. Bien que les IRI ne sont pas encodés directement dans les champs et extensions de certificat et CRL, leur version mappé URI peuvent êrte inclus dans les certificats et CRL. Les URI peuvent apparaître dans les extensions subjecAltName, issuerAltName, contraintes de noms, accès aux informations de l'autorité, accès aux informations du sujet, point de distribution de fournisseur et de CRL. Chacune de ces extensions utilisent le type GeneralName, les URI sont encodés dans le champ uniformResourceIdentifier dans GeneralName, qui est défini en type IA5String.

   Pour représenter les IRI dans la structure courante, les implémentations courantes doivent mapper les IRI en URI comme spécifiés dans la rfc 3987, avec les clarifiations suivantes:

- Dans l'étape 1, génère une séquence de caractère UCS du format IRI original normalisant en accord au NFC comme spécifié dans la variante b
- Effectue l'étape 2 en utilisant la sortie de l'étape 1.

   Les implémentations ne doivent pas convertir le composant ireg-name avant d'effectuer l'étape 2.

   Avant que les URI puissent être comparés, les implémentations conformes doivent effectuer une combinaison des techniques de normalisation basé sur la syntaxe et sur le schéma décris dans la rfc3987. Spécifiquement, les implémentations conformes doivent préparer les URI pour les comparaisons comme suit:

Étape 1 Quand les IRI permettent l'utilisation d'IDN, ces noms doivent être convertis en ACE comme spécifié plus haut
Étape 2 Le schéma et l'hôte sont normalisés en minuscule comme spécifié dans la rfc3987
Étape 3 Effectue une normalisation percent-encoding, comme spécifié dans la rfc3987
Étape 4 Effectue une normalisation de segment de chemin, comme spécifié dans la rfc3987
Étape 5 Si reconnus, L'implémentation doit effectuer une normalisation basée sur le schéma, comme spécifié dans la rfc3987

   Les implémentations conformes doivent reconnaître et effectuer une normalisation basée sur les schéma pour les schéma suivant: ldap, http, https, et ftp. Si le schéma n'est pas reconnu, l'étape 5 est omise.

   En comparant les URI pour l'équivalence, les implémentations conformes devraient effectuer une correspondance d'égalité sensible à la casse.. Les implémentations devraient convertir les URI en Unicode avant affichaqe.

Adresses de messagerie électronique internationalisées

   Les adresses de messagerie électronique peuvent être inclus dans les certificats et les CRL dans les extension subjecAltName et issuerAltName, contraintes de noms, accès aux information d'autorité et du sujet, et point de distribution du fournisseur et de CRL. chacune de ces extensions utilise la construction GeneralName; GeneralName inclus rfc822Name, qui est définis comme type IA5String. Pour spécifier des adresses email avec des noms de domaine internationalisés en utilisant la structure courante, les implémentations conforme doivent convertir les adresses en représentation ASCII.

   Quand la partie hôte (le domaine de la boîte mail) contient un nom internationalisé, le nom de domaine doit être convertis depuis un IDN en ACE. 2 adresses email correspondent si:

1) La partie locale du chaque nom est un exact match, et
2) la partie hôte de chaque nom correspond en utilisant une comparaison ASCII insensible à la casse.

   Les implémentations devraient convertir la partie hôte des adresses email internationalisés spécifiés dans ces extension en Unicode avant affichage. Spécifiquement, les implémentations conformes devraient effectuer la conversion de la partie hôte de la boîte mail comme décris dans la section des IDN dans GeneralName.

Considérations de sécurité

   Vu que les certificats et les CRL sont signés numériquement, aucun service d'intégrité additionnel n'est nécessaire, ni de conserver les certificats ou les CRL secrets, et les accès non-restreins et anonymes aux certificats et CRL n'a pas d'implication de sécurité.

   Cependant, des facteurs de sécurité en dehors du scope de cette spécification affectent l'assurance fournie par les certificats utilisateurs. Cette section met en avant les problèmes de sécurité hautement critique à considérer par les implémenteurs, administrateurs et les utilisateurs.

   L'utilisation d'une simple paire de clé pour la signature et d'autres buts est fortement découragée. L'utilisation de paires de clé séparés pour la signature et la gestion de clé fournis de nombreux bénéfices aux utilisateurs. Les ramifications associées avec la pertes ou la divulgation d'une clé de signature sont différents de la perte ou la divulgation d'une clé de gestion de clé. Utiliser des paires de clé différente permet une réponse balancée et différente. Similairement, différentes périodes de validité ou longueur de clé pour chaque paire de clé peuvent être approprié dans certains environnements. Malheureusement, certaines applications utilisent une simple paire de clé pour la signature et la gestion de clé.

   La protection des clés privées conférée aux clés privées est un facteur critique. À petite échelle, les utilisateurs qui ne protègent pas leurs clés privée va permettre à un attaquant de les usurper ou déchiffrer leurs informations personnelles. À plus grande échelle, la clé privée de signature d'une CA compromise peut avoir un effet catastrophique. Si un attaquant obtient une clé privée, il peut émettre de faux certificats et CRL. L'existance de faux certificats et CRL va détruire la confidence dans le système. Si un tel compromis est détecté, tous les certificats émis par la CA compromise doivent être révoqués, bloquant les services entre ses utilisateurs et les utilisateurs d'autres CA. Reconstruire après un tel compromis sera problématique, donc les CA doivent implémenter une combinaison de mécanismes fort et de procédures de gestion appropriés (ex: séparation des privilèges) pour éviter un incident.

   La perte d'une clé de signature privée de CA peut également être problématique. La CA ne sera pas capable de produire de CRL ou d'effectuer des remplacements de clé. Les CA devraient maintenir une sauvegarde sûre pour les clés de signature. La sécurité des procédures de sauvegarde de clé est un facteur critique pour éviter la compromission de clé.

   La disponibilité des informations de révocation affecte le degré d'assurance qui est placé dans un certificat. Bien que les certificats expirent naturellement, des évènements peuvent se produire durant sa durée de vie qui supprime la liaison entre le sujet et sa clé publique. Si l'information de révocation n'est pas disponible, l'assurance avec la liaison est clairement réduite. Les parties de confiance peuvent ne pas être capable de traiter toutes les extensions critiques qui peuvent apparaître dans une CRL. Les CA devraient faire très attention créant des informations de révocation uniquement disponibles via des extensions critiques, particulièrement si le support pour ces extensions n'est pas mandaté par ce profile.

   Par exemple, si les informations de révocation sont fournis en utilisant une combinaison de CRL delta et le CRL complètes, et que la CRL delta est fournie plus fréquemment que les CRL complètes, les parties de confiance qui ne peuvent pas manipuler les extensions critiques liées au traitement de la CRL delta ne seront pas capable d'obtenir les informations de révocations les plus récentes. Alternativement, il une CRL complète est fournis au même moment qu'une CRL delta, Les informations de révocation seront disponibles à toutes les parties. Similairement, les implémentations du mécanisme de validation de chemin de certification qui omettent la vérification de révocation fournissent moint d'assurance qui celles qui le supporte.

   L'algorithme de validation de chemin de certification dépend de la connaissance des clé publiques ( et autres informations ) sur une ou plusieurs CA de confiance. La décision de la confiance en un CA est une décision importante vu qu'elle détermine la confiance accordée à un certificat. La distribution authentifiée de clés publique de CA (généralement sous la forme de certificat auto-signé) est un processus à part critique qui est en dehors de cette spécification.

   En plus, quand une clé est compromise ou qu'une CA en peut plus être de confiance, l'utilisateur doit modifier les informations fournies à la routine de validation de chemin. Sélectionner trop de CA de confiance rend cette maintenance difficile.

   La qualité des implémentations qui traitent les certificats affectent également le degré d'assurance fournis. L'algorithme de validation de chemin s'assure de l'intégrité des informations de CA de confiance, et spécialement l'intégrité des clés publiques associées avec ces CA. En substituant les clés publiques pour lequel un attaquant a la clé privée lui permet de faire accepter de faux certificats à un utilisateur.

   La liaison entre une clé et le sujet du certificat ne peut pas être plus fort que l'implémentation du module cryptographique et des algorithmes utilisés pour générer la signature. Des longueurs de clé courtes ou des algorithmes de hashage faible limitent l'utilité des certificats. Les CA sont encouragés à noter les progrès en cryptologie afin d'employer des techniques cryptographiques fortes. De plus, les CA devraient refuser de fournir des certificats à de CA ou des entités finales qui génèrent des signatures faibles.

   Une application inconsistante de règle de comparaison de nom peut résulter dans l'acceptation de chemins de certification invalides ou le rejet de chemins valides. Les séries de spécification X.500 définissent des règles pour comparer les noms distincts qui nécessitent la comparaison de chaînes sans regarder là casse, le jeu de caractère, espaces blancs multi-caractères, ou espaces blancs en début ou fin. Cette spécification relaxe ces requis, nécessitant le support d'une comparaison binaire au minimum.

   Les CA doivent encoder les noms distinct dans le champ sujet d'un certificat CA identiquement au nom distinct dans le champ issuer dans les certificats fournies par cette CA. Si les CA utilisent des encodages différents, les implémentations peuvent échouer à reconnaître les chaînes de nom pour les chemins qui incluent ce certificat. En conséquence, les chemins valides pourraient être rejetés.

   En plus, les contraintes de nom pour les noms distincts doivent être identiques à l'encodage utilisé dans le champ subjet ou l'extension subjectAltName. Sinon, les contraintes de noms définis comme excludedSubtrees ne matcheront pas et les chemins invalides seront acceptés et les contraintes de noms exprimés comme permittedSubtrees ne vont pas matcher et les chemins valides seront rejeter. Pour éviter d'accepter les chemins invalides, les CA devraient définir les contraintes de noms pour les noms distincts comme permittedSubtrees si possibles.

   En général, utiliser l'extension nameConstraints pour contraindre une forme de nom n'offre pas de protection contre l'utilisation d'autre formes de nom.

   Bien que X.509 mandate que les noms soient non ambigus, il y a un risque que 2 autorités non liées fournissent des certificats et/ou des CRL sous le même nom de fournisseur. Un moyen de réduire ces problèmes et les problèmes de sécurité liés aux collisions de nom de fournisseur, les noms de CA et de fournisseurs de CRL devraient être formé d'une manière qui réduit la probabilité des collisions de noms. Les implémenteurs devraient prendre en compte l'existence possible de multiples CA et fournisseurs de CRL avec le même nom. Au minimum, les implémentations validant les CRL doivent s'assurer que le chemin de certification d'un certificat et du chemin de certification du fournisseur de CRL utilisés pour valider ce certificat se terminent à l'ancre de confiance.

   Bien que la partie locale d'une adresse de messagerie électronique est sensible à la casse, les valeurs de l'attribut emailAddress sont insensibles à la casse. Il y un risque que 2 adresses emails différentes soient traitées comme des adresse identiques. Les implémenteurs ne devraient pas inclure une adresses email dans l'attribut emailAddress si le serveur de messagerie traite la partie locale des adresses email comme sensible à la casse.

   Les implémenteurs devraient s'assurer des risques liés si les points de distribution de CRL ou les extensions d'accès aux informations d'autorité de certificats ou de CRL corrompus contiennent les liens vers du code malicieux. Les implémenteurs devraient toujours prendre les étapes consistant à valider les données extraites afin de s'assurer que les données sont correctement formées.

   Quand les certificats incluent une extension cRLDistributionPoints avec une URI https ou un schéma similaire, des dépendances circulaires peuvent être introduits. Le tier de confiance est forcé d'effectuer une validation de chemin additionnel pour obtenir la CRL requise pour compléter la validation de chemin initiale. Des conditions similaires peuvent égalemente être créés avec une URI https dans les extensions authorityInfoAccess ou subjectInfoAccess.

   Les CA ne devraient pas inclure d'URI qui spécifient https, ldaps, ou des schémas similaires dans les extensions. Les CA qui incluent une de ces extension doivent s'assurer que le certificat du serveur peut être validé dans utiliser d'informations pointé par l'URI. Les tiers de confiance qui choisissent de valider le certificat du serveur en obtenant les informations pointés par une URI https dans les extensions cRLDistributionPoints, authorityInfoAccess, ou subjectInfoAccess doivent être préparés pour cette possibilité.

   Les certificats auto-fournis fournissent des CA avec un mécanisme automatisé pour indiques les changements dans les opération de la CA. En particulier, les certificat auto-signés peuvent être utilisés pour implémenter un changement de paire de clé non-compromis à un autre. Les procédures détaillée pour la mise à jours de clé de CA sont spécifiés dans la rfc4210, où la CA protège sa nouvelle clé publique en utilisant sa précédente clé privée et vice versa en utilisa 2 certificats auto-fournis. Les implémentations client conformes vont traiter le certificat auto-signé et déterminer si les certificats fournis sous la nouvelle clé peut être trusté. Les certificats auto-fournis peuvent être utilisé pour supporter d'autres changements dans les opérations de CA, tel que l'ajout de stratégies, en utilisant des procédures similaires.

   Certaines anciennes implémentations supportent les noms encodés en ISO 8859-1 (Latin1String) mais les tag en TeletexString. TeletexString encode un jeu de caractère plus grand que ISO 8859-1, mais il encode certains caractères différemment. Les règles de comparaison spécifiée plus haut assument que les TeletexStrings sont encodés comme décris dans le standard ASN.1. En comparant les noms encodés en Latin1String, de faux positifs et négatifs sont possibles.

   Quand des chaînes sont mappées depuis des représentations interne vers de représentation visuelle, 2 chaînes différentes peuvent parfois avoir la même représentation visuelle. Cela peut se produire pour plusieurs raisons, incluant l'utilisation de glyphes similaires et l'utilisation de caractères composés. Les fournisseurs de certificats et les tiers de confiance doivent gérer cette situation.
^
21 décembre 2014

htmlpdflatexmanmd




rfc5755

rfc5755

Profil de certificat d'attribut Internet pour l'autorisation

Introduction

   Les certificats à clé publique X.509 (PKCs) lien une identité et une clé publique. Un certificat d'attribut (AC) est une structure similaire à PKC; la principale différence est que AC ne contient pas de clé publique. Un AC peut contenir des attributs qui spécifie l'appartenance à un groupe, un rôle, habilitation, ou d'autres informations d'autorisation associés avec le titulaire de l'AC.

   La syntaxe pour AC est définie dans Recommendation X.509, rendant le terme "X.509 Certificate' ambigus.

   Certaines personnes confondent constamment PKCs et ACs. Un analogie peut rendre la distinction plus claire. An PKC peut être considéré comme un passeport: il identifie le titulaire, tend à durer longtemps, et ne devrait pas être trivial à obtenir. Un AC est plus comme un visa d'entrée: il est typiquement utilisé par une autorité différente et ne dure pas très longtemps.

   Les informations d'autorisation peuvent être placés dans une extension PKC ou placé dans un certificat d'attribut séparé. Le placement des informations d'autorisation dans les PKCs est généralement indésirable pour 2 raisons. D'abord, les informations d'autorisation n'ont pas la même durée de vie que la liaison de l'identité et de la clé publique. Ensuite, le fournisseur PKC n'a généralement pas autorité pour les informations d'autorisation.

   Pour ces raisons, il est souvent meilleur de séparer les informations d'autorisation des PKC. Les informations d'autorisation doivent également être liées a une identité. Un AC fournis cette liaison; c'est simplement une identité signé ou certifiée numériquement et un jeu d'attributs.

   Un AC peut être utilisé avec divers services de sécurité, incluant le contrôle d'accès, authentification de l'origine des données, et la non-répudiation.

   les PKCs peuvent fournir une identité à des fonctions de contrôle d'accès. Cependant, dans de nombreux contextes, l'identité n'est pas le critère qui est utilisé pour les décisions de contrôle d'accès, mais plutôt le rôle ou l'appartenance à un groupe. De tels schémas de contrôles d'accès sont appelé RBAC.

   En créant des décisions de contrôle d'accès basé sur un AC, une fonction de décision de contrôle d'accès peut nécessiter de s'assurer que le titulaire de l'AC approprié est l'entité qui a demandé l'accès. Une manière de lier la demande ou l'identité et l'AC peut être accomplie par l'inclusion d'une référence à un PKC dans l'AC et l'utilisation de la clé privée correspondante au PKC pour l'authentification dans la demande d'accès.

   Les AC peuvent également être utilisés dans le contexte de service d'authentification de l'origine des données et de non-répudiation. Dans ces contextes, les attributs contenus dans l'AC fournis des informations additionnels sur l'identité du signataire. Cet information peut être utilisée pour s'assurer que l'identité est autorisée à signer la donnée. Ce genre de vérification dépend soit du contexte dans lequel la donnée est échangée soit sur la donnée qui a été signée numériquement.

Délégation de chemin d'AC

   Le standard X.509 définis l'autorisation comme le "transport de privilège d'une entité qui détient ce privilège, à une autre identité.". Un AC est un mécanisme d'autorisation.

   Une séquence ordonnée d'AC pourrait être utilisée pour vérifier l'authenticité des privilège du déclarant. De cette manière, les chaînes et chemins d'AC pourraient être employés pour déléguer l'autorisation.

   Vu que l'administration est le traitement associé avec de telles chaînes AC est complexe et que l'utilisation des AC dans l'Internet aujourd'hui est limitée, il est recommandé que les implémentations de cette spécification n'utilisent pas les chaînes d'AC. D'autres futures spécifications peuvent adresser l'utilisation de chaînes d'AC. Cette spécification s'occupe de cas simples, où une autorité gère tous les AC pour un jeu d'attributs particuliers. Cependant, cette simplification n'exclus par l'utilisation de plusieurs autorités différentes, chacune d'entre elles gérant un jeu d'attributs différents. Par exemple, l'appartenance à un groupe peut être inclus dans un AC fournis par une autorité, et les habilitations de sécurité peuvent être inclus dans un autre AC par une autre autorité.

   Cela signifie que les implémentations conformes doivent seulement être capable de traiter un simple AC à la fois. Le traitement de plus d'un AC, un après l'autre, peut être nécessaire. Noter cependant, que la validation d'un AC peut nécessiter une validation d'une chaîne de PKCs.

Distribution de certificat d'attributs

   Comme discuté plus haut, les AC fournissent un mécanisme pour fournir de manière sécurisé des informations d'autorisation pour, par exemple, des fonctions de décision de contrôle. Cependant, il y a un nombre de chemins de communication possible pour les AC.

   Dans certains environnements, il est possible pour un client de "pousser" un AC à un serveur. Cela signifie qu'il n'y a pas de nouvelle connexion entre le client et le serveur. Ce la signifie également qu'aucune charge de recherche n'est imposée sur les serveurs, ce qui améliore les performances et le vérificateur d'AC est seulement présenté avec ce que l'on a besoin de connaître. Le modèle "push" est préférable spécialement dans les cas inter-domaines où les droits des client devraient être assignés dans le domaine du client.

   Dans d'autres cas, il est préférable pour un client de simplement s'authentifier auprès du serveur et de lui demander ( "pull" ) l'AC du client depuis un fournisseur d'AC. Un bénéfice majeur est du modèle "pull" est qu'il peut être implémenté sans changements sur le client ou dans le protocole. Le modèle "pull" est préférable spécialement pour les cas inter-domaines où les droits du client devraient être assignés dans le domaine du serveur.

   Il y a un certain nombre d'échanges possibles impliquant 3 entités: Le client, le serveur, et le fournisseur d'AC. En plus, un service d'annuaire ou d'autres annuaire pour la récupération d'AC peuvent être supportés.

La Figure 1 montre un vue abstraite des échanges qui peuvent se produire. Ce profile ne spécifie pas de protocole pour ces échanges:
______+--------------+__________________________________________
______|______________|________Server_Acquisition________________
______|__AC_issuer___+‹---------------------------+_____________
______|______________|____________________________|_____________
______+--+-----------+____________________________|_____________
_________^________________________________________|_____________
_________|_Client_________________________________|_____________
_________|_Acquisition____________________________|_____________
_________v________________________________________v_____________
______+--+-----------+_________________________+--+------------+
______|______________|_______AC_"push"_________|_______________|
______|___Client_____+‹------------------------|____Server_____|
______|______________|_(part_of_app._protocol)_|_______________|
______+--+-----------+_________________________+--+------------+
_________^________________________________________^_____________
_________|_Client_________________________________|_Server______
_________|_Lookup________+--------------+_________|_Lookup______
_________|_______________|______________|_________|_____________
_________+--------------›+__Repository__+‹--------+_____________
_________________________|______________|_______________________
_________________________+--------------+_______________________
_
____________________________Figure_1:_AC_Exchanges______________

Terminologie

   Par simplicité, on utilise les termes client et serveur dans cette spécification. Cela n'est pas prévu pour indiquer que les AC sont seulement utilisé dans des environnements client/serveur. Par exemple, les AC peuvent être utilisé dans un contexte S/MIME v3.2, où le MUA serait à la fois client et serveur dans le sens des termes utilisés ici.

AA Attribute Autority, l'entité qui fournis l'AC, synonyme dans cette spécification avec "fournisseur de CA"
AC Attribute Certificate
AC user Une entité qui parse ou traite un AC
AC verifier Une entité qui vérifie la validité d'un AC et utilise le résultat
AC issuer L'entité qui signe l'AC: synonyme de AA
Client L'entité qui demande l'action pour laquelle les vérifications d'autorisation doivent êtes faites
Proyxing Dans cette spécification, le proxying est utilisé pour signifier la situation où un serveur d'application agit comme application cliente à la demande de l'utilisateur.
PKC Public Key Certificates - utilise les certificats de type ASN.1 définis dans X.509 et profilé dans la rfc5280.
Server L'entité qui nécessite qu'une vérification d'autorisation soit faite.

Pré-requis

   Ce profile AC à les pré-requis suivants:

1. Support pour les AC à durée de vie courte et longue. Une période de validité courte typique peut se mesurer en heures, en mois pour les PKC. Les périodes de validité courtes permettent aux AC d'être utiles sans mécanisme de révocation.
2. Les fournisseurs d'AC devraient être capable de définir leur propres types d'attributs à utiliser dans les domaines fermés.
3. Certains types d'attributs standard, qui peuvent être contenus dans les AC devraient être définis. Par exemple "access identity", "group", "role", "clearance", "audit identity", et "charging identity".
4. Les type d'attributs standard devraient être définis d'une manière qui permette à un AC verifier de distinguer l'utilisation de mêmes attributs dans des domaines différents. Par exemple, "Administrators group" comme définis par "Baltimore" et "Administrators group" définis par "SPYRUS" devraient être facilement distincts.
5. Il devrait être possible de cibler un AC à un ou un petit nombre de serveurs. Cela signifie qu'un serveur non-ciblé sera rejeté par les décisions d'autorisation d'AC.
6. Les AC devaient être définis pour qu'il puissent être soit "pushed" par le client au serveur, ou "pulled" par le serveur depuis un dépôt ou un service réseaux, incluant un fournisseur d'AC online.

Profile de certificat d'attribut

   Les AC peuvent être utilisés dans un large éventail d'applications et d'environnements, couvrant un large spectre de besoins opérationnels et d'assurances. Le but de ce document est d'établir une base commune pour des applications génériques nécessitant une grande interopérabilité et des besoins spéciaux limités. En particulier, l'accent sera mis sur le support de l'utilisation de certificats d'attributs pour les messages électroniques, IPsec, et les applications www.

   Cette section présente un profile pour les AC qui va favoriser l'interopérabilité. Cette section définis également certaines extensions pour la communauté internet.

  Alors que les documents ISO/IEC/ITU utilisent la version 1993 (ou ultérieur) de ASN.1, ce document utilise la syntaxe ASN.1 1988, comme pour les PKCs.

Définition de certificat d'attribut X.509

X.509 contient la définition d'un AC donné ci-dessous. Tous les types qui ne sont pas définis dans ce document peuvent être trouvés dans la rfc 5280.
AttributeCertificate ::= SEQUENCE {
    acinfo AttributeCertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}
    
AttributeCertificateInfo ::= SEQUENCE {
    version AttCertVersion, -- version is v2
    holder Holder,
    issuer AttCertIssuer,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attrCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL
}
    
AttCertVersion ::= INTEGER { v2(1) }
    
Holder ::= SEQUENCE {
    baseCertificateID [0] IssuerSerial OPTIONAL,
        -- le issuer et serial number du titulaire du certificat à clé publique
    entityName [1] GeneralNames OPTIONAL,
        -- le nom du demandeur ou du rôle
    objectDigestInfo [2] ObjectDigestInfo OPTIONAL
        -- Utilisé pour authentifier directement le titulaire, par exemple, un exécutable.
}
    
ObjectDigestInfo ::= SEQUENCE {
    digestedObjectType ENUMERATED {
        publicKey (0),
        publicKeyCert (1),
        otherObjectTypes (2) },
    -- otherObjectTypes ne doit pas être utilisé dans ce profile
    otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
    digestAlgorithm AlgorithmIdentifier,
    objectDigest BIT STRING
}
    
AttCertIssuer ::= CHOICE {
    v1Form GeneralNames, -- ne doit pas être utilisé dans ce profile
    v2Form [0] V2Form -- v2 only
}
    
V2Form ::= SEQUENCE {
    issuerName GeneralNames OPTIONAL,
    baseCertificateID [0] IssuerSerial OPTIONAL,
    objectDigestInfo [1] ObjectDigestInfo OPTIONAL
        -- issuerName doit être présent dans ce profile
        -- baseCertificateID et objectDigestInfo ne doivent pas être présents dans ce profile
}
    
IssuerSerial ::= SEQUENCE {
    issuer GeneralNames,
    serial CertificateSerialNumber,
    issuerUID UniqueIdentifier OPTIONAL
}
    
AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime GeneralizedTime,
    notAfterTime GeneralizedTime
}

Bien que la syntaxe d'attribut soit définis dans la rfc 5280, on répète la définition ici par commodité:
Attribute ::= SEQUENCE {
    type AttributeType,
    values SET OF AttributeValue
        -- Au moins une valeur est requise
}
    
AttributeType ::= OBJECT IDENTIFIER
    
AttributeValue ::= ANY DEFINED BY AttributeType

   Les implémenteurs devraient noter que l'encodage DER des valeurs de jeu nécessitent d'ordonner l'encodage des valeurs. Bien que cette question se pose avec les dn, et doit être géré avec l'implémentation rfc 5280, il est plus important dans ce contexte, vu que les valeurs multiples sont plus courantes dans les AC.

Profile des champs standards

   GeneralName offre une grande flexibilité. Pour parvenir à l'interopérabilité, en dépit de cette souplesse, ce profile impose des contraintes à l'utilisation de GeneralName.

   Les implémentations doivent être capable de supporter dNSName, directoryName, uniformResourceIdentifier, et iPAddress. C'est compatible avec les pre-requis de GeneralName dans la rfc 5280. Les implémentations doivraient également supporter SRVName, et ne doivent pas utiliser x400Address, ediPartyName et registeredID.

   Les implémentations peuvent utiliser otherName pour transmettre les formes de nom définis dans les standards Internet. Par exemple, le format kerberos des noms peut être encodé dans otherName, en utilisant l'OID du nom principal kerberos v5 et une séquence de domaine et du PrincipalName.

Version

   Le champ version doit avoir la valeur v2. Le champ version est présent dans l'encodage DER.

  Note: cette version n'est pas compatible avec les précédentes définition des certificats d'attribut du standard X.509-1997, mais est compatible avec la définition v2 X.509-2000.

Holder

   Le champ Holder est une séquence permettant 2 syntaxes optionnelles différentes: baseCertificateID, entityName, et objectDigestInfo. Où seul une option est présente, la signification du champ Holder est claire.

   Cependant, quand plus d'une option est utilisée, il y a une confusion possible, laquelle est normative, laquelle est une allusion, etc. Vu que la position correcte n'est pas claire dans X.509-2000, cette spécification recommande que seule une de ces options soit utilisée dans un AC donné.

   Pour tout environnement où l'AC est passée dans un message authentifié ou une session et où l'authentification est basée sur l'utilisation d'un PKC X.509, le champ Holder devrait être le baseCertificateID.

   Avec l'option baseCertificateID, le serialNumber et issuer du PKC du titulaire doit être identique au champ Holder de l'AC. Le fournisseur PKC doit avoir un dn non vide qui doit être présent comme simple valeure de la construction holder.baseCertificateID.issuer dans le champ directoryName. Le champ holder.baseCertificateID.issuerUID de l'AC doit seulement être utilisé si le PKC du titulaire contient un champ issuerUniqueID. Si le champs holder.baseCertificateID.issuerUID de l'AC et le champ issuerUniqueID du PKC sont présents, la même valeur doit être présente dans ces 2 champs. Donc, baseCertificateID est seulement utilisable avec les profiles PKC qui mandatent que le champ issuer du PKC contient une valeur dn non-vide.

   Note: un dn vide est un dn où la séquence de dn relatifs à une longueur de 0. Dans un encodage DER, il a la valeur '3000'H.

   Si le champ Holder utilise l'option entityName et que l'authentification sous-jacent est basée sur un PKC, entityName doit être le même que le champ subject du PKC ou une des valeurs de subjectAltName du PKC ( si présent ). Noter que la rfc 5280 mandate que l'extension subjectAltName soit présente si le sujet du PKC est un dn vide.

   Dans tous les cas où le champ Holder utilise l'option entityName, seul un nom devrait être présent.

   Les implémentations se conformant à ce profile ne sont pas obligés de supporter l'utilisation du champ objectDigest.

   Tout protocole se conformant à ce profile devrait spécifier quel option de titulaire de l'AC doit être utilisé et comment cela s'intègre avec les schémas d'authentification supportés définis dans ce protocole.

Issuer

   Les AC se conformant à ce profile doivent utiliser le choix v2Form, qui doit contenir un et un seul GeneralName dans le issuerName, qui doit contenir un dn non-vide dans le champ directoryName. Cela signifie que tous les fournisseurs d'AC doivent avoir des noms distincts non-vide. Les AC se conformant à ce profile doivent omettre les champs baseCertificateID et objectDigestInfo.

   Une des raisons d'utiliser v2Form contenant seulement un issuerName et que cela le fournisseur n'a pas à connaître quel PKC l'AC verifier va utiliser. Utiliser le champ baseCertificateID pour référencer le fournisseur d'AC signifie que l'AC verifier doit faire confiance au PKC que le fournisseur d'AC choisis pour lui à la création de l'AC.

Signature

   Contient l'identifiant d'algorithme utilisé pour valider la signature AC. Doit être un des algorithmes de signature définis dans les rfc3279, rfc4055, rfc5480, et rfc5756, ou définis dans une mise à jour approuvée par l'ietf de ces rfc. Les implémentations conformes doivent honorer toutes les déclarations MUST/SHOULD/MAY des algorithmes de signature.

SerialNumber

   Pour tout AC conforme, la paire issuer/serialNumber doit former une combinaison unique, même si les AC ont une durée de vie très courte. Les fournisseurs d'AC doivent s'assure que le serialNumber est un nombre positif, qui est, le bit de signe dans l'encodage DER de la valeur integer doit être 0. Cela peut être fait en ajoutant un '00'H gauche si nécessaire. Cela supprime une ambiguïté dans le mappage entre une chaîne d'octets et une valeur entière.

   En donnant un timing et une unicité requise, les numéros de série peuvent contenir des entiers longs. Les utilisateurs d'AC doivent être capable de manipuler les valeurs de serialNumber supérieurs à 4 octets. Les AC conformes ne doivent pas contenir de valeurs serialNumber supérieurs à 20 octets.

   Il n'y a pas de pré-requis pour que le numéro de série utilisé par un fournisseur d'AC suive un ordre particulier. En particulier, ils nécessitent de ne pas être incrémentés monotoniquement avec le temp. Chaque fournisseur d'AC doit s'assurer que chaque AC qu'il fournis contient un numéro de série unique.

Période de validité

   Le champ attrCertValidityPeriod spécifie la période pour laquelle le fournisseur d'AC certifie que le lien entre le titulaire et les champs d'attributs sont valides.

   Le type GeneralizedTime est un type ASN.1 standard pour représenter le temps. Ce champ peut optionnellement inclure une représentation du temps différentiel entre la zone de temps local et GMT.

   Pour ce profile, les valeurs GeneralizedTime doivent être exprimés en UTC et doivent inclure les secondes (ex: YYYYMMDDHHMMSSZ), même quand le nombre de seconde est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

   Les utilisateurs d'AC doivent être capable de manipuler un AC que, au moment du traitement, a des parties de sa période de validité ou toute sa période de validité dans le passé ou dans le future. C'est valide pour certaines applications, tels que les backups.

Attributes

   Le champ attributes donne des informations sur le titulaire de l'AC. Quand l'AC est utilisé pour l'autorisation, il contient souvent un jeu de privilèges.

   Le champ attributes contient une séquence d'attributs. chaque attribut contient le type de l'attribut et un jeu de valeurs. Pour un AC donné, chaque identifiant d'object AttributeType dans la séquence doit être unique, mais peut être multi-valué.

   Les utilisateurs d'AC doivent être capable de manipuler plusieurs valeurs pour tous les types d'attributs. Un AC doit contenir au moins un attribut, c'est à dire une séquence d'Attributes de longueur non-zéro.

Issuer Unique Identifier

   Ce champ ne doit pas être utilisé à moins qu'il est également utilisé dans le PKC du fournisseur d'AC, auquel cas il doit être utilisé. Noter que la rfc5280 indique que ce champ ne devrait pas être utilisé par les autorités de certification conformes, mais ces applications devraient être capable de gérer les PKCs contenant ce champ.

Extensions

   Le champ extensions donne généralement des informations sur l'AC, en opposé aux informations sur le titulaire de l'AC.

   Un AC qui n'a pas d'extensions est conforme avec ce profile. Cependant les sections suivantes définissent des extensions qui peuvent être utilisé avec ce profile, et indique s'ils sont à marquer critiques. Si une autre extension critique est utilisé, l'AC n'est pas conforme à ce profile. Cependant, si une autre extension non-critique est utilisée, l'AC est conforme à ce profile.

   Les extensions définie pour les AC fournissent des méthodes pour associer les attributs additionnels avec les titulaires. Ce profile permet aux communautés de définir des extensions privées pour les informations unique à ces communautés. Chaque extension dans un AC peut être désigné comme critique ou non-critique. Un system utilisant les AC doit rejeter un AC s'il rencontre une extension critique qu'il ne reconnaît pas; cependant, une extension non-critique peut être ignorée s'il ne la reconnaît pas.

Audit Identity

   Dans certaines circonstances, il est requis ( par ex: protection des données ) que chemins d'audit ne contiennent pas d'enregistrement qui identifie directement les individus. Cette circonstance peut rendre le champ Holder inutilisable dans les chemins d'audit.

   Pour permettre de tels cas, un AC peut contenir une extension d'identité d'audit. Idéalement, il devrait être impossible de dériver l'identité du titulaire depuis la valeur de l'identité d'audit sans la coopération du fournisseur d'AC.

   La valeur de l'identité d'audit, avec le issuer/serial, devrait être utilisé dans un but d'audit/logging. Si la valeur de l'identité d'audit est bien choisis, un serveur/administrateur de service peut utiliser les traces d'audit pour tracer le comportement du titulaire de l'AC sans être capable d'identifier ce titulaire.

   Le serveur/administrateur de service en combinaison avec le fournisseur d'AC doit être capable d'identifier le titulaire de l'AC dans les cas où des problèmes sont détectés. Cela signifie que le fournisseur d'AC doit être capable de déterminer l'identité actuelle du titulaire de l'AC depuis l'identité d'audit.

   Bien évidemment, l'audit pourrait être basée sur la paire issuer/serial; cependant, cette méthode ne permet pas de tracer le même titulaire avec plusieurs AC. Donc, une identité d'audit n'est utile que si elle dure plus longtemps que la durée de vie typique d'un AC. L'audit pourrait également être basée sur le issuer/serial du PKC du titulaire de l'AC; cependant, cela permet souvent au serveur/administrateur de service d'identifier le titulaire de l'AC.

   Un AC verifier peut sinon utiliser holder ou d'autres valeur identifiant pour un but d'audit, cette extension doit être critique quand elle est utilisée.

   Les protocoles qui utilisent les AC vont souvent exposer l'identité du titulaire. Dans de tels cas, une identité d'audit opaque n'utilise pas d'AC anonyme; il s'assure simplement que les traces d'audit ne contiennent pas d'information d'identification.

La valeur d'une identité d'audit doit être plus longue que 0 octet. La valeur d'une identité d'audit ne doit pas être plus longue que 20 octets.
name id-pe-ac-auditIdentity
OID { id-pe 4 }
syntax OCTET STRING
criticality MUST be TRUE

AC Targeting

   Pour cibler un AC, l'extension d'information de cible, importé depuis X.509-2000, peut être utilisé pour spécifier un nombre de serveurs/services. Le but est que l'AC devrait seulement être utilisable sur les serveurs/services spécifiés. Un AC verifier ( honnête ) qui n'est pas parmi les serveurs/services nommés doit rejeter l'AC.

   Si cette extension n'est pas présente, l'AC n'est pas ciblée et peut être accepté par n'importe quel serveur. Dans ce profile, les informations de cible consiste simplement d'une liste de cibles nommés, ou de groupes.

La syntaxe suivante est utilisée pour représenter les informations de cible:
Targets ::= SEQUENCE OF Target
    
Target ::= CHOICE {
    targetName [0] GeneralName,
    targetGroup [1] GeneralName,
    targetCert [2] TargetCert
}
    
TargetCert ::= SEQUENCE {
    targetCertificate IssuerSerial,
    targetName GeneralName OPTIONAL,
    certDigestInfo ObjectDigestInfo OPTIONAL
}

   Le choix targetCert dans la structure Target est seulement présente pour permettre de futures compatibilités avec X.509-2000 et ne doit pas être utilisé.

   Les vérifications de cible réussissent si le serveur courant ( le destinataire ) est un des champs targetName dans la séquence Targets, ou si le serveur courant est un membre d'un des champs targetGroup dans la sequence Targets. Dans ce cas, le serveur courant est dit "correspondre" à l'extension de ciblage.

   La manière de déterminer si la cible est dans un targetGroup n'est pas déterminés ici. Il est assumé que la cible donnée connaît les noms des targetGroups pour lequel il appartient ou peut déterminer ses membres. Par exemple, le targetGroup spécifie un domaine DNS, et l'AC verifier connaît le domaine DNS auquel il appartient. Pour un autre exemple, targetGroup spécifie "PRINTERS" et l'AC verifier sait s'il est ou non une imprimante ou un serveur d'impression.

   Note: X.509-2000 définis la syntaxe d'extension comme une séquence de target. Les implémentations de fournisseur d'AC conformes doivent seulement produire un élément Targets. Les utilisateurs d'AC doivent être capable d'accepter une sequence de Targets. Si plus d'un élément Targets est trouvé dans l'AC, l'extension doit être traitée comme si tous les éléments Target avaient été trouvés dans un élément Targets.


name id-ce-targetInformation
OID { id-ce 55 }
syntax SEQUENCE OF Targets
criticality MUST be TRUE

Authority Key Identifier

   L'extension authorityKeyIdentifier, comme profilé dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification de la signature de l'AC. La description de la rfc 5280 devrait être lue comme si CA signifiait AC issuer. Comme avec les PKC, cette extension devrait être incluse dans les AC.

Note: Un AC, où le champ issuer utilisant le choix baseCertificateID, ne nécessite pas l'extension authorityKeyIdentifier, vu qu'il est explicitement lié à la clé dans le certificat référé. Cependant, l'AC doit utiliser la v2Form avec le choix issuerName, cette duplication ne se produit pas.
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE

Authority Information Access

   l'extension authorityInfoAccess, comme définis dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification de statut de révocation de l'AC. Le support pour id-ad-caIssuers accessMethod est optionnel par ce profile vu que les chaînes d'AC ne sont pas attendus.

L'accessMethod suivante est utilisée pour indiquer que la vérification de statut de révocation est fournie pour cet AC, en utilisant OCSP:
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

accessLocation doit contenir une URI, et l'URI doit contenir une URL HTTP qui spécifie l'emplacement d'un répondeur OCSP. Le fournisseur d'AC doit, bien sûr, maintenir un répondeur OCSP à cet emplacement.
name id-ce-authorityInfoAccess
OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax
criticality MUST be FALSE

CRL Distribution Points

   l'extension crlDistributionPoints, comme définis dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification du statut de révocation de l'AC.

Si l'extension crlDistributionPoints est présent, un seul point de distribution doit être présent. l'extension crlDistributionPoints doit utiliser l'option DistributionPointName, qui doit contenir un nom complet, qui doit contenir une forme nom simple. Ce nom doit contenir soit un nom distinct soit une URI. L'URI doit être soit une URL HTTP soit une URL LDAP.
name id-ce-cRLDistributionPoints
OID { id-ce 31 }
syntax CRLDistributionPoints
criticality MUST be FALSE

No Revocation Available

   L'extension noRevAvail, définis dans X.509-2000, permet à un fournisseur d'AC d'indiquer qu'aucune information de révocation n'est disponible pour cet AC.

Cette extension doit être non-critique. Un AC vérifier qui ne comprend par cette extension doit être capable de trouver une liste de révocation du fournisseur d'AC, mais la liste de révocation n'inclura jamais l'AC.
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e., '0500'H is the DER encoding)
criticality MUST be FALSE

Types d'attributs

   Certains attributs définis ci-dessous utilisent le type IetfAttrSyntax, également définis ci-dessous. Les raisons d'utiliser ce type sont:

1. Il permet une séparation entre le fournisseur d'AC et l'autorité de stratégie d'attributs. C'est utile pour les situations où une seule autorité de stratégie (par exemple une organisation) alloue des valeurs d'attributs, mais où plusieurs fournisseurs d'AC sont déployés pour les raisons de performances, ou autre.
2. Les syntaxes permises pour les valeurs sont restreintes à des chaînes d'octets, identifiant d'objet, et UTF8String, qui réduit significativement la complexité associée avec les syntaxes plus générales. Tous les attributs multi-valués utilisant cette syntaxe sont restreints pour que chaque valeur utilise le même choix de syntaxe de valeur. Par exemple, le fournisseur d'AC ne doit pas utiliser une valeur avec un oid et une autre valeur avec une chaîne.


IetfAttrSyntax ::= SEQUENCE {
    policyAuthority [0] GeneralNames OPTIONAL,
    values SEQUENCE OF CHOICE {
        octets OCTET STRING,
        oid OBJECT IDENTIFIER,
        string UTF8String
    }
}

   Dans la description ci-dessous, chaque type d'attribut est soit marqué "Multiple Allowed" ou "One Attribute value only; multiple values within the IetfAttrSyntax". Cela réfère au jeu d'AttributeValues; le AttributeType ne se produit qu'une seul fois.

Service Authentication Information

   L'attribut SvceAuthInfo identifie le titulaire de l'AC au serveur/service par un nom, et l'attribut peut inclure des information optionnelles d'authentification spécifiques au service. Typiquement, il contient une paire nom/mot de passe.

   Cet attribut fournis des informations qui peuvent être présentés par l'AC verifier pour être interprété et authentifié par une application séparée dans le système cible. Noter que c'est une utilisation différente de ce qui est prévu pour l'attribut accessIdentity.

Ce type d'attribut est typiquement chiffré quand le champ authInfo contient des information sensibles, tel qu'un mot de passe.
name id-aca-authenticationInfo
OID { id-aca 1 }
syntax SvceAuthInfo
values Multiple allowed
    
SvceAuthInfo ::= SEQUENCE {
    service GeneralName,
    ident GeneralName,
    authInfo OCTET STRING OPTIONAL
}

Access Identity

   L'attribut accessIdentity identifie le fournisseur d'AC au serveur/service. Pour cet attribut le champ authInfo ne doit pas être présent.

Cet attribut est prévu pour fournir des informations sur le titulaire d'AC, qui peut être utilisé par l'AC verifier ( ou un grand système dans lequel l'AC verifier est un composant ) pour autoriser les actions du titulaire dans le système de l'AC verifier. Noter que c'est une utilisation différente que l'attribut svceAuthInfo.
name id-aca-accessIdentity
OID { id-aca 2 }
syntax SvceAuthInfo
values Multiple allowed

Charging Identity

L'attribute chargingIdentity identifie le titulaire de l'AC dans un but de charge. En général, l'identité de charge sera différent des autres identités du titulaire. Par exemple, la compagnie du titulaire peut être chargé pour un service.
name id-aca-chargingIdentity
OID { id-aca 3 }
syntax IetfAttrSyntax
values One Attribute value only; multiple values within the IetfAttrSyntax

Group

L'attribut group gère les informations d'appartenance du titulaire à des groupes.
name id-aca-group
OID { id-aca 4 }
syntax IetfAttrSyntax
values One Attribute value only; multiple values within the IetfAttrSyntax

Role

L'attribut role, spécifié dans X.509-2000, gère les informations sur l'allocation de rôle du titulaire de l'AC. La syntaxe utilisée pour cet attribut est:
RoleSyntax ::= SEQUENCE {
    roleAuthority [0] GeneralNames OPTIONAL,
    roleName [1] GeneralName
}

   Le champ roleAuthority peut être utilisé pour spécifier l'autorité de délivrance de certificat de spécification de rôle. Il n'y a pas de pré-requis pour qu'un certificat de spécification de rôle existe nécessairement pour le roleAuthority. Cela diffère de X.500-2000, où le champ roleAuthority est assumé au nom du fournisseur du certificat de spécification de rôle. Par exemple, pour distinguer le rôle administrateur comme définis par Baltimore de ce qui est définis par SPYRUS, on pourrait placer la valeur "urn:administrator" dans le champ roleName et la valeur "Baltimore" ou "SPYRUS" dans le champ roleAuthority.

Le champ roleName doit être présent, et roleName doit utiliser le choix uniformResourceIdentifier de GeneralName:
name id-at-role
OID { id-at 72 }
syntax RoleSyntax
values Multiple allowed

Clearance

   L'attribut clearance, spécifié dans X.501-1993, gère les informations de clairance ( associé avec les labels de sécurité ).

   Le champ policyId est utilisé pour identifier la stratégie de sécurité pour lequel la clairance est liée. policyId indique les sémantiques des champs classList et securityCategories.

   Cette spécification inclus le champ classList exactement comme spécifié dans X.501-1993. Des valeurs additionnelles de classification de sécurité, et leur position dans la hiérarchie de classification, peuvent être définis par une stratégie de sécurité au niveau local ou par accord bilatéral. La hiérarchie de classification de sécurité de base est, dans l'ordre ascendant: unmarked, unclassified, restricted, confidential, secret, et top-secret.

   Une organisation peut développer ses propres stratégies de sécurité qui définissent les valeurs de classification de sécurité et leur signification. Cependant, les positions 0 à 5 de la chaîne de bits sont réservés pour la hiérarchie de classification de sécurité de base.

   Si présent, le champ securityCategory fournis d'autres information d'autorisation. La stratégie de sécurité identifié par le champ policyId indique les syntaxes qui sont permises dans le jeu securityCategories. Un identifiant d'objet identifie chaque syntaxe permise. Quand une de ces syntaxe est présente dans le jeu securityCategories, l'identifiant d'objet associé avec cette syntaxe est réalisé dans le champ securityCategory.type.

L'identifiant d'objet pour l'attribut clearance de la rfc3281 est:
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
    clearance (55) }

La syntaxe a été corrigée depuis la rfc3281, pour restaurer la conformité avec X.509-1997:
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

L'identifiant d'objet pour l'attribut clearance de X.509-1997 est:
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }

La syntaxe associée est la suivante:
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

Les implémentations doivent supporter l'attribut clearance comme définis dans X.501-1997. Les implémentations devraient supporter le décodage de la syntaxe clearance de la rfc3281. Les implémentations ne doivent pas générer d'attribut clearance comme définis dans la rfc3281.
ClassList ::= BIT STRING {
    unmarked (0),
    unclassified (1),
    restricted (2),
    confidential (3),
    secret (4),
    topSecret (5)
}
    
SecurityCategory ::= SEQUENCE {
    type [0] OBJECT IDENTIFIER,
    value [1] EXPLICIT ANY DEFINED BY type
}
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) attribute-type (4) clearance (55) }
syntax Clearance -- imported from [X.501-1997]
values Multiple allowed

Profile du PKC du AC Issuer

   Le PKC du fournisseur doit être conforme à la rfc5280, et l'extension keyUsage dans le PKC ne doit pas explicitement indiquer que la clé publique du fournisseur d'AC ne peut pas être utilisée pour valider une signature numérique. Pour éviter toute confusion dans les numéros de série et les révocations, un fournisseur d'AC ne doit pas être en même temps un PKC Issuer. Donc le PKC du fournisseur d'AC ne doit pas avoir une extension basicConstraints avec cA à TRUE.

Validation de certificat d'attribut

   Cette section décrit un jeu de règles de base que tout AC valide doit satisfaire. Certaines vérifications additionnelles sont également décrites, que l'AC verifier peut choisir d'implémenter. Pour être valide, un AC doit satisfaire tous les points suivant:

1. Là où le titulaire utilise un PKC pour s'authentifier auprès de l'AC verifier, le PKC du titulaire de l'AC doit être trouvé, et tout le chemin de certification de ce PKC doit être vérifié en accord avec la rfc5280. Comme mentionné dans la section Considération de Sécurité, si un autre schémas de sécurité est utilisé, les AC verifier doivent être très attentifs au mappage des identités.
2. La signature de l'AC doit être cryptographiquement correcte, et tout le chemin de certification du PKC du fournisseur d'AC doit être vérifié en accord avec la rfc5280.
3. Le PKC du fournisseur d'AC doit également être conforme au profile spécifié dans la section précédente.
4. Le fournisseur d'AC doit être directement considéré comme un fournisseur d'AC.
5. Le temps pour lequel l'AC est évalué doit être dans la validité de l'AC. Si l'évaluation est égal à soit notBeforeTime soit notAfterTime, la vérification réussit. Noter que dans certaines applications, l'évaluation du temps peut ne pas être la même que l'heure courante.
6. La vérification de l'AC targeting doit passe comme spécifié dans la section AC Targeting.
7. Si l'AC contient une extension critique non-supportée, l'AC doit être rejetée.

   Le support pour une extension dans ce contexte signifie:

1. L'AC verifier doit être capable de lire la valeur de l'extension
2. Là où la valeur de l'extension implique de rejeter l'AC, l'AC verifier doit rejeter l'AC.

   Vérifications additionnelles:

1. L'AC peut être rejetée sur la base d'une configuration de l'AC verifier. Par exemple, un AC verifier peut être configuré pour rejeter les AC qui contiennent ou qui n'ont pas certains attributs.
2. Si l'AC verifier fournis une interface qui permet aux applications de requêter le contenu de l'AC, alors l'AC verifier peut filtrer les atributs de l'AC en fonction de sa configuration. Par exemple, un AC verifier pourrait être configuré pour ne pas retourner certains attributs pour certains serveurs.

Révocation

   Dans de nombreux environnements, la période de validité d'un AC est inférieure au temps requis pour fournir et distribuer les informations de révocation. Les AC à durée de vie courte ne nécessitent pas de support de révocation. Cependant, les AC à durée de vie longue et les environnements où les AC permettent les transaction à forte valeur, le support de la révocation peut être requise.

   2 schémas de révocation sont définis, et le fournisseur d'AC devrait élire celui qui est le plus adapté à l'environnement dans lequel l'AC sera employé.

Schéma "Never revoke": Les AC peuvent être marqués pour que les parties comprennent qu'aucune information de statut de révocation ne sera rendu disponible. L'extension NoRevAvail doit être présent dans l'AC pour indiquer l'utilisation de ce schéma. Si cette extension n'est pas présente, le fournisseur d'AC statut qu'une vérification du statut de révocation est suppportée, et certaines méthodes de révocation doivent être fournis pour permettre aux AC verifiers d'établir le statut de révocation de l'AC.
Schéma "Pointer in AC": Les AC peuvent "pointer" sur la source d'information de statut de révocation, en utilisant soit l'extension authorityInfoAccess ou l'extension crlDistributionPoints dans l'AC.

   Pour les utilisateurs d'AC, le schéma "never revoke" doit être supporté, et le "pointer in AC" devrait être supporté. Si seul le premier est supporté, tous les AC qui ne contiennent pas l'extension noRevAvail doivent être rejetés.

   Un AC ne doit pas contenir à la fois l'extension noRevAvail et un "pointer in AC".

  Un AC verifier peut utiliser toute information de statut de révocation de l'AC.

Fonctionnalités optionnelles

   Cette section spécifie les fonctionnalités qui peuvent être implémentées. La conformité avec ce profile n'impose pas de supporter ces fonctionnalités; cependant, si ces fonctionnalités sont supportées, elles doivent le faire tel que décris ici.

Chiffrement d'attribut

   Les attributs d'AC peuvent nécessiter d'être chiffrés si l'AC est transporté dans le protocole d'application en clair ou contient des informations sensibles ( par ex: username/password ).

   Quand un jeu d'attributs doit être chiffré dans un AC, le CMS EnvelopedData est utilisé pour transporter le texte chiffré et les informations par destinataire associés.

   Ce type de chiffrement d'attribut est ciblé. Avant que l'AC soit signé, les attributs sont chiffrés pour un jeu de destinataires prédéterminés.

Dans l'EnvelopedData, encapsulatedContentInfo identifie le type de contenu transporté dans le texte chiffré. Dans ce cas, le champ contentType de encapsulatedContentInfo doit contenir id-ct-attrCertEncAttrs, qui a la valeur suivante:
attrCertEncAttrs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-ct(1) 14 }

   Le texte chiffré est inclus dans l'AC comme valeur d'un attribut encAttrs. Seul un attribut encAttrs peut être présent dans un AC; cependant, l'attribut encAttrs peut être multi-valué, et chacune de ses valeurs contient un EnvelopedData indépendant.

   Chaque valeur peut contenir un jeu d'attributs ( chaque pouvant être multi-valué ) chiffré pour un jeu de déstinataires prédéterminés.

Le texte en clair qui est chiffré a le type:
ACClearAttrs ::= SEQUENCE {
    acIssuer GeneralName,
    acSerial INTEGER,
    attrs SEQUENCE OF Attribute
}

   L'encodé DER de la structure ACClearAttrs est utilisée comme champ encryptedContent de EnvelopedData. L'encodé DER doit être embarqué dans une chaîne d'octets.

   Les champs acIssuer et acSerial sont présents pour empêcher le vol du texte chiffré. Quand un AC verifier a déchiffré un attribut chiffré avec succès, il doit ensuite vérifier que les champs acIssuer et acSerial contiennent les même valeur. Cela empêche un fournisseur d'AC malicieux de copier le texte chiffré d'un autre AC.

   La procédure pour un fournisseur d'accès pour chiffrer des attributs est illustré par les étapes suivantes ( tout autre procédure qui donne le même résultat peut être utilisé ):

1. Identifier les jeux d'attributs qui doivent être chiffrés pour chaque jeu de destinataires.
2. Pour chaque jeu d'attribut qui doit être chiffré:

        2.1. Créer une structure EnvelopedData pour les données pour ce jeu de destinataires
        2.2. Encoder ContentInfo contenant le EnvelopedData comme valeur de l'attribut encAttrs
        2.3. S'Assurer que les attributs en texte clair ne sont pas présents dans l'AC à signer

3. Ajouter encAtrs ( avec ses multiples valeurs ) à l'AC.

   Noter qu'il peut y avoir plus d'un attribut de même type ( le même identifiant d'objet ) après de déchiffrement. C'est à dire, un AC peut contenir le même type d'attribut à la fois en clair et chiffré ( et de nombreuses fois si différents destinataires sont associés avec plus d'un EnvelopedData ). Par exemple, un AC pourrait contenir un attribut clearance en texte claire indiquant que le titulaire est autorisé à SECRET, et , en plus, un attribut clearance chiffré dont la valeur est une clairance supérieure qui ne doit pas être connus par tout le monde. Une approche peut choisir de fusionner les valeurs d'attributs après déchiffrement pour rétablir la contrainte "once only".


name id-aca-encAttrs
OID { id-aca 6}
syntax ContentInfo
values Multiple Allowed

   Si un AC contient des attributs apparemment chiffrés pour l'AC verifier, un échec du processus de déchiffrement doit impliquer le rejet de l'AC.

Proxying

   Quand un serveur agit comme un client pour un autre serveur de la part du titulaire, le serveur peut nécessiter proxyfier un AC. Un tel proxy peut être fait sous le contrôle du fournisseur d'AC, pour que tous les AC ne soient pas proxyfiables et qu'un AC proxyfié puisse l'être de façon ciblée. Le support pour les chaînes de proxy ( avec plus d'un serveur intermédiaire ) peut également être requis. Noter que cela n'implique pas une chaîne d'AC.

   Pour ce pré-requis, on définis une autre extension, ProxyInfo, similaire à l'extension targeting.

   Quand cette extension est présente, l'AC verifier doit vérifier que l'entité depuis lequel l'AC a été reçus était autorisé à l'envoyer et que l'AC est autorisé à être utilisé par l'AC verifier.

   Les informations de proxying est une liste dans laquelle chaque élément est une liste d'informations de ciblage. Si le verifieur et l'émetteur de l'AC sont nommés dans la même liste de proxy, l'AC peut alors être accepté ( la règle exacte est donnée plus bas ).

   L'effet est que le titulaire de l'AC peut envoyer l'AC à une cible valide qui peut ainsi seulement proxyfier aux cibles qui sont dans une des même listes que lui.

La structure de donnée suivante est utilisée pour représenter les information de targeting/proxying:
ProxyInfo ::= SEQUENCE OF Targets

   Les Targets sont expliqués dans la section AC Targeting. Comme dans le cas du targeting, le choix targetCert ne doit pas être utilisé.

   Une vérification de proxy réussie si une des conditions suivantes est rencontrée:

1. L'identité de l'émetteur, comme établit par le service d'authentification sous-jacent, correspond au champ Holder de l'AC, et le serveur courant correspond à un nom dans les jeux proxy.
2. L'identité de l'émetteur, comme établit par le service d'authentification sous-jacent, correspond à un des jeux proxy ( appelons le jeu A ), et le serveur courant est un des champs targetName dans le jeu A, ou le serveur courant est un membre d'un des champs targetGroup dans le jeu A.

   Quand un AC est proxyfié plus d'une fois, un nombre de cibles seront sur le chemin du client original, qui est normalement, mais pas toujours, le titulaire de l'AC. Dans de tels cas, la prévention du vol d'AC nécessite que l'AC verifier vérifie toujours que toutes les cibles dans le chemin sont dans le jeu proxy. Il est de la responsabilité du protocole utilisant d'AC de s'assurer qu'une liste de cibles de confiance dans le chemin soit disponible à l'AC verifier.


name id-pe-ac-proxying
OID { id-pe 10 }
syntax ProxyInfo
criticality MUST be TRU

Utilisation de ObjectDigestInfo

   Dans certains environnements, il peut être requis que l'AC ne soit pas lié soit à une identité ( via entityName ) ou à un PKC ( via baseCertificateID ). Le choix objectDigestInfo dans le champ Holder permet de le gérer.

   Si le titulaire est identifié avec le champ objectDigestInfo, alors le champ version de l'AC doit contenir v2 ( l'entier 1 ).

   L'idée est de lier l'AC à un objet en plaçant un hash de cet objet dans le champ Holder de l'AC. Par exemple, cela permet la production d'AC qui sont liés aux clés publiques au lieu de leur noms. Cela permet également la production d'AC qui contiennent des privilèges associés avec un objet exécutable telle qu'une classe java au travers d'une clé publique ou un PKC. Les AC conformes ne doivent pas utiliser de valeur otherObjectTypes pour le digestedObjectType.

   Pour lier un AC à une clé publique, le hash doit être calculé sur la présentation de cette clé publique, qui pourrait être présente dans un PKC, spécifiquement, l'entrée pour l'algorithme de hash doit être l'encodé DER d'une représentation SubjectPublicKeyInfo de la clé.

   Note: cela inclus l'AlgorithmIdentifier aussi bien que la chaîne de bit. Les règles donnée dans les algorithmes PKIX ( rfc3279, rfc4055, rfc5480, et rfc5756 ) pour encoder les clés doivent être suivies. Dans ce cas, le digestedObjectType doit être publicKey et le champ otherObjectTypeID ne doit pas être présent.

   Noter que si la valeur de la clé publique utilisé en entrée de la fonction de hashage a été extraite d'un PKC, il est possible que le SubjectPublicKeyInfo de ce PKC ne soit pas la valeur qui devrait être hashé. Cela peut se produire si les Dss-parms de DSA sont hérités comme décris dans la section 2.3.2 de la rfc3279. L'entrée correcte pour le hashage dans ce contexte inclus la valeur des paramètres hérités du PKC de la CA, et donc peut différer du SubjectPublicKeyInfo présent dans le PKC.

   Les implémentations qui supportent cette fonctionnalité doivent être capable de gérer les représentations de clé publique pour les algorithmes spécifiés dans la section 2.3 de la rfc3279.

   Pour lier un AC à un PKC via un hash, le hash doit être calculé sur l'encodé DER de tout le PKC, incluant la valeur de signature. Dans ce cas, digestedObjectType doit être publicKeyCert et otherObjectTypeID ne doit pas être présent.

Contrôles AA

Durant la validation d'AC, un partie de confiance doit répondre à la question: est-ce que ce fournisseur d'AC est valide pour fournir des ACs avec cet attribut? L'extension AAControls est prévu pour être utilisé dans les CA et les fournisseurs d'AC
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
    
AAControls ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL,
    permittedAttrs [0] AttrSpec OPTIONAL,
    excludedAttrs [1] AttrSpec OPTIONAL,
    permitUnSpecified BOOLEAN DEFAULT TRUE
}
    
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER

   L'extension AAControls est utilisé comme suit:

PathLenConstraint si présent,, est interprété comme dans la rfc5280. Il restreint la distance permise entre le AA CA ( une CA directement validé pour inclure les AAControls dans ses PKCs), et le fournisseur d'AC.
permittedAttrs spécifie une liste de types d'attributs que tout fournisseur d'AC sous ce AA CA est autorisé à inclure dans les AC. Si ce champ n'est pas présent, cela signifie qu'aucun type d'attribut n'est explicitement permis.
excludedAttrs spécifie une liste de types d'attributs qu'aucun fournisseur d'AC sous ce AA CA n'est autorisé à inclure dans les AC. Si ce champ n'est pas présent, cela signifie qu'aucun type d'attribut n'est explicitement interdis.
permitUnSpecified spécifie comment manipuler les types d'attributs qui ne sont pas présents dans les champs permittedAttrs ou excludedAttrs. TRUE ( par défaut ) signifie qu'un type d'attribut non-spécifié est autorisé dans les AC, et FALSE, qu'il ne l'est pas.
- Quand AAControls est utilisé, les vérifications additionnelles suivantes sur la chaîne de PKC d'AA doit tous réussir pour que l'AC soit valide:

        1. Certaines CA dans le chemin de certification de l'AC doivent être directement trustés pour fournir des PKCs qui précède le fournisseur d'AC dans le chemin de certification; appelons cette CA le "AA CA".
        2. Tous les PKC dans le chemin depuis le AA CA, incluant le PKC du fournisseur d'AC, doivent contenir l'extension AAControls; cependant, le PKC du AA CA n'a pas besoin de contenir cette extension.
        3. Seul les attributs dans l'AC qui sont permis, en accord avec toutes les valeurs d'extension AAControls dans tous les PKC depuis le AA CA jusqu'au fournisseur d'AC, peuvent être utilisé pour les décisions d'autorisation; tous les autres attributs doivent être ignorés. Cette vérification doit être appliquée à la liste des attributs suivant le déchiffrement d'attributs, et le type id-aca-encAtrs doit être également vérifié.


name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE

Considérations de sécurité

   La protection offerte pour les clés privées est un facteur critique pour maintenir la sécurité. Si les fournisseurs d'AC ne parviennent pas à protéger leur clé privée, un attaquant pour les utiliser, potentiellement pour générer de faux AC ou statut de révocation. Si le système est compromis, tous les AC fournis par le fournisseur d'AC doivent être révoqués. La reconstruction sera problématique, donc les fournisseurs d'AC doivent implémenter une combinaison de techniques fortes ( ex: modules cryptographique inviolable ) et de procédures de gestion appropriés ( ex: séparation des fonctions ) pour éviter un tel incident.

   La perte d'une clé privée d'un fournisseur d'AC peut également être problématique. Le fournisseur d'AC ne sera plus capable de produire de status de révocation ou de renouvellement d'AC. Les fournisseur d'AC doivent maintenir une sauvegarde sécurisée de leur clé de signatue. La sécurité des procédures de sauvegarde de clé est un facteur critique.

   La disponibilité et la "fraîcheur" du status de révocation va affecter le degré d'assurance qui serai placé dans un AC long terme. Bien que les AC long-terme expirent naturellement, des évènements peuvent se produire durant sa durée de vie. Si le status de révocation est non-timé ou non-disponible, l'assurance associée avec le lien entre le titulaire de l'AC et les attributs est clairement réduit.

   La liaison entrée un titulaire d'AC et les attributs ne peut pas être plus forte que l'implémentation cryptographique et les algorithmes utilisé pour générer la signature. Des clé courtes ou des algorithmes faibles limitent l'utilité d'un AC.

   Les applications qui sont inconsistant lors de la comparaison des noms peut engendrer l'acceptation de cibles ou proxy invalides, ou le rejet de certains valides. Les séries X.500 de spécifications définissent des règles pour comparer les noms distincts. Ces règles nécessitent la comparaison de chaînes sans regarder la casse, le jeu de caractères, les espace blancs multi-caractères, ou les espaces blanc de début et de fin. Cette spécification relaxe ces pré-requis, nécessitant une comparaison binaire au minimum.

   Les fournisseurs d'AC doivent encoder le nom distinct dans le champ holder.entityName de l'AC identiquement au nom distinct dans le PKC du titulaire. Si des encodages différents sont utilisé, les implémentations de cette spécifiaciton peuvent échouer dans la reconnaissance de l'AC et du PKC appartenant à la même entité.

   Si un certificat d'attribut est lié au PKC du titulaire un utilisant le composant baseCertificateID du champ Holder et la PKI utilisée inclue un faux CA avec le même nom de fournisseur spécifié dans le composant baseCertificateID, ce faux CA pourrait fournir un PKC à un paire malicieux, en utilisant le même nom de fournisseur et numéro de série que le PKC du titulaire. Ainsi, le paire malicieux pourrait utiliser ce PKC en conjonction avec l'AC. Ce scénario devrait être évité en gérant et en configurant proprement la PKI pour qu'il ne puisse pas y avoir 2 CA avec le même nom.

   Une autre alternative est de lier les AC aux PKC en utilisant le type publicKeyCert dans le champ ObjectDigestInfo. Les AC verifier doivent établir ( en utilisant d'autres moyens ) que les collisions potentiels ne peuvent pas se produire, par exemple, le Certificate Practice Statements (CPSs) des CA impliqués peuvent préciser qu'une collision de nom ne puisse se produire.

   Les implémenteurs doivent s'assurer qu'en suivant la validation d'un AC, seuls les attributs dont le fournisseur est autorisé à fournir sont utilisés dans les décisions d'autorisation. Les autres attributs, qui peuvent être présents doivent être ignorés. L'extension PKC AAControls est optionnel, et les informations de configuration peuvent être une alternative. Cela devient très important si un AC verifier trust plus d'un fournisseur d'AC.

   Il est souvent requis de mapper l'authentification fournie par un protocole de sécurité particulier ( ex: TLS, S/MIME ) et l'identité du titulaire de l'AC. Si l'authentification utilise les PKC, alors le mapping est simple. Cependant, il est envisagé que les AC sont également utilisés dans des environnement où le titulaire peut être authentifié en utilisant d'autres moyens. Les implémenteurs devraient prendre en charge le mapping d'identité d'authentification qui ne proviennent pas de certificats à clé publique.

Appendix A - Object Identifiers

   Cet appendix liste les nouveaux identifiant d'objet qui sont définis dans cette spécification. Certains sont requis uniquement pour le support de fonctionnalités optionnels et ne sont pas obligatoire pour se conformer à ce profile.

Les OID suivant sont importés depuis les rfc de profile PKIX:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

Le nouvel OID de mode ASN.1 suivant est définis:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }

Les OID d'extension d'AC suivant sont définis:
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }

Les OID d'extension PKC suivants sont définis:
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

Les OID d'attributs suivant sont définis:
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) clearance (55) }

Appendix B - Module ASN.1

Cet appendix décrit les objects utilisé par les composant de PKI conformes dans une syntaxe ASN.1-like, un hybrid des syntaxe 1988 et 1993 d'ASN.1.
PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-attribute-cert-v2(61) }
    
DEFINITIONS IMPLICIT TAGS ::=
    
BEGIN
    
-- EXPORTS ALL --
    
IMPORTS
    
-- Les OID des modules IMPORTés peuvent changer si les rfc de profile PKIX changent les extensions de certificat PKIX.
    
Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
    FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-explicit-88(18) }

GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
    AuthorityInfoAccessSyntax, CRLDistributionPoint
        FROM PKIX1Implicit88
        { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-implicit-88(19) }
    
ContentInfo
    FROM CryptographicMessageSyntax2004
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
            smime(16) modules(0) cms-2004(24) }
    
;
    
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
    
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
    
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
    
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
    
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
    
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
    
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
    
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
    
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
    
-- { id-aca 5 } is reserved
    
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
    
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
    
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
    
-- Décommenter la déclaration suivante et commenter la ligne au dessus pour utiliser
-- l'attribut id-at-clearance comme définis dans la rfc3281.
    
-- id-at-clearance OBJECT IDENTIFIER ::= {
-- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) }
    
-- Uncomment this if using a 1988 level ASN.1 compiler
    
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
    
AttributeCertificate ::= SEQUENCE {
    acinfo AttributeCertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}
    
AttributeCertificateInfo ::= SEQUENCE {
    version AttCertVersion, -- version is v2
    holder Holder,
    issuer AttCertIssuer,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attrCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL
}
    
AttCertVersion ::= INTEGER { v2(1) }
    
Holder ::= SEQUENCE {
    baseCertificateID [0] IssuerSerial OPTIONAL,
        -- the issuer and serial number of
        -- the holder's Public Key Certificate
    entityName [1] GeneralNames OPTIONAL,
        -- the name of the claimant or role
    objectDigestInfo [2] ObjectDigestInfo OPTIONAL
        -- used to directly authenticate the
        -- holder, for example, an executable
}
    
ObjectDigestInfo ::= SEQUENCE {
    digestedObjectType ENUMERATED {
        publicKey (0),
        publicKeyCert (1),
        otherObjectTypes (2) },
    -- otherObjectTypes MUST NOT
    -- MUST NOT be used in this profile
    otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
    digestAlgorithm AlgorithmIdentifier,
    objectDigest BIT STRING
}
    
AttCertIssuer ::= CHOICE {
    v1Form GeneralNames, -- MUST NOT be used in this profile
    v2Form [0] V2Form -- v2 only
}
    
V2Form ::= SEQUENCE {
    issuerName GeneralNames OPTIONAL,
    baseCertificateID [0] IssuerSerial OPTIONAL,
    objectDigestInfo [1] ObjectDigestInfo OPTIONAL
        -- issuerName MUST be present in this profile
        -- baseCertificateID and objectDigestInfo MUST
        -- NOT be present in this profile
}
    
IssuerSerial ::= SEQUENCE {
    issuer GeneralNames,
    serial CertificateSerialNumber,
    issuerUID UniqueIdentifier OPTIONAL
}
    
AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime GeneralizedTime,
    notAfterTime GeneralizedTime
}
    
Targets ::= SEQUENCE OF Target
    
Target ::= CHOICE {
    targetName [0] GeneralName,
    targetGroup [1] GeneralName,
    targetCert [2] TargetCert
}
    
TargetCert ::= SEQUENCE {
    targetCertificate IssuerSerial,
    targetName GeneralName OPTIONAL,
    certDigestInfo ObjectDigestInfo OPTIONAL
}
    
IetfAttrSyntax ::= SEQUENCE {
    policyAuthority [0] GeneralNames OPTIONAL,
    values SEQUENCE OF CHOICE {
        octets OCTET STRING,
        oid OBJECT IDENTIFIER,
        string UTF8String
    }
}
    
SvceAuthInfo ::= SEQUENCE {
    service GeneralName,
    ident GeneralName,
    authInfo OCTET STRING OPTIONAL
}
    
RoleSyntax ::= SEQUENCE {
    roleAuthority [0] GeneralNames OPTIONAL,
    roleName [1] GeneralName
}
    
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}
    
-- Uncomment the following lines to support deprecated clearance
-- syntax and comment out previous Clearance.
    
-- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory OPTIONAL
-- }
    
ClassList ::= BIT STRING {
    unmarked (0),
    unclassified (1),
    restricted (2),
    confidential (3),
    secret (4),
    topSecret (5)
}
    
SecurityCategory ::= SEQUENCE {
    type [0] OBJECT IDENTIFIER,
    value [1] EXPLICIT ANY DEFINED BY type
}
    
-- Note that in [RFC3281] the syntax for SecurityCategory was
-- as follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encoding.
    
AAControls ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL,
    permittedAttrs [0] AttrSpec OPTIONAL,
    excludedAttrs [1] AttrSpec OPTIONAL,
    permitUnSpecified BOOLEAN DEFAULT TRUE
}
    
AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER
    
ACClearAttrs ::= SEQUENCE {
    acIssuer GeneralName,
    acSerial INTEGER,
    attrs SEQUENCE OF Attribute
}
    
ProxyInfo ::= SEQUENCE OF Targets
    
END
^
01 décembre 2014

htmlpdflatexmanmd




rfc3370

rfc3370

Algorithmes de Syntaxe de message cryptographique

Introduction

   CMS est utilisé pour signer, hasher, authentifier, ou chiffrer numériquement des messages. Ce document décris l'utilisation des algorithmes utilisés communément avec CMS. Les implémentations de CMS peuvent supporter ces algorithmes; et peuvent également supporter d'autres algorithmes. Cependant, si une implémentation choisis de supporter un des algorithmes décris dans ce document, l'implémentation doit le faire comme décris dans ce document.

   Les valeurs CMS sont générées en utilisant ASN.1, encodé BER. Les identifiants d'algorithmes ( qui incluent les identifiants d'objets ASN.1) identifient les algorithmes de cryptographiques, et certains algorithmes nécessitent des paramètres additionnels. Quand nécessaire, les paramètres sont spécifiés avec une structure ASN.1. L'identifiant d'algorithme pour chaque algorithme est spécifié, et que nécessaire, la structure de paramètres est spécifiée. Les champs dans le CMS employé par chaque algorithme sont identifié.

Changements depuis la rfc 2630

   Ce document obsolète la section 12 de la rfc 2630. La séparation des spécification du protocole et des algorithmes permet à chacun d'être mis à jours sans impacter d'autre. Cependant, les conventions pour utiliser des algorithmes additionnels avec CMS sont spécifiés dans des documents séparés.

Algorithmes de hashage

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent SHA-1 ou MD5. Les identifiants d'algorithmes de hashage sont localisés dans le champ digestAlgorithms du SignedData, le champ digestAlgorithm du SignerInfo, le champ digestAlgorithm du DigestedData, et le champ digestAlgorithm du AuthenticatedData.

   Les valeurs de hash sont placés dans le champ DigestedData et l'attribut authentifié messages-digest.

SHA-1

L'algorithme de hashage SHA-1 est définis dans FIPS pub 180-1. L'identifiant d'algorithme pour SHA-1 est:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

   Il y a 2 encodages possible pour le champ de paramètres AlgorithmIdentifier. Les 2 alternatives surviennent du fait que quand la syntaxe 1988 pour AlgorithmIdentifier a été traduite en syntaxe 1997, l'optionnel associé avec les paramètres AlgortihmIdentifier ont été perdus. Plus tard, cet optionnel a été récupérée, mais jusque là beaucoup de gens pensaient que les paramètres de l'algorithme étaient obligatoires. À cause de cela certaines implémentations encodent les paramètres en éléments NUL et d'autres les omettent entièrement. L'encodage correct est d'omettre le champ parameters; cependant, les implémentations doivent également gérer les champ parameters qui contiennent un NULL.

   Le champ parameters de AlgorithmIdentifier est optionnel. Si présent, le champ parameters doit contenir un NULL. Les implémentations doivent accepter un AlgorithmIdentifiers SHA-1 sans paramètres. Les implémentations doivent accepter AlgorithmIdentifiers SHA-1 avec un AlgorithmIdentifiers avec un parameters NULL. Les implémentations devraient générer des AlgorithmIdentifiers SHA-1 sans parameters.

MD5

L'algorithme de hashage MD5 est définis dans la rfc1321. L'identifiant d'algorithme pou MD5 est:
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }

   Le champ parameters de AlgorithmIdentifier doit être présent, et doit contenir NULL. Les implémentations peuvent accepter le AlgorithmIdentifiers MD5 avec parameters absent ou à NULL.

Algorithmes de signature

   Cette section spécifie les conventions employées par les implémentation CMS qui supportent DSA ou RSA. Les identifiants d'algorithme de signature sont localisés dans le champ signatureAlgorithm du SignerInfo du SignedData. Également, les identifiants d'algorithme de signature sont localisés dans le champ signatureAlgorithm du SignerInfo des attributs countersignatures. Les valeurs de signature sont localisées dans le champ signature du SignerInfo du SignedData. Également, les valeurs de signature dans le champ signature des attributs countersignature.

DSA

L'algorithme de signature DSA est définis dans FIPS Pub 186. DSA doit être utilisé avec l'algorithme SHA-1. L'identifiant d'algorithme DSA sujetà à clé publique dans les certificats est:
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 1 }

   La validation de signature DSA nécessite 3 paramètres, communément appelés p, q et g. Quand l'identifiant d'algorithme id-dsa est utilisé, le champ parameters de AlgorithmIdentifier est optionnel. Si présent, ce champ doit contenir les 2 valeurs de paramètre DSA encodés en utilisant le type Dss-Parms. Si absent, le sujet de la clé publique DSA utilise les même paramètres DSA que le fournisseur de certificat:


Dss-Parms ::= SEQUENCE {
    p INTEGER,
    q INTEGER,
    g INTEGER }

Quand l'identifiant d'algorithme id-dsa est utilisé, la clé publique DSA, communément appelée Y, doit être encodée en integer. La sortie de cet encodage est placé dans la clé publique du sujet du certificat:
Dss-Pub-Key ::= INTEGER -- Y

L'identifiant de l'algorithme DSA avec signature SHA-1 est:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

Quand l'identifiant de l'algorithme id-dsa-with-sha1 est utilisé, le champ de paramètres AlgorithmIdentifier doit être absent. En signant, l'algorithme DSA génère 2 valeurs, communément appelés r et s. Pour transférer ces 2 valeurs en tant que signature, il doivent être encodés en utilisant le type Dss-Sig-Value:
Dss-Sig-Value ::= SEQUENCE {
    r INTEGER,
    s INTEGER }

RSA

L'algorithme de signature RSA est définis dans la rfc2437, et spécifie l'utilisation de l'algorithme de signature RSA avec les algorithmes de hashage SHA-1 et MD5. L'identifiant d'algorithme pour les sujets de clé publique RSA dans les certificats est:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

Quand l'identifiant d'algorithme rsaEncryption est utilisé, le champ parameters de AlgorithmIdentifier doit contenir NULL. Quand l'identifiant d'algorithme rsaEncryption est utilisé, la clé publique RSA, qui est composée d'un modulo et d'un exposant publique, doit être encodé en utilisant le type RSAPublicKey. La sortie de cet encodage est placé dans la clé publique du sujet du certificat.
RSAPublicKey ::= SEQUENCE {
    modulus INTEGER, -- n
    publicExponent INTEGER } -- e

   Les implémentations CMS qui incluent l'algorithme de signature RSA doivent implémenter l'algorithme de hashage SHA-1. De telles implémentations devraient également supporter l'agorithme MD5.

   L'identifiant d'algorithme rsaEncryption est utilisé pour identifier les valeurs de signature RSA sans regarder l'algorithme de hashage utilisé. Les implémentations CMS qui incluent l'algorithme de signature RSA doivent supporter l'identifiant d'algorithme de valeur de signature rsaEncryption, et les implémentations CMS peuvent supporter les identifiant d'algorithme de valeur de signature RSA et l'algorithme de hashage.

L'identifiant d'algorithme pour RSA avec signature SHA-1 est:
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

L'identifiant d'algorithme pour RSA avec signature MD5 est:
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

   Quand les identifiants d'algorithme de signature rsaEncryption, sha1WithRSAEncryption, ou md5WithRSAEncryption sont utilisés, le champ parameters de AlgorithmIdentifier doit être NULL.

   En signant, l'algorithme RSA génère une seule valeur, et cette valeur est utilisée directement comme valeur de signature.

Algorithmes de gestion de clé

   CMS accueille les techniques de gestion de clé suivant: key agreement, key transport, previously distributed symmetric key-encryption keys, et passwords.

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent l'agrément de clé en utilisant X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H) et X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H).

   Quand un algorithme d'agrément de clé est utilisé, un algorithme de chiffrement de clé est également nécessaire. Donc, quand l'agrément de clé est supporté, un algorithme de chiffrement de clé doit être fournis pour chaque algorithme de chiffrement de contenu. Les algorithmes d'enveloppement de clé pour Triple-DES et RC2 sont décris dans la rfc3217.

   Pour l'agrément de clé des clés de chiffrement de clé RC2, 128bits doivent être générés en entrée du processus d'expansion de clé utilisé pour calculé la clé effective RC2.

   Les identifiants d'algorithme d'agrément de clé sont localisé dans les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

   Les identifiants d'algorithme d'envelopement de clé sont localisés dans parameters de KeyWrapAlgorithm dans les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

   Les clés de chiffrement de contenu enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey. Les clés message-authentication enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

X9.42 Ephemeral-Static Diffie-Hellman

   L'agrément de clé Ephemeral-Static Diffie-Hellman est définis dans la rfc 2631. En utilisant Ephemeral-Static Diffie-Hellman, le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo est utilisé comme suit:

- la version doit être 3
- originator doit être l'alternative originatorKey. le champ algorithm de originatorKey doit contenir l'identifiant d'objet dh-public-number avec parameters absent. le champ publicKey de originatorKey doit contenir la clé publique éphémère de l'émetteur. l'identifiant d'objet dh-public-number est:


dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

- ukm peut être présent ou absent. Les implémentations CMS doivent supporter l'absence de ukm, et devraient supporter la présence d'ukm. Quand présent, ukm est utilisé pour s'assurer qu'une clé de chiffrement de clé est générée quand la clé privée éphémère doit être utilisée plus d'une fois.
- keyEncryptionAlgorithm doit être l'identifiant d'algorithme id-alg-ESDH. Le champ de paramètre d'identifiant d'algorithme pour id-alg-ESDH est KeyWrapAlgorithm, et ce paramètre doit être présent. KeyWrapAlgorithm dénote l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement de contenu ave la clé de chiffrement générée en utilisa l'algorithme d'agrément de clé X9.42 Ephemeral-Static Diffie-Hellman. Triple-DES et RC2 sont décris dans la rfc3217. la syntaxe de l'identifiant d'algorithme id-alg-ESDH et ses paramètres est:


id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
    
KeyWrapAlgorithm ::= AlgorithmIdentifier

- recipientEncryptedKeys contient un identifiant et un clé chiffrée pour chaque destinataire. Le KeyAgreeRecipientIdentifier de RecipientEncryptedKey doit contenir soit le issuerAndSerialNumber identifiant le certificat du destinataire, soit RecipientKeyIdentifier contenant d'identifiant de clé du sujet du certificat du destinataire. Dans les 2 cas, le certificat du destinataire contient la clé publique statique du destinataire. EncryptedKey de RecipientEncryptedKey doit contenir la clé de chiffrement de contenu chiffrée avec la clé de chiffrement de clé X9.42 Ephemeral-Static Diffie-Hellman générée en utilisant l'algorithme spécifié par le KeyWrapAlgorithm.

X9.42 Static-Static Diffie-Hellman

   L'agrément de clé Static-Static Diffie-Hellman est définis dans la rfc 2631. En utilisant Static-Static Diffie-Hellman, les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo sont utilisé comme suit:

- la version doit être 3
- originator doit être sost issuerAndSerialNumber soit subjectKeyIdentifier. Dans les 2 cas, le certificat de l'auteur contient la clé publique statique de l'émetteur. La rfc 3279 spécifie la syntaxe et les valeurs des paramètres AlgorithmIdentifier qui sont inclus dans le certificat de l'auteur. Le champ d'information de clé publique du certificat de l'auteur doit contenir l'identifiant d'objet dh-public-number:


dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

- ukm doit être présent. ukm s'assure qu'une clé de chiffrement de clé différente est générée pour chaque message entre les même émetteur et destinataire.
- keyEncryptionAlgorithm doit être d'identifiant d'algorithme id-alg-SSDH. Le champ parameter de d'identifiant d'algorithme pour id-alg-SSDH est KeyWrapAlgorithm, et ce paramètre doit être présent. KeyWrapAlgorithm dénote l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé générée en utilisant l'algorithme d'agrément de clé X9.42 Static-Static Diffie-Hellman. Triple-DES et RC2 sont décris dans la rfc 3217. L'identifiant d'algorithme id-alg-SSDH et ses paramètres est:


id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
    
KeyWrapAlgorithm ::= AlgorithmIdentifier

- recipientEncryptedKeys contient un identifiant et une clé chiffrée pour chaque destinataire. KeyAgreeRecipientIdentifier de RecipientEncryptedKey doit contenir soit le issuerAndSerialNumber identifiant le certificat du destinataire, soit le RecipientKeyIdentifier contenant l'identifiant de clé du sujet du certificat du destinataire. Dans les 2 cas, le certificat du destinataire contient la clé publique statique du destinataire. EncryptedKey de RecipientEncryptedKey doit contenir la clé de chiffrement de contenu chiffrée avec la clé de chiffrement de clé X9.42 Static-Static Diffie-Hellman générée en utilisant l'algorithme spécifiée par KeyWrapAlgorithm.

Algorithmes de transport de clé

   Cette section spécifie les conventions employés par les implémentations CMS qui supportent le transport de clé en utilisant RSA. Les identifiant d'algorithme de transport de clé sont localisé dans le champ EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm. Les clé de chiffrement de contenu chiffrés par transport de clé sont localisés dans le champ EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey.

RSA

L'algorithme de transport de clé RSA est le shéma de chiffrement RSA définis dans la rfc 2313, le type de block est 02, où le message à chiffrer est la clé de chiffrement de contenu. L'identifiant d'algorithme pour RSA est:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

   Le champ parameters de AlgorithmIdentifier doit être présent, et le champ parameters doit contenir NULL. En utilisant une clé de chiffrement de contenu Triple-DES, les implémentations CMS doivent ajuster les bits de parité pour chaque clé DES comprises dans la clé Triple-DES avant le chiffrement RSA.

   L'utilisation du chiffrement RSA, comme définis dans la rfc 2313, pour fournir la confidentialité a une vulnérabilité conue. La vulnérabilité est plus dans l'utilisation dans les application intéractives que dans les environnement de stockages. Dans informations et contre-mesure sont discutés dans la section considération de sécurité de ce document et la rfc3218.

   Noter que le même schéma de chiffrement RSA est également définis dans la rfc 2437, qui est appelé RSAES-PKCS1-v1.5.

Algorithmes de clé de chiffrement de clé symétriques

   Cette section spécifie les conventions employés par les implémentations CMS qui supportent la gestion de clé de chiffrement de clé en utilisant Triple-DES ou RC2. Quand RC2 est supporté, des clé RC2 128 bits doivent être utilisé, et doivent être utilisées avec le paramètre RC2ParameterVersion à 58. Une implémentation CMS peut supporter un key-encryption et content-encryptionalgorithms mixés. Par exemple, une clé de chiffrement de contenu 40-bits RC2 peut être enveloppé avec une clé de chiffrement de clé Triple-DES 168-bits ou avec une clé de chiffrement de clé 128-bits RC2.

   Les identifiants d'algorithme d'enveloppement sont localisé dans les champs EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm.

   Les clé de chiffrement de contenus enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KEKRecipientInfo. Les clé d'authentification de message enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey.

   La sortie d'un algorithme d'agrément de clé est une clé de chiffrement de clé, et cette clé de chiffrement de clé est utilisée pour chiffrer la clé de chiffrement de contenu. Pour suppporter l'agrément de clé, les identifiants d'algorithme d'enveloppement sont localisés dans le KeyWrapAlgorithm parameter des champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm. Cependant, seuls les algorithmes d'agrément de clé qui fournissent des clés d'authentification doivent être utilisé avec AuthenticatedData. Les clés de chiffrement de contenu enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey, les clé d'authentification de message enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

Triple-DES Key Wrap

   Une implémentation CMS peut supporter des algorithmes de chiffrement de clé et de chiffrement de contenu mixés. Par exemple, une clé de chiffrement de contenu 128-bits RC2 peut être enveloppé avec une clé de chiffrement de clé 168-bits Triple-DES.

Le chiffrement Triple-DES a l'identifiant d'algorithme :
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

   Le champ parameter de AlgorithmIdentifier doit être NULL. L'algorithme d'envelope de clé utilisé pour chiffrer une clé de chiffrement de contenu Triple-DES avec une clé de chiffrement de clé Triple-DES est spécifiée dans la rfc3217.

RC2 Key Wrap

   Une implémentation CMS peut supporter des algorithmes de chiffrement de clé et de chiffrement de contenu mixés. Par exemple, une clé de chiffrement de contenu 128-bits RC2 peut être enveloppé dans une clé de chiffrement de clé Triple-DES 168-bits. Similairement, une clé de chiffrement de contenu RC2 40-bits peut être enveloppé dans une clé de chiffrement de clé RC2 128-bits.

Le chiffrement de clé RC2 a l'identifiant d'algorithme:
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

Le champ parameter de AlgorithmIdentifier doit être RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER

   Les bits de clé effectifs RC2 ( la taille de clé ) supérieurs à 32 et inférieurs à 256 sont encodés dans le RC2ParameterVersion. Pour les tailles 40, 64, et 128, les valeurs RC2ParameterVersion sont 160, 120, et 58, respectivement. Ces valeurs ne sont pas simplement la longueur de clé RC2. Noter que la valeur 160 doit être encodé en 2 octets (00 A0), parce que l'octet A0 seul représente un nombre négatif.

   Les clé RC2 128-bits doivent être utilisés comme clé de chiffrement de clé, et doivent être utilisé avec le paramètre RC2ParameterVersion à 58.

   L'algorithme d'enveloppe de clé utilisé pour chiffrer une clé de chiffrement de contenu RC2 avec une clé de chiffrement de clé RC2 est spécifiée dans la rfc 3217.

Algorithmes de dérivation de clé

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent la gestion de clé basé sur mot de passe en utilisant PBKDF2. Les algorithmes de dérivation de clé sont utilisés pour convertir un mot de passe en une clé de chiffrement de clé comme partie de la technique de gestion de clé basée sur mot de passe.

   Les identifiants d'algorithme de dérivation de clé sont localisés dans les champs EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm et AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm. La clé de chiffrement de clé qui est dérivée du mot de passe est utilisée pour chiffrer la clé de chiffrement de contenu.

   Les clé de chiffrement de contenu chiffrés avec une clé de chiffrement de clé dérivé de mot de passe sont localisés dans le champ EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey. Les clés d'authentification de message chiffrés avec de clés de chiffrement de clé dérivés de mot de passe sont localisés dans le champ AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey.

L'algorithme de dérivation de clé PBKDF2 est spécifié dans la rfc 2898. keyDerivationAlgorithmIdentifier identifie l'algorithme de dérivation de clé, et ses paramètres associés utilisés pour dériver la clé de chiffrement de clé du mot de passe fournis. L'identifiant d'algorithme pour l'algorithme de dérivation de clé PBKDF2 est:
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 }

Le champ parameter de AlgorithmIdentifier doit être PBKDF2-params:
PBKDF2-params ::= SEQUENCE {
    salt CHOICE {
        specified OCTET STRING,
        otherSource AlgorithmIdentifier },
    iterationCount INTEGER (1..MAX),
    keyLength INTEGER (1..MAX) OPTIONAL,
    prf AlgorithmIdentifier
        DEFAULT { algorithm hMAC-SHA1, parameters NULL } }

   Dans le PBKDF2-params, le salt doit utiliser la chaîne d'octet spécifiée.

Algorithmes de chiffrement de contenu

   Cette section spécifie les conventions employées par les implémentation CMS qui supportent le chiffrement de contenu en utilisant Triple-DES 3 clés en mode CBC, Triple 2-clés en mode CBC, ou RC2 en mode CBC.

   Les identifiants d'algorithme de chiffrement de contenu sont localisés dans les champs EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm et EncryptedData EncryptedContentInfo contentEncryptionAlgorithm. Les algorithme de chiffrement de contenu sont utilisé pour chiffrer le contenu localisé dans le champ EnvelopedData EncryptedContentInfo encryptedContent et le champ EncryptedData EncryptedContentInfo encryptedContent.

Triple-DES CBC

   L'algorithme Triple-DES est composé de 3 opération DES séquentielles: chiffrer, déchiffrer, et chiffrer. Triple-DES 3-clés utilise une clé différente pour chaque opération DES. Triple-DES 2-clés utilise une clé pour les opérations de chiffrement et une clé différente pour l'opération de déchiffrement. Les même identifiant d'algorithme sont utilisé pour les 2.

L'identifiant d'algorithme pour Triple-DES en mode CBC est:
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

Le champ parameters de AlgorithmIdentifier doit être présent, et le champ doit contenir un CBCParameter:
CBCParameter ::= IV
IV ::= OCTET STRING -- exactement 8 octets

RC2 CBC

L'algorithme RC2 est décris dans la rfc2268. L'identifiant d'algorithme pour RC2 en mode CBC est:
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2 }

Le champ parameters de AlgorithmIdentifier doit être présent et doit contenir un RC2CBCParameter:
RC2CBCParameter ::= SEQUENCE {
    rc2ParameterVersion INTEGER,
    iv OCTET STRING } -- exactement 8 octets

   Les bits de clé effectifs RC2 (la taille de clé) supérieurs à 32 et inférieurs à 256 sont encodés dans le RC2ParameterVersion. Pour les tailles 40, 64, et 128, les valeurs RC2ParameterVersion sont 160, 120, et 58, respectivement. Ces valeurs ne sont pas simplement la longueur de clé RC2. Noter que la valeur 160 doit être encodé en 2 octets (00 A0), parce que l'octet A0 seul représente un nombre négatif.

Algorithms de code d'authentification de message

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent HMAC avec SHA-1. Les identifiant d'algorithme MAC sont localisés dans le champ macAlgorithm de AuthenticatedData. es valeurs MAC sont localisées dans le champ mac de AuthenticatedData.

HMAC avec SHA-1

L'algorithme HMAC avc SHA-1 est décris dans la rfc 2104. L'identifiant d'algorithme pour HMAC avec SHA-1 est:
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

   Il y a 2 encodages possibles pour le champ parameters de AlgorithmIdentifier pour HMAC avec SHA-1. Les 2 alternatives surviennent du fait que quand la syntaxe 1988 pour AlgorithmIdentifier a été traduite en syntaxe 1997, l'optionnel associé avec les paramètres AlgortihmIdentifier ont été perdus. Plus tard, cet optionnel a été récupérée, mais jusque là beaucoup de gens pensaient que les paramètres de l'algorithme étaient obligatoires. À cause de cela certaines implémentations encodent les paramètres en éléments NUL et d'autres les omettent entièrement.

   Le champ parameters de AlgorithmIdentifier est optionnel. Si présent, le champ parameters doit contenir NULL. Les implémentations doivent accepter HMAC avec SHA-1 avec parameters absent, et doivent accepter HMAC avec SHA-1 avec paramaters à NULL. Les implémentations devraient générer des AlgorithmIdentifiers HMAC avec SHA-1 avec parameters absent.

Module ASN.1


CryptographicMessageSyntaxAlgorithms
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
    
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
    -- EXPORTS All
    -- Les types et valeurs définis dans ce module sont exporté pour l'utilisation dans d'autres modules ASN.1.
    -- D'autres applications peuvent les utiliser.
    
IMPORTS
    -- Imports de la rfc 3280, Appendix A.1
        AlgorithmIdentifier
            FROM PKIX1Explicit88 { iso(1)
                identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } ;
    
    -- Algorithm Identifiers
    
    sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }
    
    md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }
    
    id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
    
    id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 }
    
    rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
    
    md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
    
    sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
    
    dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
    
    id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
    
    id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
    
    id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
    
    id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
    
    des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
    
    rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2 }
    
    hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
    
    id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
    
    -- Public Key Types
    
    Dss-Pub-Key ::= INTEGER -- Y
    
    RSAPublicKey ::= SEQUENCE {
        modulus INTEGER, -- n
        publicExponent INTEGER } -- e
    
    DHPublicKey ::= INTEGER -- y = g^x mod p
    
    -- Signature Value Types
    
    Dss-Sig-Value ::= SEQUENCE {
        r INTEGER,
        s INTEGER }
    
    -- Algorithm Identifier Parameter Types
    
    Dss-Parms ::= SEQUENCE {
        p INTEGER,
        q INTEGER,
        g INTEGER }
    
    DHDomainParameters ::= SEQUENCE {
        p INTEGER, -- odd prime, p=jq +1
        g INTEGER, -- generator, g
        q INTEGER, -- factor of p-1
        j INTEGER OPTIONAL, -- subgroup factor
        validationParms ValidationParms OPTIONAL }
    
    ValidationParms ::= SEQUENCE {
        seed BIT STRING,
        pgenCounter INTEGER }
    
    KeyWrapAlgorithm ::= AlgorithmIdentifier
    
    RC2wrapParameter ::= RC2ParameterVersion
    
    RC2ParameterVersion ::= INTEGER
    
    CBCParameter ::= IV
    
    IV ::= OCTET STRING -- exactly 8 octets
    
    RC2CBCParameter ::= SEQUENCE {
        rc2ParameterVersion INTEGER,
        iv OCTET STRING } -- exactly 8 octets
    
    PBKDF2-params ::= SEQUENCE {
        salt CHOICE {
            specified OCTET STRING,
            otherSource AlgorithmIdentifier },
        iterationCount INTEGER (1..MAX),
        keyLength INTEGER (1..MAX) OPTIONAL,
        prf AlgorithmIdentifier
            DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
    
END -- of CryptographicMessageSyntaxAlgorithms

Considérations de sécurité

   La technique de gestion de clé employée pour distribuer les clé d'authentification de message doit elle-même fournir l'authentification, sinon le contenu est délivré avec l'intégrité depuis une source inconnue. Ni RSA, ni Ephemeral-Static Diffie-Hellman ne fournissent l'authentification de l'origine des données nécessaires. Static-Static Diffie-Hellman fournis l'authentification de l'origine des données nécessaire quand l'auteur et les clés publiques des destinataires sont liés aux entités appropriés dans les certificats X.509.

   Quand plus de 2 parties partagent la même clé d'authentification de message, l'authentification de l'origine des donnée n'est pas fournie. Toutes les parties qui connaissent la clé d'authentification de message peuvent calculer un MAC valide, donc le contenu pourrait venir de n'importe lequel de ces parties.

   Les implémentations doivent générer des clé de chiffrement de contenu, de clé d'authentification de message, des vecteurs d'initialisation, des valeurs one-time aléatoirement, et du padding. Également, la génération de paires de clé publique/privées assure des nombres aléatoires. L'utilisation inadéquate de générateurs de nombre pseudo-aléatoires pour générer des valeurs peut engendrer des problèmes de sécurité. Un attaquant peut trouver qu'il est plus facile de reproduite l'environnement PRNG qui de produire les clé, en cherchant le plus petit jeu de possibilités résultants, au lieu de brute forcer tout l'espace de clé. La génération de nombre aléatoires de qualité est difficile. Les rfc1750 offre un guide important dans ce but, et l'appendice 3 de FIPS Pub 186 fournis une technique PRNG de qualité.

   En utilisant les algorithmes d'agrément de clé ou des clé de chiffrement de clé symétrique précédemment distribués, une clé de chiffrement de clé est utilisée pour chiffrer la clé de chiffrement de contenu. Si les algorithmes de chiffrement de clé et de chiffrement de contenu sont différents, la sécurité effective est déterminée par le plus faible des 2. Les implémenteurs doivent s'assurer que les algorithmes de chiffrement de clé sont aussi fort sinon plus que les algorithmes de chiffrement de contenu.

   La rfc 3217 spécifie des algorithmes d'enveloppe de clé utilisés pour chiffrer une clé de chiffrement de contenu Triple-DES avec une clé de chiffrement de clé Triple-DES ou pour chiffrer un clé de chiffrement de contenu RC2 avec une clé de chiffrement de clé RC2. Les algorithmes d'enveloppe de clé utilisent le mode CBC, et ont été revus pour l'utilisation avec Triple-DES et RC2. Ils n'ont pas été revus pour l'utilisation avec d'autres modes cryptographiques ou d'autres algorithmes de chiffrement. Cependant, si une implémentation CMS souhaite supporter d'autres chiffrements, les algorithmes d'enveloppe de clé additionnels doivent être définis pour supporter ces chiffrements additionnels.

   Les implémenteurs devraient vérifier si les algorithmes cryptographiques deviennent faible dans le temps. De nouvelles techniques de cryptanalyse sont développées et les performances de calcul s'améliorent, Le facteur temps pour casser un algorithme cryptographique sera réduit. Cependant, les implémentations d'algorithmes crytographiques devraient être modulaires permettant aux nouveaux algorithmes d'être facilement insérés.

   Les utilisateurs de CMS, particulièrement ceux employant le CMS pour le support d'applications intéractives, devraient savoir que RSA, comme spécifié dans la rfc 2313, est vulnérable à des attaques de texte chiffré choisis lorsqu'il est appliqué à des fins de chiffrement. L'exploitation de cette vulnérabilité identifiée, révélant le résultat d'un déchiffrement RSA particulier, nécessite l'accès à un oracle qui répondra à un grand nombre de textes chiffrés (basé sur les résultats disponibles actuellement), qui sont construits adaptivement en réponse à une réponse reçue précédemment fournissant des informations sur la réussite ou l'échec des opération de déchiffrement tentés. En résultat, l'attaque apparaît significativement moins faisable dans les environnements S/MIME store-and-forward que pour les protocoles intéractif.

   Une version mises à jours de PKCS#1 a été publiée, la version 2.0, qui préserve le support pour le format de padding de chiffrement, et définis une nouvelle alternative. Pour résoudre la vulnérabilité, la version 2.0 spécifie et recommande l'utilisation de OAEP quand RSA est utilisé pour fournir la confidentialité. Voir la rfc 3218 pour plus d'informations sur la vulnérabilité de PKCS#1 version 1.5.
^
27 novembre 2014

htmlpdflatexmanmd




rfc5652

rfc5652

Syntaxe de message cryptographique

Définitions

   Ce document décris la syntaxe de message cryptographique (CMS). Cette syntaxe est utilisée pour signer, hasher, authentifier ou chiffrer numériquement du contenu de message arbitraire.

   Le CMS décris une syntaxe d'encapsulation pour la protection des données. Il supporte les signatures et chiffrement numérique. La syntaxe permet plusieurs encapsulations; un enveloppe d'encapsulation peut être imbriquée dans une autre. Également, une partie peut signer une donnée précédemment encapsulée. Il peut également des attributs arbitraires, telle que la date de signature.

   Le CMS peut supporter divers architectures pour la gestion de clé basé sur les certificats, tes que celui définis par le groupe de travail PKIX.

   Les valeurs CMS sont générées en utilisant ASN.1, utilisant l'encodage BER. Les valeurs sont typiquement représentées comme chaîne d'octets. Bien que de nombreux systèmes sont capable de transmettre des chaînes d'octet arbitraires de manière sûre, il est bien connu que les systèmes de messagerie électronique ne le sont pas. Ce document n'adresse pas les mécanismes pour encoder les chaînes d'octets pour une transmission sûre dans de tels environnements.

Évolution de CMS

   Le CMS est dérivé de PKCS#7 version 1.5, qui est documenté dans la rfc 2315. PKCS#7 a été publié à l'origine comme note technique des laboratoires RSA en novembre 1993. IETF a depuis repris la responsabilité pour le développement et la maintenance du CMS. Aujourd'hui, de nombreux protocoles IETF utilisent CMS. Cette section décris les changement que l'IETF a fait de CMS dans chaque version publiée.

Changements depuis PKCS#7 version 1.5

   la rfc 2630 [CMS1] était la première version de CMS. Quand cela est possible, la compatibilité avec PKCS#7 a été préservée; cependant, des changements fait pour accueillir le transfert de l'attribut certificat version 1 et pour supporter la gestion de clé indépendamment de l'algorithme. PKCS#7 version 1.5 incluait le support seulement pour le transport des clé. la rfc 2630 ajoute le support pour l'accord de clé et les techniques de chiffrement de clé symétrique distribués précédemment.

Changements depuis la rfc 2630

   La rfc 3369 [CMS2] remplace la rfc 2630 et la rfc 3211. La gestion de clé basé sur des mots de passe est inclue dans la spécification CMS et un mécanisme d'extension pour supporter de nouveau schémas de gestion de clé dans avoir à changer le CMS est spécifié. La compatibilité avec la rfc 2630 et la rfc3211 est préservée. Cependant, le transfert d'attribut de certificat version 2 est ajouté, et l'utilisation des attributs de certificat version 1 est déprécié.

   Les signatures S/MIME v2, qui sont basées sur PKCS#7 v1.5, sont compatibles avec les signature S/MIME v3 et v3.1. Cependant, il y a quelques problème subtiles de compatibilité avec les signatures basées sur PKCS#7 v1.5.

   Les algorithmes de chiffrement spécifiques ne sont pas discutés dans ce document, mais ont été discutés dans la rfc 2630. La discussion des algorithmes de chiffrement on été placés dans les document séparés.

Changements depuis la rfc 3369

   La rfc 3852 [CMS3] remplace la rfc 3369. Comme discuté dans la précédente section, la rfc 3369 a introduit un mécanisme d'extension pour supporter de nouveaux schémas de gestion de clé. La rfc 3852 introduit un mécanisme d'extension similaire pour supporter des formats de certificats additionnels et les formats d'information de status de révocation.

Changement depuis la rfc 3852

   Ce document remplace la rfc 3852. La raison principale pour la publication de ce document est de faire progresser le CMS avec la maturité des standards. Ce document inclus la clarification qui était originellement publiée dans la rfc 4853 concernant la manipulation correcte du type de contenu SignedData quand plus d'une signature numérique est présente.

Numéros de version

   Chacune des structures de donnée majeur inclus un numéro de version comme premier élément de la structure. Les numéros de version. Les numéro de version sont prévus pour éviter les erreurs de décodage ASN.1. Certaines implémentations ne vérifient pas le numéro de version avant de tenter un décodage, et si une erreur est rencontrée, le numéro de version est vérifié. C'est une approche raisonnable.

   La plupart des numéros de version initiales ont été assignés dans PKCS#7 v1.5. D'autre ont été assignés quand la structure a été créée initialement. Quand une structure est mise à jours, un numéro de version supérieur est assigné. Cependant, pour s'assurer d'une interopérabilité maximale, le numéro de version supérieur est uniquement utilisé quand une nouvelle syntaxe est employée.

Vue générale

   Le CMS est suffisamment généraliste pour supporter de nombreux types de contenu différents. Ce document définis une protection de contenu, ContentInfo. ContentInfo encapsule un type de contenu identifié simple, et le type identifié peut fournir d'autres encapsulations. Ce document définis 6 types de contenu: donnée, donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée et donnée authentifiée. Des types de contenu additionnels peuvent être définis en dehors de ce document.

   Une implémentation qui se conforme à cette spécification doit implémenter le contenu de protection, ContentInfo, et doit implémenter les types de contenu donnée, donnée hashé donnée chiffrée, et donnée authentifiée. Les autres type de contenu peuvent être implémentés.

   Comme philosophie de design générale, chaque type de contenu permet un traitement en une seule passe en utilisant l'encodage BER à longueur indéfinie. L'opération single-pass est spécifiquement utile si le contenu est grand, stocké sur cassettes, ou pipé depuis un autre processus. Une opération simple passe a un inconvénient important: il est difficile d'effectuer des opérations d'encodage en utilisant DER dans une simple passe vu que les longueurs des divers composants peuvent ne pas être connus à l'avance. Cependant, les attributs signés dans le type de contenu donnée signée et les attributs authentifiés dans le type de contenu donnée authentifiée doivent être transmis sous la forme DER pour s'assurer que le destinataire puisse vérifier un contenu qui contiendrait un ou plusieurs attributs non-reconnus. Les attributs signés et les attributs authentifiés sont les seuls types de donnée utilisées dans le CMS qui nécessitent un encodage DER.

Syntaxe générale

Les identifiants d'objet suivants identifient le type d'information de contenu:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

Le CMS associe un identifiant de type de contenu avec un contenu. La syntaxe doit avoir le type ASN.1 ContentInfo:
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }
    
    ContentType ::= OBJECT IDENTIFIER

contentType Indique le type de contenu associé. C'est un identifiant d'objet; c'est une chaîne unique d'entiers assignés par une autorité qui définie le type de contenu.
content Est le contenu associé. Le type de contenu peut être déterminé de manière unique par le contentType. Les types de contenus pour donnée, donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée et donnée chiffrée sont définies dans ce document. Si d'autres types de contenu sont définis dans d'autres documents, le type ASN.1 définis ne devrait pas être un type CHOICE.

Type de contenu donnée

L'identifiant d'objet suivant identifie le type de contenu donnée:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   Le type de contenu donnée est prévu pour référer à des chaînes d'octets arbitraires, tels que des fichiers texte ASCII; l'interprétation est laissée à l'application. De telles chaînes n'ont pas besoin de structure interne ( bien qu'ils peuvent avoir leur propre définition ASN.1 ou d'autre structure ). S/MIME utilis id-data pour identifier le contenu encodé MIME. L'utilisation de cet identifiant de contenu est spécifié dans la rfc 2311 pour S/MIME v2, rfc 2633 pour S/MIME v3, et rfc 3851 pour S/MIME v3.1. Le type de contenu donnée est généralement encapsulée dans un type de contenu donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée, ou donnée authentifiée.

Type de contenu donnée signée

   Le type de contenu donnée signée consiste d'un contenu de n'importe quel type et 0 ou plusieurs valeurs de signatures. Plusieurs signataires en parallèle peuvent signer un type de contenu.

   L'application typique du type de contenu donnée signée représente la signature numérique d'un signataire sur le contenu d'un type de contenu donnée. Une autre application typique est la diffusion de certificats et le listes de révocation de certificats. Le processus par lequel une donnée signée est construite est composé des étapes suivantes:

1. Pour chaque signataires, un hash est calculé sur le contenu avec un algorithme de hash spécifique au signataire. Si le signataire signe une information autre que le contenu, le hash du contenu et les autres informations sont hashées avec l'algorithme de hashage du signataire, et le résultat devient le hash.
2. Pour chaque signataire, le hash est signé numériquement en utilisant la clé privée du signataire.
3. Pour chaque signataire, la valeur de signature et d'autres informations spécifiques au signataire sont collectées dans une valeur SignerInfo. Les certificats et CRL pour chaque signataire, et ceux ne correspondant pas à un signataire, sont collectées dans cette étape.
4. Les algorithmes de hash et les valeurs SignerInfo pour tous les signataires sont collectés ensemble avec le contenu dans une valeur SignedData.

   Un destinataire calcule de manière indépendante le hash. Ce hash est la clé publique du signataire sont utilisés pour vérifier la valeur de la signature. La clé publique du signataire est référencée d'un des 2 manières. Elle peut être référencée par un dn de fournisseur avec un numéro de série de fournisseur pour identifier de manière unique le certificat qui contient la clé publique. Alternativement, elle peut être référencéé par un identifiant de clé du sujet, qui reçoit les clé publiques certifiés et non-certifiés. Bien qui ce ne soit pas requis, le certificat du signataire peut être inclu dans le champ des certificates du SignedData.

   Quand plus d'une signature est présente, la réussite de la validation d'une signature associée avec un signataire donné est généralement traitée comme une signature réussie dans le signataire. Cependant, il y a certaines application où d'autres règles sont nécessaires. Une application qui emploie une règle autre qu'une signature valide pour chaque signataire doit spécifier ces règles. Également, là où une simple correspondance de l'identifiant du signataire n'est pas suffisant pour déterminer si les signatures ont été générées par le même signataire, l'application doit décrire comment déterminer quelles signatures ont été générées par le même signataire. Le support de différentes communautés des bénéficiaires est la principale raison qui les signataires choisissent d'inclure plus d'une signature.

   Par exemple, le type de contenu donnée signée peut inclure des signatures générées avec l'algorithme de signature RSA et avec l'algorithme de signature à courbe elliptique (ECDSA). Celà permet aux destinataires de vérifier la signature associée avec un algorithme ou l'autre.

   Cette section est divisée en 6 parties. La première décris le type SignedData, la seconde décris EncapsulatedContentInfo, la troisième décris les information par signataire SignerInfo, la quatrième, cinquième et sixième décrivent le calcule du hash, génération de signature, et processus de vérification de signature.

Type SignedData

L'identifiant d'objet suivant identifie le type de contenu donnée signée:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Le type de contenu donnée signée devrait avoir le type ASN.1:
SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }
    
    DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
    
    SignerInfos ::= SET OF SignerInfo

version Est le numéro de version de syntaxe. La valeur appropriée dépend des certificats, eContentType et SignerInfo. a version doit être assignée comme suit:


IF ((certificates is present) AND
    (any certificates with a type of other are present)) OR
    ((crls is present) AND
    (any crls with a type of other are present))
THEN version MUST be 5
ELSE
    IF (certificates is present) AND
        (any version 2 attribute certificates are present)
    THEN version MUST be 4
    ELSE
        IF ((certificates is present) AND
            (any version 1 attribute certificates are present)) OR
            (any SignerInfo structures are version 3) OR
            (encapContentInfo eContentType is other than id-data)
        THEN version MUST be 3
        ELSE version MUST be 1

digestAlgorithm Est une collection d'identifiant d'algorithme de hash. Il peut y avoir plusieurs éléments dans la collection, incluant 0. Chaque élément identifie l'algorithme de hash, avec leur paramètres associés, utilisés par un ou plusieurs signataires. La collection est prévue pour lister les algorithmes de hash employées par tous les signataires, dans n'importe quel ordre, pour faciliter la vérification de signature en une passe. Les implémentations peuvent échouer la validation des signatures qui utilisent un algorithme qui n'est pas inclus dans ce set.
encapContentInfo Est le contenu signé, consistant d'un identifiant de type de contenu et le contenu lui-même.
certificates Est une collection de certificats. Il est prévu que ce jeu de certificat soit suffisant pour contenir les chemins de certification depuis un root reconnus vers tous les signataires dans le champ signerInfos. Il peut y avoir plus de certificats qui nécessaire, et il peut y avoir suffisamment de certificats pour contenir les chemins de certification depuis 2 ou plusieurs autorités de certification racine indépendante. Il peut y avoir moins de certificats qui nécessaire, s'il est prévu que les destinataires ont un moyen alternatif pour les obtenir. Le certificat du signataire peut être inclus. L'utilisation de la version 1 de l'attribut certificates est fortement découragée.
crls Est une collection d'information de status de révocation. Il est prévu qui la collection contienne les information suffisantes pour déterminer si les certificats dans le champ certificates sont valides, mais une telle correspondance n'est pas nécessaire. Les CRL sont la principale source d'information de status de révocation. Il peut y avoir plus de CRL que nécessaire, et il peut y avoir moins de crl qui nécessaire.
signerInfos Est une collection d'information par signataire. Il peut y avoir plusieurs éléments dans la collection, incluant 0. Quand la collection représente plus d'une signature, la réussite de la validation d'une signature d'un signataire donné doit être traitée comme une signature réussie par le signataire. Cependant, il y a certaines applications où d'autres règles sont nécessaire. Vu que chaque signataire peut employer une technique de signature différente, et de futures spécifications peut mettre à jours la syntaxe, toutes les implémentations doivent manipuler les versions non-implémentées de SignerInfo. De plus, toutes les implémentations doivent manipuler les algorithmes de signature non-implémentées quand elles sont rencontrées.

Type EncapsulatedContentInfo

Le contenu est représenté dans le type EncapsulatedContentInfo:
EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL }
    
    ContentType ::= OBJECT IDENTIFIER

eContentType Est un identifiant d'objet.
eContent Est le contenu lui-même, il n'a pas besoin d'être encodé DER.

   L'omission optionnelle de eContent avec le champ EncapsulatedContentInfo rend possible la contruction de signatures externes. Dans le cas de signatures externes, le contenu à signer est absent de la valeur EncapsulatedContentInfo inclus dans le type de contenu donnée signée. Si la valeur eContent dans EncapsulatedContentInfo est absent, signatureValue est calculée et le eContentType est assignée comme si la valeur eContent était présente.

   Dans le cas dégénéré où il n'y a pas de signataires, la valeur EncapsulatedContentInfo à signer est sans importance. Dans ce cas, le type de contenu avec la valeur EncapsulatedContentInfo à signer doit être id-data, et le champ content de la valeur EncapsulatedContentInfo doit être omise.

Compatibilité avec PKCS#7

   Cette section contient un mot d'alerte pour les implémenteurs qui souhaites supporter les type de contenu SignedData CMS et PKCS#7. CMS et PKCS#7 identifient le type de contenu encapsulé avec un identifiant d'objet, mais le type ASN.1 du contenu lui-même est variable dans le type de contenu SignedData PKCS#7.

PKCS#7 définis le contenu:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
Le CMS définis eContent:
eContent [0] EXPLICIT OCTET STRING OPTIONAL

   La définition de CMS est plus facile à utiliser dans la plupart des applications, et est compatible avec S/MIME v2 et v3. les messages signés S/MIME utilisant CMS et PKCS#7 sont compatibles parce que les format de message signés identique sont spécifiés dans les rfc 2311, 2633 et 3851. S/MIME v2 encapsule le contenu MIME dans un type Data ( un OCTET STRING ) dans le contenu contentInfo de SignedData, et S/MIME v2 le porte dans le eContent encapContentInfo SignedData. Cependant, dans S/MIME v2, v3 et v3.1, le contenu MIME est placé dans un OCTET STRING et le hash est calculé sur les portions identiques de contenu.

   Il y a des incompatibilités entre les type SignedData de CMS et PKCS#7 qui le contenu encapsulé n'est pas formaté en utilisant le type Data. Par exemple, qui un reçu signé rfc3634 est encapsulé dans le type SignedData CMS, le Receipt SEQUENCE est encodé dans le SignedData encapContentInfo eContent OCTET STRING et le hash est calculé en utilisant tous l'encodage Receipt SEQUENCE ( incluant le tag, longueur et octets de valeurs). Cependant, si un reçu signé rfc2634 est encapsulé dans le type SignedData PKCS#7, alors le Receipt SEQUENCE est encodé DER dans le contenu SignedData contentInfo (une SEQUENCE, par un OCTET STRING). Cependant, le hash est calculé en utilisant seulement les octets de valeur de l'encodage de Receipt SEQUENCE.

   La stratégie suivante peut être utilisée pour la compatibilité avec PKCS#7 en traitant les type de contenu SignedData. Si l'implémentation n'est pas capable de décoder l'ASN.1 du type SignedData en utilisant la syntaxe CMS SignedData encapContentInfo eContent OCTET STRING, alors l'implémentation peut tenter de décoder le type SignedData en utilisant une syntaxe de contenu PKCS#7 SignedData contentInfo et calculer le hash.

   La stratégie suivante peut être utilisé pour la compatibilité avec PKCS#7 en créant un type de contenu SignedData dans lequel le contenu encapsulé n'est pas formaté en utilisant le type Data. Les implémentations peuvent examiner la valeur de eContentType, et ainsi ajuster l'encodage DER attendu de eContent basé sur la valeur de l'identifiant d'objet. Par exemple pour supporter MSAC, les informations suivantes peuvent être inclus:


    eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
    
    eContent contains DER-encoded Authenticode signing information

Type SignerInfo

Les information par signataire sont représentés dans le type SignerInfo:
SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
    
SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }
    
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }
    
AttributeValue ::= ANY
    
SignatureValue ::= OCTET STRING

version Est le numéro de version de syntaxe. Si SignerIdentifier est le choix issuerAndSerialNumber, la version doit être 1. Si SignerIdentifier est sibjectKeyIdentifier, la version doit être 3.
sid Spécifie le certificat du signataire ( et donc sa clé publique). La clé publique du signataire est nécessaire au destinataire pour vérifier la signature.

   SignerIdentifier fournis 2 alternatives pour spécifier la clé publique du signataire. L'alternative issuerAndSerialNumber identifie le certificat du signataire par le dn du fournisseur et le numéro de série du certificat; le subjectKeyIdentifier identifie le certificat du signataire par un identifiant de clé. Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extention subjectKeyIdentifier. Quand d'autres formats de certificats sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclure les détails sur le matching d'identifiant de clé du champ certificat approprié. Les implémentations doivent supporter la réception des formes issuerAndSerialNumber et subjectKeyIdentifier.

   En générant un SignerIdentifier les implémentations peuvent supporter une des formes ( soit issuerAndSerialNumber soit subjectKeyIdentifier) et toujours l'utiliser, ou les implémentations peuvent arbitrairement mixer les 2 formes. Cependant, subjectKeyIdentifier doit être utilisé pour référer à une clé publique contenue dans un certificat non-X.509.

digestAlgorithm Identifie l'algorithme de hash, et ses paramètres associés, utilisés par le signataire. Le hash est calculé sur soit le contenu à signer soit le contenu et les attributs signés en utilisant le processus décris plus bas. l'algorithme de hash devrait être listé dans le champ digestAlgorithms du SignerData associé. Les implémentations peuvent échouer si ce n'est pas le cas.
signedAttrs Est une collection d'attributs qui sont signés. Le champ est optionnel, mais il doit être présent si le type de contenu de la valeur EncapsulatedContentInfo à signer n'est pas id-data. SignedAttributes doit être encodé DER, même si le reste de la structure set encodée BER. Les types d'attributs utiles, tels qu'une date de signature, sont définis plus loin dans ce document. Si le champ est présent, il doit contenir, au minimum, les 2 attributs suivants:

        content-type ayant comme valeur le type de contenu de la valeur EncapsulatedContentInfo à signer. Cependant, cet attribut ne doit pas être utilisé comme partie d'un attribut contersignatures non-signé
        message-digest ayant comme valeur le hash du contenu.

signatureAlgorithm identifie l'algorithme de signature, et ses paramètres associés, utilisé par le signataire pour générer la signature numérique.
signature Est le résultat de la génération de la signature, en utilisant le hash et la clé privée du signataire.
unsignedAttrs Est une collection d'attributs qui ne sont pas signés. Ce champ est optionnel.

   Les champs de type SignedAttributes et UnsignedAttributes ont la signification suivante:

attrType Indique le type d'attribut, c'est un identifiant d'objet.
attrValues Est un jeu de valeurs pour cet attribut.

Processus de calcul du hash

   Le processus de calcul du hash calcule un hash sur soit le contenu à signer, soit le contenu et les attributs signés. Dans tous les cas, l'entrée initiale du processus est la valeur du contenu encapsulé à signer. Spécifiquement, l'entrée initiale est la chaîne d'octets eContent de encapContentInfo auquel le processus de signature est appliqué. Seul les octets comprenant la valeur de la chaîne d'octets eContent sont entrés dans l'algorithme de hashage, et non le tag ou les octets de longueur.

   Le résultat du processus de calcul du hash dépend de la présence ou non du champ signedAttrs. Quand le champ est absent, le résultat est simplement le hash du contenu. Quand le champ est présent, cependant, le résultat est le hash de l'encodage DER complet de la valeur SignedAttrs contenu dans le champ signedAttrs. Vu que la valeur SignedAttrs, quand présent, doit contenir les attributs de type de contenu et de hash, ces valeurs sont indirectement incluses dans le résultat. L'attribut content-type ne doit pas être inclus dans un attribut non signé countersignature. Un encodage séparé du champ signedAttrs est effectué pour le calcul du hash. Le IMPLICIT [0] tag dans signedAttrs n'est pas utilisé pour l'encodage DER, et EXPLICIT SET OF tag est utilisé, et doit donc être inclus dans le calcul du hash avec les octets de longueur et de contenu de la valeur SignedAttributes.

   Quand le champ signedAttrs est absent, seul les octets compris dans la valeur de la chaîne d'octets eContent de encapContentInfo du SignedData sont entrés dans le calcul du hash. Cela a l'avantage que la longueur du contenu à signer n'a pas besoin d'être connus à l'avance.

   Bien que le les octets de tag et de longueur de la chaîne d'octets eContent de encapContentInfo ne sont pas inclus dans le calcul du hash, ils sont protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme.

Processus de génération de signature

   L'entrée du processus de génération de signature inclus le résultat du processus de calcul du hash et la clé privée du signataire. Les détails de la génération de la signature dépend de l'algorithme de signature employé. L'identifiant d'objet, avec ses paramètres, qui spécifient l'algorithme de signature employé par le signataire sont placés dans le champ signatureAlgoritm. La valeur de la signature générée par le signataire doit être encodé en chaîne d'octets et placés dans le champ signature.

Processus de vérification de signature

   L'entrée du processus de vérification de signature inclus le résultat du processus de calcul du hash et la clé publique du signataire. Le destinataire peut obtenir la bonne clé publique pour le signataire par tous moyens, mais la méthode préférée est depuis un certificat obtenu depuis le champ certificates de SignedData. La sélection et la validation de la clé publique du signataire peut être basée sur la validation du chemin de certification aussi bien que d'autres contextes externes, mais c'est au-delà du scope de ce document. Les détails de la vérification de la signature dépendent de l'algorithme de signature employé.

   Le destinataire ne doit pas s'appuyer sur les valeurs de hash calculés par l'auteur. Si le signerInfo de SignedData inclus un SignedAttributes, alors le hash doit être calculé comme décris plus haut. Pour que la signature soit valide, la valeur du hash calculée par le destinataire doit être la même que la valeur de l'attribut messageDigest inclus dans le signedAttributes du signerInfo du SignedData.

   Si signerInfo du SignedData inclus signedAttributes, alors la valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo du signedData.

Type de contenu Enveloped-data

   Le type de contenu donnée enveloppée consiste d'un contenu chiffré et de clé de chiffrement de contenu chiffrés pour un ou plusieurs destinataires. La combinaison du contenu chiffré et un clé de chiffrement de contenu chiffré pour un destinataire est une enveloppe numérique pour ce destinataire. Tout type de contenu peut être enveloppé pour un nombre arbitraire de destinataires utilisant tout type de technique de gestion de clé supportés pour chaque destinataire.

   L'application typique du type de contenu donnée enveloppée représente une ou plusieurs enveloppes numérique de destinataires sur le contenu des type de de contenu donnée et donnée signée. Enveloped-data est construit par les étapes suivantes:

1. Une clé de chiffrement pour un algorithme de chiffrement de contenu est généré aléatoirement.
2. La clé de chiffrement de contenu est chiffrée pour chaque destinataire. Les détails de ce chiffrement dépend de l'algorithme de gestion de clé utilisé, mais 4 techniques générales sont supportées:

        transport de clé La clé de chiffrement de contenu est chiffrée dans la clé publique clé publique du destinataire.
        agrément de clé La clé publique du destinataire est la clé privée de l'émetteur sont utilisé pour générer une clé symétrique, puis la clé de chiffrement de contenu est chiffré dans la clé symétrique.
        Clé de chiffrement symétrique La clé de chiffrement de contenu est chiffré dans un clé de chiffrement de clé symétrique distribuée précédemment.
        mot de passes La clé de chiffrement de contenu est chiffrée dans une clé de chiffrement de contenu qui est dérivée d'un mot de passe ou autre valeur de secret partagée.

3. Pour chaque destinataire, la clé de chiffrement de contenu chiffré et d'autres informations spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Le contenu est chiffré avec la clé de chiffrement de contenu. Le chiffrement de contenu peut nécessiter qui le contenu soit padded à un multiple d'une taille de block.
5. Les valeurs RecipientInfo pour tous les destinataires sont collectés ensemble avec le contenu chiffré pour former une valeur enveloppée.

   Un destinataire ouvre l'enveloppe numérique en déchiffrant celle qui contient les clé de chiffrement de contenu chiffrés puis déchiffre le contenu chiffré avec la clé de chiffrement de contenu récupéré.

   Cette section est divisée en 4 parties. La première partie décris le type EnvelopedData, la seconde partie décris le type d'information par destinataire RecipientInfo, et les troisième et quatrième partie décrivent le chiffrement de contenu et les processus de chiffrement de clé.

Type EnvelopedData

L'identifiant d'objet suivant identifie le type de contenu enveloped-data suivant:
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Le type donnée enveloppée devrait avoir le type ASN.1 suivant:
EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
    
OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
    
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
    
EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
    
EncryptedContent ::= OCTET STRING
    
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

version Est le numéro de version de la syntaxe. La valeur appropriée dépend de originatorInfo, RecipientInfo, et unprotectedAttrs. La version doit être assignée comme suit:


IF (originatorInfo is present) AND
    ((any certificates with a type of other are present) OR
    (any crls with a type of other are present))
THEN version is 4
ELSE
    IF ((originatorInfo is present) AND
        (any version 2 attribute certificates are present)) OR
        (any RecipientInfo structures include pwri) OR
        (any RecipientInfo structures include ori)
    THEN version is 3
    ELSE
        IF (originatorInfo is absent) AND
            (unprotectedAttrs is absent) AND
            (all RecipientInfo structures are version 0)
        THEN version is 0
        ELSE version is 2

originatorInfo Fournis optionnellement des informations sur l'auteur. Il est présent seulement s'il est requis par l'algorithme de gestion des clés. Il peut contenir des certificats et des crls:

        certs est une collection de certificats. certs peut contenir les certificats d'expéditeur associés avec de nombreux algorithmes de gestion de clés. certs peut également contenir des certificats d'attribut associés avec l'expéditeur. Les certificats contenus dans certs sont prévus pour être suffisants pour tous les destinataires pour construire des chemin de validation depuis un root reconnu. Cependant, certs peut contenir plus de certificats que nécessaire, et il peut y avoir les certificats nécessaire pour créer les chemins de validation de 2 ou plusieurs autorité de certification racine. Alternativement, il est prévu que les destinataires aient un moyen alternatif pour obtenir les certificats nécessaires.
        crls est une collection de CRL. Il est prévu que ce jeu contienne les informations suffisantes pour déterminer si les certificats dans le champ certs sont valides ou non. Il peut y avoir plus de CRL que nécessaire, et il peut y avoir moins de crl que nécessaire.

recipientInfos est une collection d'information par destinataire, il doit y avoir au moins un élément dans la collection.
encryptedContentInfo Est l'information de contenu chiffré
unprotectedAttrs est une collection d'attributs qui ne sont pas chiffrés. Le champ est optionnel.
EncryptedContentInfo Les champs ont la signification suivante:

        contentType Indique le type de contenu
        contentEncryptionAlgorithm identifie l'algorithme de chiffrement de contenu, et ses paramètres associés, utilisés pour chiffrer le contenu. Le même algorithme de chiffrement de contenu et la clé de chiffrement de contenu sont utilisé pour tous les destinataires.

Type RecipientInfo

   Les informations par destinataire sont représentés dans le type RecipientInfo. RecipientInfo a un format différent pour chacune des techniques de gestion de clés supportés. Tout type de technique de gestion de clé peut être utilisé pour chaque destinataire de même contenu chiffré. Dans tous les cas, la clé de chiffrement de contenu chiffrée est transféréeà un ou plusieurs destinataires.

   Vu que toutes les implémentations ne vont pas supporter tous les algorithmes de gestion de clés possibles, toutes les implémentations doivent gérer les algorithmes non-implémentés quand ils sont rencontrés. Par exemple, si un destinataire reçoit une clé de chiffrement de contenu chiffrée avec leur clé publique RSA en utilisant RSA-OAEP et que l'implémentation ne supporte que RSA PKCS#1 v1.5, alors l'échec doit être implémentée.

   Les implémentations doit supporter le transport de clé, l'agrément de clé, et les clé de chiffrement de clé symétriques distribués précédemment, comme représentés par ktri, kari, et kekri, respectivement. Les implémentations peuvent supporter la gestion de clé basé sur mot de passe comme représenté par pwri. Les implémentations peuvent supporter d'autres technique de gestion de clé comme représenté par ori. Vu que chaque destinataire peut employer une technique de gestion de clé différente et que les spécifications futures peuvent définir des technique supplémentaires, toutes les implémentation doit manipuler les alternatives non-implémentées, les versions non-implémentées et les ori inconnues.


RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientinfo,
    ori [4] OtherRecipientInfo }
    
    EncryptedKey ::= OCTET STRING

Type KeyTransRecipientInfo

Les informations par destinataire utilisant le transport de clé sont représentés dans le type KeyTransRecipientInfo. Chaque instance de KeyTransRecipientInfo transfert la clé de chiffrement de contenu à un destinataire.
KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

version Est le numéro de version de la syntaxe. Si RecipientIdentifier est issuerAndSerialNumber, la version doit être 0. Si c'est subjectKeyIdentifier, la version doit être 2.
rid Spécifie le certificat ou la clé du destinataire qui a été utilisé par l'émetteur pour protéger la clé de chiffrement de contenu. RecipientIdentifier fournis 2 alternatives pour spécifier le certificat du destinataire, et donc la clé publique du destinataire. Le certificat du destinataire doit contenir une clé publique de transport de clé. Donc, un certification X.509v3 d'un destinataire qui contient un extension d'utilisation de clé doit avoir le bin keyEncipherment. L'alternative issuerAndSerialNumber identifie le certificat du destinataire par le dn du fournisseur et le numéro de série du certificat; le sibjectKeyIdentifier identifie le certificat du destinataire par un identifiant de clé.

           Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extension subjectKeyIdentifier X.509. Quand d'autres formats de certificat sont référencés, les documents qui spécifient le format du certificat et son utilisation avec le CMS doit inclure les détails sur la correspondance le l'identifiant de clé. Pour le traitement du destinataire, les implémentations doivent supporter ces alternatives pour spécifier le certificat du destinataire. Pour l'émetteur, les implémentations doivent supporter au moins un de ces alternatives.

keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisés pour chiffrer la clé de chiffrement de contenu pour le destinataire.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu pour le destinataire.

Type KeyAgreeRecipientInfo

Les informations de destinataire utilisant l'accord de clé est représenté dans le type KeyAgreeRecipientInfo. Chaque instance de KeyAgreeRecipientInfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui utilisent le même algorithme d'accord de clé et les paramètres de domaine pour cet algorithme.
KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys }
    
OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey }
    
OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }
    
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
    
RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey }
    
KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }
    
SubjectKeyIdentifier ::= OCTET STRING

version Est le numéro de version de la syntaxe. Doit toujours être 3.
originator Est un choix avec 3 alternatives spécifiant la clé publique de l'accord de clé de l'émetteur. L'émetteur utilise la clé privée correspondant et la clé publique du destinataire pour générer une clé paire. La clé de chiffrement de contenu est chiffrée dans la clé paire. L'alternative issuerAndSerialNumber identifie le certificat de l'émetteur, et donc sa clé publique, par dn de fournisseur et numéro de série. l'alternative subjectKeyIdentifier identifie le certificat de l'émetteur par identifiant de clé.

           Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extension X.509 subjectKeyIdentifier. Quand d'autres format de certificat sont référencés, les documents qui spécifient le format de certificat et son utilisation avec le CMS doit inclure les détails sur le matche d'identifiant de clé. L'alternative originatorKey inclus l'identifiant d'algorithme et la clé publique d'accord de clé de l'émetteur. Cette alternative permet à l'auteur l' anonymité vu que la clé publique n'est pas certifiée. Les implémentations doivent suppporter les 3 alternatives pour spécifier la clé publique de l'émetteur.

ukm est optionnel. Avec certains algorithmes d'accord de clé, l'émetteur fournis un User Keying Material (UKM) pour s'assurer qu'une clé différente est générée chaque fois que les même 2 parties génèrent une clé paire. Les implémentations doivent accepter une séquence KeyAgreeRecipientInfo qui inclus un champ ukm. Les implémentations qui ne supportent par les algorithmes d'accord de clé qui utilisent UKM doivent manipuler correctement la présence des UKM.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé.
recipientEncryptedKeys Inclus un identifiant de destinataire et une clé chiffrée pour un ou plusieurs destinataires. le KeyAgreeRecipientIdentifier est un choix avec 2 alternatives spécifiant le certificat du destinataire, et donc sa clé publique, qui a été utilisée par l'émetteur pour générer un clé de chiffrement de clé paire. Le certificat du destinataire doit contenir une clé publique d'accord de clé. Donc, un certificat X.509 v3 d'un destinataire qui contient une utilisation de clé étendue doit avoir le bit keyAgreement. La clé de chiffrement de contenu est chiffrée dans la clé de chiffrement de clé paire. L'alternative issuerAndSerialNumber identifie le certificat du destinataire par dn du fournisseur et numéro de série. encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu dans la clé de chiffrement de clé paire générée en utilisa l'algorithme d'accord de clé. Les implémentations doivent supporter ces alternatives en spécifiant le certificat du destinataire.
subjectKeyIdentifier Identifie le certificat du destinataire par identifiant de clé.
date est optionnel. Quand présent, la date spécifie celle du précédent UKM distribué précédemment qui a été utilisé par l'émetteur.
other est optionnel. Quand présent, ce champ contient des informations additionnels utilisé par le destinataire pour localiser l'UKM utilisé par l'émetteur.

Type KEKRecipientInfo

Les informations de déstinataire utilisant les clés symétriques précédemment distribuées sont représentés dans le type KEKRecipientInfo. Chaque instance de KEKRecipientInfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui ont la clé de chiffrement de clé distribuée précédemment.
KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

version est le numéro de version de la syntaxe. Doit être 4.
kekid spécifie un clé de chiffrement de clé symétrique qui a été distribué précédemment à l'émetteur en un ou plusieurs destinataires.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu dans la clé de chiffrement de clé.
keyIdentifier identifie la clé de chiffrement de clé qui a été précédemment distribuée à l'émetteur et un ou plusieurs destinataires.
date optionnel. Quand présent, la date spécifie un clé de chiffrement de clé simple depuis un jeu qui a été distribué précédemment.
other optionnel. Quand présent, ce champ contient des informations optionnelles utilisées par le destinataire pour déterminer la clé de chiffrement de clé utilisée par l'émetteur.

Type PasswordRecipientinfo

Les information de destinataire utilisant un mot de passe ou une valeur secrète partagée est représentée dans le type PasswordRecipientinfo. Chaque instance de PasswordRecipientinfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui possède un mot de passe ou une valeur secrète partagée. Le type PasswordRecipientinfo est définie dans la rfc3211:
PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- Always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
     OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

version est le numéro de version de la syntaxe. Doit être 0.
keyDerivationAlgorithm identifie l'algorithme de dérivation de clé et ses paramètres associés, utilisé pour dériver la clé de chiffrement de clé du mot de passe ou de la valeur secrète partagée. Si ce champ est absent, la clé de chiffrement de clé est fournie depuis une source externe, par example, un jeton cryptographique physique tel qu'une carte à puce.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu avec la clé de chiffrement de clé.

Type OtherRecipientinfo

Les information de destinataire pour les techniques de gestion de clé additionnels sont représentés dans le type OtherRecipientInfo. Le type OtherRecipientInfo permet aux technique de gestion de clé au delà des type précédemment définis d'être spécifiés dans de futures documents. Un identifiant d'objet identifie de manière unique de telles techniques de gestion de clé.
OtherRecipientInfo ::= SEQUENCE {
    oriType OBJECT IDENTIFIER,
    oriValue ANY DEFINED BY oriType }

oriType identifie la technique de gestion de clé
oriValue contient les éléments de données du protocole nécessaire pour un destinataire utilisant la technique de gestion de clé identifiée.

Processus de chiffrement de contenu

   La clé de chiffrement de contenu pour l'algorithme de chiffrement de contenu désiré est généré aléatoirement. La donnée à protéger est padded comme décris plus bas, puis cette donnée est chiffrée en utilisant la clé de chiffrement de contenu. L'opération de chiffrement mappe une chaîne d'octets arbitraire (la donnée) en une autre chaîne d'octets (le texte chiffré) sous le contrôle d'une clé de chiffrement de contenu. La donnée chiffrée est inclue dans encryptedContent de encryptedContentInfo du EnvelopedData.

Certains algorithmes de chiffrement de contenu assument que la longueur d'entrée est un multiple de k octets, où k est supérieur à 1. Pour de tels algorithmes, l'entrée devrait être complétée à la fin avec des octets k-(lth mod k) ayant pour valeur (k-lth mod k), où lth est la longueur de l'entrée. En d'autres termes, l'entrée est complétées à la fin avec une des chaînes suivantes:
__________01 -- if lth mod k = k-1
_______02 02 -- if lth mod k = k-2
__________.
__________.
__________.
k k ... k k -- if lth mod k = 0

   Le padding peut être supprimé de manière non ambigu vu que toute l'entrée est paddée, incluant les valeurs d'entrée qui sont déjà un multiple de la taille de block, et aucune chaîne de padding n'est un suffix d'un autre. Cette méthode de padding est définie si et seulement si k est inférieur à 256.

Processus de chiffrement de clé

   L'entrée du processus de chiffrement de clé -- la valeur fournie à l'algorithme de chiffrement de clé du destinataire -- est simplement la valeur de la clé de chiffrement de contenu.

   N'importe quelle technique de gestion de clé mentionnées dans ce document peuvent être utilisées pour chaque destinataire de même contenu chiffré.

Type de contenu Digested-Data

   Le type de contenu donnée hashée consiste d'un contenu de n'importe quel type et un hash du contenu. Typiquement, le type de contenu donnée hashée est utilisé pour fournir une intégrité de contenu, et le résultat devient généralement un entrée au type de contenu donnée enveloppée. Les étapes suivantes construisent une donnée hashée:

1. Un hash est calculé sur le contenu avec un algorithme de hashage.
2. L'algorithme de hashage et le hash sont collectés ensemble avec le contenu dans une valeur DigestedData.

   Un destinataire vérifie le hash en comparant le hash à un hash calculé indépendamment.

L'identifiant d'objet suivant identifie le type de contenu digested-data:
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Le type de contenu digested-data devrait avoir le type ASN.1:
DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest }
    
Digest ::= OCTET STRING

version est le numéro de version de la syntaxe. Si le type de contenu incapsulé est id-data, la valeur doit être 0, 2 sinon.
digestAlgorithm identifie l'algorithme de hashage et ses paramètres associés.
encapContentInfo est le contenu qui est hashé
digest est le résultat du processus de hashage.

   L'ordre des champs rend possible le traitement d'un valeur DigestedData en une seule passe.

Type de contenu Encrypted-data

   Le type de contenu donnée chiffrée consiste d'un contenu de n'importe quel type, chiffré. À la différence du type de contenu donnée enveloppée, le type de contenu donnée chiffrée n'a ni destinataire, ni clé de chiffrement de contenu. Les clé doivent être gérées par un autre moyen.

   L'application typique du type de contenu chiffré est de chiffré le contenu du type de contenu donnée pour un stockage local, où la clé de chiffrement est dérivée d'un mot de passe.

L'identifiant d'objet suivant identifie le type de contenu encrypted-data:
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

Le type de contenu encrypted-data devrait avoir le type ASN.1:
EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

version est le numéro de version de la syntaxe. si unprotectedAttrs est présent, la version doit être 2, 0 sinon.
encryptedContentInfo est le contenu chiffré
unprotectedAttrs est une collection d'attributs qui ne sont pas chiffrés. Ce champ est optionnel.

Type de contenu Authenticated-data

   Le type de contenu donnée authentifiée consiste d'un contenu de n'importe quel type, un MAC, et de clés d'authentification chiffrés pour un ou plusieurs destinataires. La combinaison du MAC et d'une clé d'authentification chiffrée pour un destinataire est nécessaire pour que ce destinataire puisse vérifier l'intégrité du contenu. Tout type de contenu peut être protégé pour l'intégrité pour plusieurs destinataires.

  Le processus par lequel un donnée authentifiée est construite est faite des étapes suivantes:

1. Une clé d'authentification de message pour un algorithme d'authentification de message particulier est généré aléatoirement.
2. La clé d'authentification de message est chiffrée pour chaque destinataire. Les détails de ce chiffrement dépend de l'algorithme de gestion de clé utilisé.
3. Pour chaque destinataire, la clé d'authentification de message chiffrée et les autres information spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Un utilisant la clé d'authentification de message, l'auteur calcul une valeur MAC sur le contenu. Si l'auteur authentifie une information en plus du contenu, un hash est calculé sur le contenu, le hash du contenu est les autres informations sont authentifiées en utilisant la clé d'authentification de message, et le résultat devient la valeur MAC.

Type AuthenticatedData

L'identifiant d'objet suivant identifie le type de contenu authenticated-data:
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

Le type de contenu authenticated-data devrait avoir le type ASN.1:
AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
    
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
MessageAuthenticationCode ::= OCTET STRING

version est le numéro de version de la syntaxe. La version doit êtré assignée comme suit:

IF (originatorInfo is present) AND
    ((any certificates with a type of other are present) OR
    (any crls with a type of other are present))
THEN version is 3
ELSE
    IF ((originatorInfo is present) AND
        (any version 2 attribute certificates are present))
    THEN version is 1
    ELSE version is 0

originatorInfo fournis optionnellement des informations sur l'auteur. Il est présent seulement s'il est requis par l'algorithme de gestion de clé. Il peut contenir des certificats, des attributs de certificat, et des CRLs.
recipientInfos Est une collection d'information par destinataire. Il doit y avoir au moins un élément dans la collection.
macAlgorithm est un identifiant d'algorithme MAC. Il identifie l'algorithme MAC et ses paramètres associés, utilisé par l'auteur.
digestAlgorithm identifie l'algorithme de hashage et ses paramètres associés, utilisé pour calculer un hash sur le contenu encapsulé si des attributs authentifiés sont présents. Si ce champ est présent, authAttrs doit l'être également.
authAttrs est une collection d'attributs authentifiés. La structure AuthAttributes doit être encodé DER, même si le reste du la structure est encodée BER. Si cet attribut est présent, il doit contenir au minimum ces 2 attributs:

        content-type ayant comme valeur le type de contenu de la valeur EncapsulatedContentInfo qui est authentifée.
        message-digest ayant comme valeur le hash du contenu.

mac est le message authentication code
unauthAttrs est une collection d'attributs non authentifiés. Ce champ est optionnel.

Génération du MAC

   Le processus de calcul du MAC calcule un code d'authentification de message sur soit le contenu à authentifier soit un hash du contenu à authentifier avec les attributs authentifié de l'auteur.

   Si le champ authAttrs est absent, l'entrée du processus de calcul MAC est la valeur de la chaîne d'octets de eContent dans encapContentInfo. Seul les octets comprenant la valeur de eContent sont entrées dans l'algorithme MAC; le tag et les octets de longueur sont omis. Cela a l'avantage que la longueur du contenu à authentifier n'a pas besoin d'être connu à l'avance.

   Si le champ authAttrs est présent, les attributs content-type et message-digest doivent être inclus, et l'entrée dans le processus de calcul du mac est l'encodé DER de authAttrs. Un encodage séparé du champ authAttrs est effectué pour un calcul de hash. Le tag implicite dans le champ authAttrs n'est pas utilisé pour l'encodage DER, un jeu explicite de tag est utilisé à la place. ce qui signifie que l'encodé DER du jeu de tag, au lieu du tag implicite, doit être inclus dans le calcul du hash avec les octets de longueur et de contenu de la valeur authAttrs.

   Le processus de calcule du hash calcul un hash sur le contenu à authentifier. L'entrée initiale du processus de calcul du hash est la valeur du contenu encapsulé à authentifier. Spécifiquement, l'entrée est la chaîne d'octets de eContent de encapContentInfo pour lequel le processus d'authentification est appliqué. Seul les octets comprenant la valeur de la chaîne d'octets eContent de encapContentInfo sont entrés dans l'algorithme de hashage, pas le tag ni les octets de longueur. Cela a l'avantage que la longueur du contenu n'a pas besoin d'être connu à l'avance. Bien que le tag et les octets de longueur ne sont pas inclus dans le calcul du hash, il sont protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme de hashage.

   L'entrée du processus de calcul MAC inclus la donnée d'entrée MAC définie précédemment, et une clé d'authentification transportée dans une structure recipientInfo. Les détails du calcul MAC dépend de l'algorithme utilisé. L'identifiant d'objet et ses paramètres, qui spécifie l'algorithme employé par l'auteur est placé dans le champ macAlgorithm. La valeur MAC générée par l'auteur est encodé en chaîne d'octet dans le champ mac.

Vérification du MAC

   L'entrée du processus de vérification du MAC inclus les donnée d'entrée ( déterminées sur la présence ou non du champ authAttrs), et la clé d'authentification dans recipientInfo. Les détails du processus de vérification du MAC dépend de l'algorithme MAC employé.

   Le destinataire ne doit pas se fier aux valeurs MAC et hash de l'auteur. Pour que l'authentification réussisse, la valeur MAC calculée par le destinataire doit être la même que la valeur du champ mac. Similairement, pour que l'authentification réussisse quand le champ authAttrs est présent, le hash du contenu calculé par le destinataire doit être le même que le hash inclus dans l'attribut message-digest.

   Si AuthenticatedData inclus authAttrs, la valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo de AuthenticatedData.

Types utiles

   Cette section est divisée en 2 parties. La première définis les identifiants d'algorithme, et la seconde définie d'autres type utiles.

DigestAlgorithmIdentifier

   Le type DigestAlgorithmIdentifier identifie un algorithme de hashage. (ex: SHA-1, MD2, et MD5). Un algorithme de hashage mappe un chaîne d'octets ( le contenu ) en une autre chaîne d'octets ( le hash ).

  DigestAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureAlgorithmIdentifier

   Le type SignatureAlgorithmIdentifier identifie un algorithme de signature, et peut également identifier un algorithme de hashage. (ex: RSA, DSA, DSA avec SHA-1, ECDSA, et ECDSA avec SHA-256). Un algorithme de signature supporte les opérations de génération et de vérification de signature. L'opération de génération de signature utilise le hash et la clé privée du signataire pour générer une valeur signature. L'opération de vérification de signature utilise le hash et la clé publique du signataire pour déterminer si la signature est valide.

  SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

KeyEncryptionAlgorithmIdentifier

   Le type KeyEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de clé pour chiffrement une clé de chiffrement de contenu. L'opération de chiffrement mappe une chaîne d'octets ( la clé ) en une autre chaîne d'octets ( la clé chiffrée ) sous le contrôle de la clé de chiffrement. L'opération de déchiffrement est l'inverse de l'opération de chiffrement. Les détails du chiffrement et du déchiffrement dépendent de l'algorithme de gestion de clé utilisé.

  KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier

   Le type ContentEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de contenu. (ex: Triple-DES et RC2). Un algorithme de chiffrement de contenu supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement mappe une chaîne d'octets ( le texte en clair ) en une autre chaîne d'octets ( le texte chiffré ) sous le contrôle de la clé de chiffrement de contenu. L'opération de déchiffrement est l'inverse de l'opération de chiffrement.

  ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

MessageAuthenticationCodeAlgorithm

KeyDerivationAlgorithmIdentifier

   Le type KeyDerivationAlgorithmIdentifier est spécifié dans la rfc 3211. Les algorithmes de dérivation de clé convertissent un mot de passe ou une valeur de clé secrète en une clé de chiffrement de clé.

  KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

RevocationInfoChoices

   Le type RevocationInfoChoices donne un jeu d'informations de statut de révocation alternatif. Il est prévu que le jeu contienne les informations suffisantes pour déterminer si les certificats et les attributs de certificat avec lequel le jeu est associé sont révoqués. Cependant, il peut y avoir plus d'informations de statut de révocation que nécessaire. Les listes de révocation de certificats X.509 sont la principale source d'informations de statut de révocation, mais tout autre format d'information de révocation peut être supporté. L'alternative OtherRevocationInfoFormat est fournis pour supporter tout autre format de révocation sans modification du CMS.

   CertificateList peut contenir un CRL, une ARL, un Delta CRL, ou un attribut CRL. Toutes ces listes partagent une syntaxe commune. Le type CertificateList donne une CRL. les CRL sont spécifiés dans X.509, et sont prévus pour être utilisés sur l'Internet.

La définition de CertificateList est prise de X.509:
RevocationInfoChoices ::= SET OF RevocationInfoChoice
    
RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat }
    
OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat }

CertificateChoices

Le type CertificateChoices donne soit un certificat étendus PKCS#6, un ACv1, ACv2, ou tout autre format. L'alternative OtherCertificateFormat est fournis pour supporter tout autre format de certificat sans modification du CMS.
CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat }
    
OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat }

CertificateSet

   Le type CertificateSet fournis un jeu de certificats. Il est prévu que le jeu soit suffisant pour contenir des chemins de certification depuis une autorité racine vers tour les certificats de l'émetteur avec lequel le jeu est associé. Cependant, il peut y avoir plus de certificats que nécessaire, ou moins que nécessaire.

   La signification précise d'un chemin de certification est hors du scope de ce document. Certaines applications peuvent imposer des limites maximales sur la longueur d'un chemin de certification; d'autre peuvent forcer certaines relations entre les sujets et les fournisseurs de certificats dans un chemin de certification.

  CertificateSet ::= SET OF CertificateChoices

IssuerAndSerialNumber

   Le type IssuerAndSerialNumber identifie un certificat, et donc une entité et une clé publique, par le nom distinct du fournisseur du certificat et un numéro de série de certificat spécifique au fournisseur.

La définition de Name vient de X.501-88 et de CertificateSerialNumber vient de X.509-97:
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }
    
CertificateSerialNumber ::= INTEGER

CMSVersion

   Le type CMSVersion donne un numéro de version de syntaxe, pour la compatibilité avec de futures révisions de cette spécification.

  CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

UserKeyingMaterial

   Le type UserKeyingMaterial donne une syntaxe pour UKM. Certains agréments de clé nécessitent UKM pour s'assurer qu'une clé différente est générée à chaque fois que les même 2 parties génèrent une clé pairée. L'émetteur fournis un UKM à utiliser avec un algorithme d'agrément de clé spécifique.

  UserKeyingMaterial ::= OCTET STRING

OtherKeyAttribute

Le type OtherKeyAttribute donne une syntaxe pour inclure d'autres attributs de clé qui permettent au destinataire de sélectionner la clé utilisé par l'émetteur. L'identifiant d'objet d'attribut doit être enregistré avec la syntaxe de l'attribut lui-même. L'utilisatino de cette structure devrait être évité vu qu'il peut entraver l'intéropérabilité
OtherKeyAttribute ::= SEQUENCE {
    keyAttrId OBJECT IDENTIFIER,
    keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

Attributs utiles

   Cette section définis les attributs qui peuvent être utilisés avec signed-data, enveloped-data, encrypted-data, ou authenticated-data. La syntaxe de l'attribut est compatible avec X.501. Certains des attributs définis dans cette section ont été définis à l'origine dans PKCS#9; d'autres ont été définis dans une précédente version de cette spécification. Les attributs ne sont pas listés dans un ordre particulier.

   D'autres attributs sont définis ailleurs, notamment dans S/MIME v3.1 et dans ESS, qui inclus également des recommandations sur le placement de ces attributs.

Content Type

   Le type d'attribut content-type spécifie le type de contenu de ContentInfo dans une donnée signée ou une donnée authentifié. L'attribut content-type doit être présent quand des attributs signés sont présents dans une donnée signée ou que des attributs authentifiés sont présents dans une donnée authentifiée. La valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo dans la donnée signée ou la donnée authentifiée.

   L'attribut content-type doit être un attribut signé ou un attribut authentifié; il ne doit pas être un attribut non-signé, non-authentifié, ou non-protégé.

L'identifiant d'objet suivant identifie l'attribut content-type:
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

Les valeurs d'attribut content-type ont le type ASN.1:
ContentType ::= OBJECT IDENTIFIER

   Même si la syntaxe est définie comme un jeu d'AttributeValue, un attribut content-type doit avoir un simple valeur d'attribut. 0 ou plusieurs instances de AttributeValue ne sont pas permis.

   Les syntaxe SignedAttributes et AuthAttributes sont chacun définis comme un jeu d'attributs. SignedAttributes dans un signerInfo ne doit pas inclure plusieurs instances de l'attribut content-type. Similairement, AuthAttributes dans un AuthenticatedData ne doit pas inclure plusieurs instances de l'attribut content-type.

Message Digest

   Le type d'attribut message-digest spécifie la hash de la chaîne d'octet eContent de encapContentInfo à signer dans une donnée signée, ou à authentifier dans une donnée authentifiée. pour une donnée signée, le hash est calculé en utilisant l'algorithme de hashage du signataire. Pour une donnée authentifiée, le hash est calculé en utilisant l'algorithme de hashage de l'auteur.

   Dans une donnée signée, le type d'attribut signé message-digest doit être présent quand il y a des attributs signés. dans une donnée authentifiée, le type d'attribut authentifié message-digest doit être présent quand il à des attribut authentifiés.

   L'attribut message-digest doit être un attribut signé ou un attribut authentifié; il ne doit pas être un attribut non-signé, non-authentifié, ou non-protégé.

L'indentifiant d'objet suivant identifie l'attribut message-digest:
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

Les valeurs d'attribut message-digest ont le type ASN.1:
MessageDigest ::= OCTET STRING

   Un attribut message-digest doit avoir une valeur d'attribut simple, même si la syntaxe est définie comme un jeu d'AttributValue. Il ne doit pas y avoir 0 ou plusieurs instances de AttributeValue.

   La syntaxe SignedAttributes et AuthAttributes sont chacun définis comme jeu d'attributs. SignedAttributes dans un signerInfo doit inclure seulement une instance de l'attribut message-digest. Similairement, AuthAttributes dans un AuthenticatedData doit inclure seulement une instance de l'attribut message-digest.

Signing Time

   Le type d'attribut signing-time spécifie la date à laquelle le signataire a effectué la signature. Le type d'attribut signing-time est prévu pour être utilisé dans une donnée signée. Il doit être un attribut signé, ou un attribut authentifié.

L'identifiant d'objet suivant identifie l'attribut signing-time:
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Les valeurs de l'attribut signing-time ont le type ASN.1:
SigningTime ::= Time
    
Time ::= CHOICE {
    utcTime UTCTime,
    generalizedTime GeneralizedTime }

   Note: la définition de Time matche celui spécifié dans la version 1997 de X.509. Les dates entre le 1 janvier 1950 et le 31 décembre 2049 (inclus) doit être encodé en UTCTime. Toutes dates en dehors de cette plage doivent être encodés en GeneralizedTime.

   Les valeurs UTCTime doivent être exprimés en Coordinated Universal Time ( GMT ) et doivent inclure les secondes ( YYMMDDHHMMSSZ), même où le nombre de secondes est 0. Minuit doit être représenté "YYMMDD000000Z". L'information du siècle est implicit, et le siècle doit être interprété comme suit:

        - où YY est supérieur ou égal à 50, l'année doit être interprétée en 19YY
        - où YY est inférieur ou égal à 50, l'année doit être interprétée en 20YY.

   Les valeurs GeneratizedTime doivent être exprimées en GMT et doivent inclure les secondes ( YYYYMMDDHHMMSSZ ), même quand le nombre de seconde est 0. Les valeurs GeneralizedTime ne doivent pas inclure des fractions de secondes.

   Un attribut signing-time doit avoir une valeur d'attribut simple, même si la syntaxe est définie comme jeu d'AttributeValue. Il ne doit pas y avoir 0 ou plusieurs instances d'AttributeValue.

   La syntaxe SignedAttributes et la syntaxe AuthAttributes sont chacun définis comme jeu d'attributs. SignedAttributes dans un signerInfo ne doit pas inclure plusieurs instances de l'attribut signing-time. Similairement, AuthAttributes dans un AuthenticatedData ne doit pas inclure plusieurs instances de l'attribut signing-time.

   Aucun prérequis n'est imposé concernant l'exactitude de la date de signature, et l'acceptation d'une date de signature est laissée à la discretion du destinataire. Il est prévu, cependant, que certains signataires, tels que les serveurs time-stamp, vont l'approuver implicitement.

Countersignature

   Le type d'attribut Countersignature spécifie une ou plusieurs signatures sur les octets de contenu de la chaîne d'octets signature dans une valeur signerInfo d'une donnée signée. C'est à dire que le hash est calculé sur les octets comprenant la valeur de la chaîne d'octets, sans inclure le tag ni les octets de longueur. Donc, le type d'attribut countersignature contre-signe ( signe en série) une autre signature.

   L'attribut countersignature doit être un attribut non signé, il ne doit pas être un attribut signé, un attribut authentifié, un attribut non-authentifié, ou un attribut non-protégé.

L'identifiant d'objet suivant identifie l'attribut countersignature:
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

Les valeurs d'attribut countersignature ont le type ASN.1:
Countersignature ::= SignerInfo

   Les valeurs countersignature ont la même signification que les valeurs SignerInfo pour les signatures ordinaires, excepté:

        1. le champ signedAttributes ne doit pas contenir un attribut content-type, il n'y a pas de type de contenu pour les contre-signatures
        2. Le champ signedAttributes doit contenir un attribut message-digest s'il contient d'autres attributs
        3. L'entrée du processus de hashage sont les octets de contenu de l'encodé DER du champ signatureValue de la valeur SignerInfo avec lequel l'attribut est associé.

   Un attribut countersignature peut avoir plusieurs valeurs d'attribut. La syntaxe est définie comme jeu d'AttributeValue, et il doit y avoir au moins une valeur présente.

   La syntaxe UnsignedAttributes est définie comme un jeu d'attributs. UnsignedAttributes dans un SignerInfo peut inclure plusieurs instances de l'attribut countersignature.

   Un countersignature, vu qu'il a le type SignerInfo, peut lui-même contenir un attribut countersignature. Donc, il est possible de construire arbitrairement une longue série de contre-signatures.

Modules ASN.1

   Cette section contient le module ASN.1 pour le CMS, et la section suivante contient le module ASN.1 pour l'attribut certificat version 1.

Module ASN.1 CMS


CryptographicMessageSyntax2004
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
    
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
    
-- EXPORTS All
-- Les types et valeurs définies dans ce module sont exportés pour l'utilisation dans
-- d'autres modules ASN.1. D'autres applications peuvent les utiliser pour leur propre usage.
    
IMPORTS
    
    -- Imports de la RFC 5280, Appendix A.1
        AlgorithmIdentifier, Certificate, CertificateList,
        CertificateSerialNumber, Name
            FROM PKIX1Explicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }
    
    -- Imports de la RFC 3281, Appendix B
        AttributeCertificate
            FROM PKIXAttributeCertificate
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) attribute-cert(12) }
    
    -- Imports de l'Appendix B de ce document
        AttributeCertificateV1
            FROM AttributeCertificateVersion1
                { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } ;
    
-- Cryptographic Message Syntax
    
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }
    
ContentType ::= OBJECT IDENTIFIER
    
SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }
    
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
    
SignerInfos ::= SET OF SignerInfo
    
EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL }
    
SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
    
SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }
    
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }
    
AttributeValue ::= ANY
    
SignatureValue ::= OCTET STRING
    
EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
    
OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
    
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
    
EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
    
EncryptedContent ::= OCTET STRING
    
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
    
RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientInfo,
    ori [4] OtherRecipientInfo }
    
EncryptedKey ::= OCTET STRING
    
KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }
    
KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys }
    
OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey }
    
OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }
    
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
    
RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey }
    
KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }
    
RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }
    
SubjectKeyIdentifier ::= OCTET STRING
    
KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }
    
PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
OtherRecipientInfo ::= SEQUENCE {
    oriType OBJECT IDENTIFIER,
    oriValue ANY DEFINED BY oriType }
    
DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest }
    
Digest ::= OCTET STRING
    
EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
    
AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
    
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
    
MessageAuthenticationCode ::= OCTET STRING
    
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
    
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
    
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
    
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
    
RevocationInfoChoices ::= SET OF RevocationInfoChoice
    
RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat }
    
OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat }
    
CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat }
    
AttributeCertificateV2 ::= AttributeCertificate
    
OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat }
    
CertificateSet ::= SET OF CertificateChoices
    
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }
    
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
    
UserKeyingMaterial ::= OCTET STRING
    
OtherKeyAttribute ::= SEQUENCE {
    keyAttrId OBJECT IDENTIFIER,
    keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
    
-- Content Type Object Identifiers
    
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
    
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
    
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
    
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
    
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
    
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
    
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }
    
-- The CMS Attributes
    
MessageDigest ::= OCTET STRING
    
SigningTime ::= Time
    
Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime }
    
Countersignature ::= SignerInfo
    
-- Attribute Object Identifiers
    
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
    
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
    
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
    
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
    
-- Obsolete Extended Certificate syntax from PKCS #6
    
ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate }
    
ExtendedCertificate ::= SEQUENCE {
    extendedCertificateInfo ExtendedCertificateInfo,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature Signature }
    
ExtendedCertificateInfo ::= SEQUENCE {
    version CMSVersion,
    certificate Certificate,
    attributes UnauthAttributes }
    
Signature ::= BIT STRING
    
END -- of CryptographicMessageSyntax2004

Module ASN.1 Certificat d'attribut version 1


AttributeCertificateVersion1
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
    
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
    
-- EXPORTS All
    
IMPORTS
    
    -- Imports from RFC 5280 [PROFILE], Appendix A.1
        AlgorithmIdentifier, Attribute, CertificateSerialNumber,
        Extensions, UniqueIdentifier
            FROM PKIX1Explicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }
    
    -- Imports from RFC 5280 [PROFILE], Appendix A.2
        GeneralNames
            FROM PKIX1Implicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-implicit(19) }
    
    -- Imports from RFC 3281 [ACPROFILE], Appendix B
        AttCertValidityPeriod, IssuerSerial
            FROM PKIXAttributeCertificate
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) attribute-cert(12) } ;
    
    -- Définition extraite de X.509-1997, mais des noms de type différents sont utilisés pour éviter les collisions
    
AttributeCertificateV1 ::= SEQUENCE {
    acInfo AttributeCertificateInfoV1,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING }
    
AttributeCertificateInfoV1 ::= SEQUENCE {
    version AttCertVersionV1 DEFAULT v1,
    subject CHOICE {
        baseCertificateID [0] IssuerSerial,
            -- associé avec un certificat à clé publique
        subjectName [1] GeneralNames },
            -- associé avec un nom
    issuer GeneralNames,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL }
    
AttCertVersionV1 ::= INTEGER { v1(0) }
    
END -- of AttributeCertificateVersion1

^
26 novembre 2014

htmlpdflatexmanmd




rfc5208

rfc5208

Syntaxe et conteneur pour les informations de clé privée

Définitions

   Les informations de clé privée incluent une clé privée pour un algorithme à clé publique spécifié, et un jeu d'attributs. La syntaxe de message cryptographique, dénifis dans la rfc5652, peut être utilisé pour signer numériquement, hasher, authentifier ou chiffrer le type de contenu de clé asymétrique.

   La liste suivante sont les mises à jours de la rfc5208:

- PrivateKeyInfo a été changé en OneAsymmetricKey. Cela reflète l'ajout du champ publicKey pour permettre aux 2 parties de la clé asymétrique d'être transportés séparément.
- Définition du type de contenu CMS asymmetric Key Package
- Suppression de la redondance IMPLICIT des attributs
- Ajout de publicKey à OneAsymmetricKey et mise à jour du numéro de version
- Ajout du support des attributs PKCS #9
- Ajout d'une discussion sur la compatibilité avec d'autres formats de clé privée
- Ajout des pré-requis pour le jeu de règle d'encodage
- Changement des imports depuis PKCS #5
- Remplacement de ALGORITHM-IDENTIFIER avec ALGORITHM depuis la rfc 5912
- Enregistrement du type de média application/pkcs8 et de l'extension de fichier .p8

Asymmetric Key Package CMS Content Type

   Le type de contenu CMS paquet de clé asymétrique est utilisé pour transférer une ou plusieurs clé asymétrique d'un partie à un autre. Un paquet de clé asymétrique peut être encapsulé dans un ou plusieurs types de contenu CMS de protection. Les anciennes versions de cette spécification de spécifiaient pas de jeu de règle d'encodage particulier, mais les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER.

Ce type de contenu a la syntaxe suivante:
ct-asymmetric-key-package CONTENT-TYPE ::=
    { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
    
id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
    { joint-iso-itu-t(2) country(16) us(840) organization(1)
        gov(101) dod(2) infosec(1) formats(2)
        key-package-content-types(78) 5
    }
    
AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
    
OneAsymmetricKey ::= SEQUENCE {
    version Version,
    privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
    privateKey PrivateKey,
    attributes [0] Attributes OPTIONAL,
    ...,
    [[2: publicKey [1] PublicKey OPTIONAL ]],
    ...
}
    
PrivateKeyInfo ::= OneAsymmetricKey
    
    -- PrivateKeyInfo est utilisé par [P12]. Si un élément taggé en version 2 est utilisé,
    -- La version doit être v2, sinon la version devrait être 1. Quand v1 est utilisé,
    -- PrivateKeyInfo est le même que dans la [RFC5208].
    
Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)
    
PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
    { PUBLIC-KEY,
        { PrivateKeyAlgorithms } }
    
PrivateKey ::= OCTET STRING
    -- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé
    
PublicKey ::= BIT STRING
    -- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé
    
Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } }

   AsymmetricKeyPackage contient un ou plusieurs élément OneAsymmetricKey.

   La syntaxe de OneAsymmetricKey accueille un numéro de version, une indication de l'algorithme asymétrique à utiliser avec la clé privée, une clé privée, des attributs optionnels ( par ex. userCertificate de X.520 ), et une clé publique optionnelle. En général, doit la clé publique, soit le certificat est présent. Dans de très rare cas les 2 sont présents, vu qu'ils incluent chacun une copie de la clé publique. OneAsymmetricKey renomme la syntaxe PrivateKeyInfo définie dans la rfc5208. Le nouveau nom reflète mieux la capacité de s'occuper des composant clé publique et privée. La compatibilité avec PrivateKeyInfo est préservée via le numéro de version. Les champs dans OneAsymmetricKey sont utilisé comme suit:

version Identifie la version de OneAsymmetricKey. Si publicKey est présent, la version est v2 sinon v1.
privateKeyAlgorithm Identifie l'algorithme de clé privée et optionnellement les paramètres associés avec la paire de clé asymétrique. L'algorithme est identifiée par un OID et le format des paramètres dépend de cet OID, mais le jeu d'objets privateKeyAlgorithms restreins les OID permis. La valeur placée dans PrivateKeyAlgorithmIdentifier est la valeur d'un algorithme utilisé avec la clé privée.
privateKey Est une chaîne d'octets qui contiennent la valeur de la clé privée. L'interprétation du contenu est définis dans l'enregistrement de l'algorithme de clé privée. Par exemple, une clé DSA est un entier, une clé RSA est représentée en RSAPrivateKey comme définis dans la rfc3447, et une clé ECC est représentée comme ECPrivateKey comme définie dans la rfc5915.
attributes est optionnel et contient les informations correspondantes à la clé publique (par ex: les certificats). Les champs attributes utilise la classe ATTRIBUTE qui est restreins par le jeu d'objet OneAsymmetricKeyAttributes. Les attributs de la rfc2985 peuvent être supportés.
publicKey est optionnel. Si présent, il contient la clé publique encodée en chaîne de bits. L structure dans cette chaîne dépend de privateKeyAlgorithm. Par exemple, une clé DSA est un entier. Noter que les clé publiques RSA sont inclues dans RSAPrivateKey, comme dans rfc 3447, et les clé publiques ECC sont inclues dans ECPrivateKey, comme dans rfc 5915.

Informations de clé privée chiffrée

Cette section donne la syntaxe pour les informations de clé privée chiffrée qui sont utilisées par [P12]:
EncryptedPrivateKeyInfo ::= SEQUENCE {
    encryptionAlgorithm EncryptionAlgorithmIdentifier,
    encryptedData EncryptedData }
    
EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    { CONTENT-ENCRYPTION,
        { KeyEncryptionAlgorithms } }
    
EncryptedData ::= OCTET STRING

encryptionAlgorithm Identifie l'algorithme sous lequel les informations de clé privée sont chiffrées.
encryptedData Est le résulta du chiffrement des informations de clé privée.

   Le processus de chiffrement est constitué des étapes suivantes:

1. Les informations de clé privée sont encodées. Les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER
2. Le résultat de la première étape est chiffré avec la clé secrète pour donner une chaîne d'octets, le résultat du processus de chiffrement.

Protection de AsymmetricKeyPackage

   Les types de contenu de protection CMS peuvent être utilisés pour fournir une sécurité à AsymmetricKeyPackage:

SignedData Peut être utilisé pour appliquer une signature numérique à AsymmetricKeyPackage
EncryptedData Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire partagent déjà la clé de chiffrement nécessaire.
EnvelopedData Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire ne partagent pas la clé de chiffrement nécessaire.
AuthenticatedData Peut être utilisé pour protéger AsymmetricKeyPackage avec MAC, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.
AuthEnvelopedData Peut être utilisé pour protéger AsymmetricKeyPackage avec des algorithmes qui supportent de chiffrement authentifié, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.

Considérations d'autres format de clé privée

   Ce document définis la syntaxe et les sémantiques pour un type de contenu qui échange des clé privées asymétriques. Il y a 2 autres formats qui ont été utilisés pour le transport de clé privée asymétiques:

Personal Information Exchange Est une syntaxe transfert pour les informations d'identité personnelle, incluant les clés privées, certificats, divers autres secrets, et des extensions. OneAsymmetricKey, PrivateKeyInfo, et EncryptedPrivateKeyInfo peuvent être inclus dans un message p12. Les informations de clé privée, OneAsymmetricKey et PrivateKeyInfo, sont inclus dans le KeyBag BAG-TYPE P12. EncryptedPrivateKeyInfo est inclu dans le pkcs8ShroudedKeyBag BAG-TYPE P12. Dans les implémentations courantes, les extensions pfx et p12 peuvent être utilisées.
Microsoft's private-key l'extension pvk est utilisé pour des stockages locaux. pvk et p12 ne sont pas interchangeables.

   Pour extraire les information de clé privée du AsymmetricKeyPackage les couches d'encapsulations doivent être enlevées. Au minimum, la couche ContentInfo doit être enlevée. Si le AsymmetricKeyPackage est encapsulée dans une donnée signée, puis les couches SignedData et EncapsulatedContentInfo doivent également être supprimées. C'est la même chose pour EnvelopedData, EncryptedData, et AuthenticatedData. Une fois toutes les couches supprimées, il y a autant de jeux d'information de clé privée qu'il y a de structure OneAsymmetricKey. OneAsymmetricKey et PrivateKeyInfo ont la même structure, donc peuvent être sauvées en tant que fichier p8 ou copiés dans un BAG-TYPE KeyBag p12. Supprimer les couches de sécurité encapsulantes va invalider toute signature et peut exposer la clé.

Les fichiers p8 sont parfois encodés PEM, et dans ce cas utilisent l'extension pem. L'encodage PEM est soit l'encodage Base64 ou de type EncryptedPrivateKeyInfo encodé DER inclus entre:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

ou l'encodage Base64 du PrivateKeyInfo encodé DER entre:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

Media application/pkcs8

Type name: application
Subtype name: pkcs8
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographic private key
Interoperability considerations: The PKCS #8 object inside this media type MUST be DER-encoded PrivateKeyInfo.
Published specification: RFC 5958
Applications which use this media type: Any MIME-compliant transport that processes asymmetric keys.
Additional information: Magic number(s): None
File extension(s): .p8
Macintosh File Type Code(s): Person & email address to contact for further information: Sean Turner ‹turners@ieca.com›
Restrictions on usage: none
^
10 novembre 2014

htmlpdflatexmanmd




rfc2315

rfc2315

Syntaxe des messages cryptographiques

Définitions

   Pour ce document, les définitions suivantes s'appliquent:

AlgorithmIdentifier un type qui identifie un algorithme et ses paramètres associés. Ce type est définis dans X.509.
ASN.1 Abstract Syntax Notation One, définis dans X.208
Attribute un type qui contient un type d'attribut et une ou plusieurs valeurs d'attribut. Ce type est définis dans X.501.
BER Basic Encoding Rules, comme définis dans X.209
Certificat un type qui lie un dn d'une entité à une clé publique avec une signature numérique. Ce type est définis dans X.509. Ce type contient également le dn du fournisseur du certificat, un numéro de série, l'algorithme de signature, et une période de validité.
CertificateSerialNumber un type qui identifie de manière unique un certificat avec ceux signés par un fournisseur de certificat particulier. Ce type est définis dans X.509.
CertificateRevocationList un type qui contient des informations sur les certificats dont la validité a été prématurément révoquée par le fournisseur.
DER Distinguished Encoding Rules for ASN.1, comme définis dans X.509
DES Data Encryption Standard, comme définis dans FIPS PUB 46-1
desCBC L'identifiant d'objet pour DES en mode cipher-block chaining
ExtendedCertificate Un type qui consiste d'un certificat X.509 et un jeu d'attributs, signés collectivement par le fournisseur du certificat. Définis dans PKCS#6
MD2 RSA Data Security, incluant l'algorithme MD2. rfc1319
md2 L'identifiant d'objet pour MD2
MD5 RSA Data Security, incluant l'algorithme MD5. rfc1321
md5 L'identifiant d'objet pour MD5
Name Un type qui identifie de manière unique des objets dans un annuaire X.500. Ce type est définis dans X.501. Dans un certificat X.509, le type identifie de fournisseur du certificat et l'entité dont la clé publique est certifiée.
PEM Internet Privacy-Enhanced, comme définis dans rfc1421-1424
RSA Le crypto-système à clé publique RSA
rsaEncryption L'identifiant d'objet pour le chiffrement RSA

Vue générale

   La syntaxe est suffisamment généraliste pour supporter de nombreux types de contenus. Ce document en définis 6: donnée, donnée signée, donnée enveloppée, donnée enveloppée et signée, donnée hashée et donnée chiffrée. D'autres types peuvent être ajoutés dans le future. L'utilisation des types de contenu définis en dehors de ce document est possible, mais est sujet à agrément bilatéral entre les parties échangeant du contenu.

   Ce document exporte un type, ContentInfo, et divers identifiants d'objets.

   Il y a 2 classes de type de contenu: base et amélioré. Les types de contenu dans la classe de base contient seulement les donnée, sans amélioration cryptographique. Présentement, un type de contenu est dans cette classe, le type de contenu donnée. Les types de contenus dans la classe améliorée contiennent le contenu d'un certain type (possiblement chiffré), et d'autre améliorations cryptographique. Par exemple, le contenu donnée enveloppée peut contenir du contenu de données signée, qui peut contenir du contenu donnée. Les 4 type de contenu non données remplissent la classe améliorée. Les types de contenu dans la classe améliorée emploient ainsi l'encapsulation, donnent naissance au termes de contenu extérieur ( celui contenant les améliorations) et de contenu intérieur ( celui qui est amélioré ).

   Le document est conçu de manière à ce que les types de contenus améliorés puissent être préparés dans une simple classe en utilisant un encodage BER de longueur indéfinie. L'opération à une seule passe est spécialement utile si le contenu est stockée sur des cassettes, ou est pipé depuis un autre processus. Un des inconvénients de l'opération simple-passe est qu'il est difficile de sortir un encodé DER en une simple passe, vu que la longueur de divers composants peuvent ne pas être connus à l'avance. Vu que l'encodage DER est requis par les type de contenu donnée signée, donnée signé et enveloppée, donnée hashée, une passe supplémentaire peut être nécessaire quand un type de contenu autre que donnée est le contenu interne de l'un de ces types de contenu.

Types utiles

   Les sections suivantes définissent les types qui sont utiles dans au moins 2 endroits dans le document.

CertificateRevocationLists

   Le type CertificateRevocationList donne un jeu de listes de révocation de certificat. Il est conçus pour que le jeu d'informations soit suffisant pour déterminer si les certificats avec lequel le jeu est associé est "hot listed" mais il peut y avoir plusieurs listes de révocation que nécessaire, ou moins que nécessaire.

  CertificateRevocationLists ::= SET OF CertificateRevocationList

ContentEncryptionAlgorithmIdentifier

   Le type ContentEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de contenu tel que DES. Un algorithme de chiffrement de contenu supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement map une chaîne d'octets ( le message ) en une autre chaîne d'octet ( le texte chiffré ) sous le contrôle de la clé de chiffrement de contenu. L'opération de déchiffrement est l'inverse.

  ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

DigestAlgorithmIdentifier

   Le type DigestAlgorithmIdentifier identifie un algorithme de hashage, ex. MD2 et MD5. Un algorithme de hashage mappe une chaîne d'octets ( le message ) en une autre chaîne d'octets ( le hash ).

  DigestAlgorithmIdentifier ::= AlgorithmIdentifier

DigestEncryptionAlgorithmIdentifier

   Le type DigestEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de hash avec lequel un hash peut être chiffré. Par exemple, rsaEncryption. Un algorithme de chiffrement de hash supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement mappe une chaîne d'octets ( le hash ) a une autre chaîne d'octets ( le hash chiffré ) sous le contrôle d'une clé de chiffrement de hash. L'opération de déchiffrement est l'inverse.

  DigestEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ExtendedCertificateOrCertificate

Le type ExtendedCertificateOrCertificate donne soit un certificat étendu PKCS#6 ou un certificat X.509. Ce type suit la syntaxe recommandée dans PKCS#6:
ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate, -- X.509
    extendedCertificate [0] IMPLICIT ExtendedCertificate }

ExtendedCertificatesAndCertificates

   le type ExtendedCertificatesAndCertificates donne un jeu de certificats étendus et de certificats X.509. Il est conçus pour que le jeu soit suffisant pour contenir des chaînes depuis un "root" ou "top-level certification authority" vers tous les signataires avec lequel le jeu est associé, mais il peut y avoir plus de certificats que nécessaire, ou moins.

  ExtendedCertificatesAndCertificates ::= SET OF ExtendedCertificateOrCertificate

IssuerAndSerialNumber

Le type IssuerAndSerialNumber identifie un certificat ( et donc une entité et une clé publique ) par le nom distinct du fournisseur du certificat et un numéro de série spécifique au fournisseur.
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }

KeyEncryptionAlgorithmIdentifier

   Le type KeyEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de clé avec lequel une clé de chiffrement de contenu peut être chiffrée. Ex: rsaEncryption.

  KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

Version

   Le type Version donne un numéro de version de syntaxe, pour compatibilité avec de future révisions de ce document.

Syntaxe générale

La syntaxe générale pour le contenu échangé entre les entités en accord avec ce document associe un type de contenu avec le contenu. La syntaxe devrait avoir le ContentInfo en ASN.1:
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content
    [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
    
ContentType ::= OBJECT IDENTIFIER

contentType Indique le type de contenu. C'est un OID, qui signifie que c'est un chaîne unique assignée par l'autorité qui définis le type de contenu.
content Est le contenu. Ce champ est optionnel, et si non présent, sa valeur attendu doit être fournie par d'autres moyens.

Notes

        1. Les méthodes ci-dessous assument que le type de contenu peut être déterminé uniquement par le contentType, donc le type définis avec l'oid ne devrait par être un type CHOICE.
        2. Quand une valeur ContentInfo est le contenu interne d'un contenu donnée signée, donnée signée et enveloppée, ou donnée hashée, un algorithme message-digest est appliqué aux octets du contenu encodé DER du champ content. Quand une valeur ContentInfo est le contenu interne d'un contenu donnée enveloppée ou donnée signée et enveloppée, un algorithme de chiffrement de contenu est appliqué aux octets d'un encodé BER à longueur définie du champ.
        3. L'omission optionnelle du champ content rend possible la construction de signatures externes, par exemple, sans modification ou réplication du contenu avec lequel la signature s'applique. Dans le cas de signatures externe, le contenu à signer sera omis de la valeur ContentInfo encapsulée interne inclus dans le type de contenu donnée signée.

Type de contenu donnée

   Le type de contenu de donnée est conçus pour référer à des chaînes arbitraires d'octets, tel que des fichiers texte ASCII. L'interprétation est laissée à l'application, de telles chaînes n'ont pas besoin d'une structure interne.

  Data ::= OCTET STRING

Type de contenu donnée signée

   Le type de contenu donnée signée consiste du contenu d'un type et du hash du contenu pour 0 ou plusieurs signataires. Le hash chiffré pour un signataire est une signature numérique sur le contenu pour ce signataire. Tout type de contenu peut être signé par plusieurs signataires en parallèle. De plus, la syntaxe a un cas dégénéré dans lequel il n'y a pas de signataires sur le contenu. Le cas dégénéré fournis un moyen de diffuser des certificat et des listes de révocation de certificat.

   Il est prévu que l'application typique du type de contenu donnée signée représente la signature numérique d'un signataire sur le contenu du type de contenu donnée. Une autre application typique est de diffuser des certificat et des listes de révocation de certificat.

  Le processus par lequel la donnée signée est construite se fait par les étapes suivantes:

1. Pour chaque signataire, un message digest est calculé sur le contenu avec un algorithme de hashage spécifique au signataire. ( Si 2 signataires emploient le même algorithme, le hash doit alors être calculé pour seulement un d'entre eux). Si le signataire authentifie une information autre que le contenu, le hash du contenu et l'autre information sont hashé avec l'algorithme de hashage du signataire, et le résultat devient le hash.
2. Pour chaque signataire, le hash et d'autres informations associées sont chiffrées avec la clé privé du signataire.
3. Pour chaque signataire, le hash chiffré et d'autres informations spécifiques au signataire sont collectés dans une valeur SignerInfo. Les certificats et les listes de révocation de certificat pour chaque signataire, et ceux ne correspondant pas à un signataire, sont collectés dans cette étape.
4. Les algorithme de hashage pour tous les signataires et les valeur SignerInfo pour tous les signataires sont collectés ensemble avec le contenu dans une valeur SignedData.

   Un destinataire vérifie les signatures en déchiffrant le hash chiffré pour chaque signataire avec la clé publique du signataire, puis compare le hash récupéré avec un hash calculé indépendamment. La clé publique du signataire est soit contenue dans un certificat inclus dans l'information du signataire, soit est référencée par un nom de fournisseur et un numéro de série spécifique au fournisseur qui identifie de manière unique le certificat pour la clé publique.

   Cette section est divisée en 5 parties. La première décrit le type SignedData, la seconde décrit le type SignerInfo, la troisième et quatrième décrivent le hashage, et la dernière section est un sommaire de la compatibilité avec PEM.

type SignedData

Le type de contenu donnée signée devrait avec le type ASN.1:
SignedData ::= SEQUENCE {
    version Version,
    digestAlgorithms DigestAlgorithmIdentifiers,
    contentInfo ContentInfo,
    certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
    crls
        [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }
    
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
    
SignerInfos ::= SET OF SignerInfo

version Est le numéro de version de syntaxe. Devrait être à 1 pour cette version du document.
digestAlgorithms Est une collection d'identifiant d'algorithme de hashage. Il peut y avoir plusieurs élément dans la collection, incluant 0. Chaque élément identifie l'algorithme de hashage ( et ses paramètres associés ) sous lequel le contenu est hashé pour un signataire. La collection est conçue pour lister les algorithmes de hashage employés par tous les signataires, dans n'importe quel ordre, pour faciliter la vérification la vérification de signature en une passe.
contentInfo Est le contenu qui est signé. Il peut avoir n'importe quel type de contenu défini.
certificates Est le jeu de certificat étendu PKCS#6 et de certificats X.509. Il est prévu que le jeu soit suffisant pour contenir des chaînes depuis un root reconnus pour tous les signataires dans le champ signerInfos. Il peut y avoir plus de certificats que nécessaire, et il peut y avoir les certificats suffisants pour contenir les chaînes depuis 2 ou plusieurs autorité racine indépendants. Il peut également y avoir moins de certificats que nécessaire, s'il est prévu que la vérification des signatures aient un moyen alternatif.
clrs Est un jou de liste de révocation de certificats. Il est prévus que le jeu contienne des informations suffisantes pou déterminer si les certificats dans le champ certificates sont listés ou non, mais une telle correspondance n'est pas nécessaire. Il peut y avoir plus d'un liste de révocation que nécessaire, et il peut y en avoir moins que nécessaire.
signerInfos Est une collection d'information par signataire. Il peut y avoir plusieurs élément dans la collection, ou aucun.

notes

1. Le fait que le champ digestAlgorithms vient avant le champ contentInfo et que le champ signerInfos vient après rend possible le traitement d'une valeur SignedData en une seul passe.
2. Les différences entre la version 1 de SignedData et la version 0 (définis dans PKCS#7, version 1.4) sont les suivantes:

        - Les champs digestAlgorithms et signerInfos peuvent contenir 0 éléments dans la version 1, mais pas dans la version 0
        - Le champ crl est permis dans le version 1, mais pas dans la version 0.

           Excepté pour la différence dans le numéro de version, les valeurs SignedData version 0 sont acceptable comme valeurs de version 1. Un implémentation peut cependant traiter les valeurs SignedData n'importe quelle version comme si elles étaient de la version 1.

3. Dans le cas dégénéré où il n'y a pas de signataires sur le contenu, la valeur ContentInfo à signer est sans importance. Il est recommandé dans ce cas que le type de contenu de la valeur ContentInfo à signer soit une donnée, et le champ content du ContentInfo est omis.

Type SignerInfo

Les informations par signataires sont représenté dans le type SignerInfo:
SignerInfo ::= SEQUENCE {
    version Version,
    issuerAndSerialNumber IssuerAndSerialNumber,
    digestAlgorithm DigestAlgorithmIdentifier,
    authenticatedAttributes
        [0] IMPLICIT Attributes OPTIONAL,
    digestEncryptionAlgorithm
        DigestEncryptionAlgorithmIdentifier,
    encryptedDigest EncryptedDigest,
    unauthenticatedAttributes
        [1] IMPLICIT Attributes OPTIONAL }
    
EncryptedDigest ::= OCTET STRING

version Est le numéro de version de syntaxe. Devrait être à 1 pour cette version du document.
issuerAndSerialNumber Spécifie le certificat du signataire ( et donc de dn et la clé publique ) par dn de fournisseur et numéro de série spécifique au fournisseur.
digestAlgorithm Identifie l'algorithme de hashage ( et ses paramètres associés ) sous lequel le contenu et les attributs authentifiés ( si présent ) sont hashés. Il devrait être parmis ceux dans le champ digestAlgorithms de la valeur SignerInfo supérieur.
authenticatedAttributes Est un jeu d'attributs qui sont signés (ex: authentifiés) par le signataire. Le champ est optionnel, mais il doit être présent si le type de contenu de la valeur ContentInfo à signer n'est pas une donée. Si le champ est présent, il doit contenir, au minimum, 2 attributs:

        1. Un attribut de type de contenu PKCS#9 ayant comme valeur le type de contenu de la valeur ContentInfo à signer
        2. Un attribut de hash PKCS#9 ayant comme valeur le hash du contenu.

D'autres type d'attributs peut être utiles ici, tel que la date de signature, également définis dans PKCS#9.
digestEncryptionAlgorithm Identifie l''algorithme de chiffrement ( et ses paramètres associés) sous lequel le message digest et informations associées sont chiffrés avec la clé privée du signataire.
encryptedDigest Est le résultat du chiffrement du hash et des informations associées avec là clé privée du signataire.
unauthenticatedAttributes Est un jeu d'attributs qui ne sont pas signé par le signataire. Ce champ est optionnel. Les types d'attributs qui peuvent être utiles ici, tels que countersignatures, sont définis dans PKCS#9.

Notes

1. Il est recommandé dans l'intérêt de la compatibilité PEM que le champ authenticatedAttributes soit omis quand le type de contenu de la valeur ContentInfo est une donnée et qu'il n'y a pas d'autres attributs à signer.
2. La différence entre SignerInfo version 1 et version 0 est le processus de chiffrement du message-digest. Seul les processus compatibles PEM sont différents, reflétant les changements dans les méthodes de signature PEM. Il n'y a pas de différence dans les processus de chiffrement de message-digest non compatible PEM.
Il est suggéré que les implémentation PKCS génèrent seulement des valeurs SignedData version 1. Vu que la méthode de signature PEM avec la version 0 est obsolète.

Processus de hashage

   Le processus de hashage calcule un hash sur soit le contenu à signer soit le contenu avec les attributs authentifiés du signataire. Dans les 2 cas, l'entrée initial du processus de hashage est la valeur du contenu à signer. Spécifiquement, l'entrée initiale sont les octets de contenu du champ ContentInfo encodé en DER pour lequel le processus de signature est appliqué. Seul les octets des contenus encodé DER de ce champ sont hashé, ni les octets identifiant ni les octets de longueur.

   Le résultat du processus de hashage dépend de la présence ou non du champ authenticatedAttributes. Que ce champ est absent, le résultat est simplement le hash du contenu. Quand ce champ est présent, cependant, le résultat est le hash de l'encodage DER complet des valeurs d'attributs contenus dans le champ authenticatedAttributes. ( le tag IMPLICIT [0] dans le champ authenticatedAttributes ne fait pas partie des valeurs d'attributs. Le tag des valeurs d'attributs est SET OF, et l'encodé DER du tag SET OF, au lieu du tag IMPLICIT [0], doit être hashé avec les octets le longueur et de contenu des valeur d'attributs). Vu que la valeur Attributes, quand le champ est présent, doit contenir comme attribut le type de contenu et le hash du contenu, ces valeurs sont indirectement inclus dans le résultat.

   Quand le contenu à signer a le type de contenu donnée et que le champ authenticatedAttributes est absent, seul la valeur de la donnée est hashé. Cela a l'avantage que la longueur du contenu à signer n'a pas besoin d'être connu à l'avance dans le processus de chiffrement. Cette méthode est compatible avec PEM.

   Bien que les octets identifiant et les octets de longueur ne sont pas hashés, ils restent protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme de hashage vu qu'il est assumé infaisable de trouver 2 messages distincts ayant le même hash. De plus, en assumant que le type de contenu détermine de manière unique les octets identifiant, ces octets sont protégés implicitement dans une des 2 manières: sont par l'inclusion du type de contenu dans les attributs authentifiés, soit en utilisant l'alternative PEM qui implique que le type de contenu soit une donnée.

   Note: Le fait que le hash est calculé sur la partie encodée DER ne signifie pas que DES est la méthode requise pour représenter cette partie pour le transfère des données. En effet, il est prévu que certaines implémentations de ce document peut stocker des objets autre que encodés DER, mais de telles pratiques n'affectent par le calcule du hash.

Processus de chiffrement du hash

   L'entrée dans le processus de chiffrement de hash - la valeur fournie à l'algorithme de chiffrement de hash du signataire - inclus le résultat du processus de hashage et l'identifiant de l'algorithme de hashage. Le résultat du processus de chiffrement du hash est le chiffrement avec la clé privée du signataire de l'encodé DER d'une valeur de type DigestInfo:


DigestInfo ::= SEQUENCE {
    digestAlgorithm DigestAlgorithmIdentifier,
    digest Digest }
    
    Digest ::= OCTET STRING

digestAlgorithm Identifie l'algorithme de hash et les paramètres associés avec lequel le contenu et les attributs authentifié sont hashés. Il devrait être le même que le champ digestAlgorithm de la valeur SignerInfo supérieur.
digest est le résultat lu processus de hashage

Notes

1. La seule différence entre le processus de signature définie ici et les algorithme de signature définis dans PKCS#1 est que les signatures sont représentées en chaîne d'octets.
2. L'entrée du processus de chiffrement typiquement va avoir 30 octets ou moins. Si digestEncryptionAlgorithm est rsaEncryption de PKCS#1, cela signifie que la longueur du modulo RSA est au moins 328bits, ce qui est raisonnable et consistant avec les recommandations de sécurité.
3. Un identifiant d'algorithme de hashage est inclus dans la valeur DigestInfo pour limiter le dégâts résultant d'un algorithme de hashage compromis. Pour l'instant, supposons un adversaire qui est capable de trouver un hash MD2 donné. Cet adversaire pourrait ainsi forger une signature pour trouver un message avec le même hash, et présenter la signature précédente comme la signature sur le nouveau message. Cette attaque va réussir seulement si le signataire avec utilisé MD2, vu que la valeur DigestInfo contient l'algorithme. Si un signataire n'a jamais validé MD2 et utilise toujours MD5, alors le MD2 compromis n'affecte pas le signataire.
4. Il y a potentiellement une ambiguïté dû au fait que la valeur DigestInfo n'indique pas si le champ de hash contient seulement le hash du contenu ou le hash du champ authenticatedAttributes encodé DER complet. En d'autre termes, il est possible pour un adversaire de transformer une signature dans les attributs authentifiés à une qui apparaît être seulement dans le contenu en changeant le contenu à encoder DER du champ authenticatedAttributes, et ainsi supprimer le champ authenticatedAttributes. La transformation inverse est possible, mais nécessite que le contenu soit l'encodé DER d'une valeur d'attributs authentifiés, ce qui est peu probable. Cette ambiguïté n'est pas un nouveau problème, ni significatif, vu que le contexte va généralement empêcher les abus. En effet, il est également possible pour un adversaire de transformer une signature dans un certificat ou une liste de révocation de certificat à une qui apparaît être seulement dans le contenu donnée signée.

Compatibilité avec PEM

   La compatibilité avec les type de processus MIC-ONLY et MIC-CLEAR dans PEM se produisent quand le type de contenu de ContentInfo à signer est une donnée, il n'y a par d'attributs authentifiés, l'algorithme de hash est md2 ou md5, et l'algorithme de chiffrement de hassh est rsaEncryption. Sous toutes ces conditions, le hash chiffré produit ici matche celui produit dans PEM parce que:

1. La valeur d'entrée de l'algorithme de hash dans PEM est le même que dans ce document quand il n'y a pas d'attributs authentifiés, MD2 et MD5 dans PEM sont les même que md2 et md5.
2. La valeur chiffrée avec la clé privée du signataire dans PEM est la même que dans ce document quand il n'y a pas d'attributs authentifié. RSA dans PEM est le même que rsaEncryption.

   Les autres parties du type de contenu donnée signée ( certificates, CRLs, algorithm identifiers, etc.) sont facilement traduisible depuis et vers leur composant PEM correspondant.

Type de contenu donnée enveloppée

   Le type de contenu donnée enveloppée consiste d'un contenu chiffré de n'importe quel type et de clé de chiffrement de contenu chiffrés pour un ou plusieurs conteneurs. La combinaison du contenu chiffré et de la clé de chiffrement de contenu chiffrée pour un conteneur est une enveloppe numérique pour ce conteneur. Tout type de contenu peut être enveloppé pour autant de type de conteneurs en parallèle.

   Il est prévu que l'application typique du type de contenu donnée enveloppée est de représenter une ou plusieurs enveloppe numérique de conteneurs dans le contenu de donnée, donnée hashée, ou donnée signée. Le processus par lequel une donnée enveloppée est construite est faites des étapes suivantes:

1. Une clé de chiffrement de contenu pour un algorithme de chiffrement de contenu particulier est généré aléatoirement.
2. Pour chaque conteneur, la clé de chiffrement de contenu est chiffrée avec la clé publique du conteneur
3. Pour chaque conteneur, la clé de chiffrement chiffrée et d'autres informations spécifique au conteneur sont collectées dans une valeur RecipientInfo
4. Le contenu est chiffré avec la clé de chiffrement de contenu
5. Les valeurs RecipientInfo pour tous les conteneurs sont collectés ensemble avec le contenu chiffré dans une valeur EnvelopedData

   Un destinataire ouvre l'enveloppe en déchiffrant celle des clés de chiffrement de contenu chiffré avec la clé privée du destinataire et déchiffre le contenu chiffré avec la clé de chiffrement de contenu récupérée. La clé privée du destinataire est référencée par un dn de fournisseur et un numéro de série spécifique qui identifie de manière unique le certificat pour la clé publique correspondance.

   Cette section est divisée en 4 parties, la première décris le type EnvelopedData, la deuxième décris le type RecipientInfo, et la troisième et quatrième décrivent les processus de chiffrement de contenu et de chiffrement de clé. Ce type de contenu n'est pas compatible avec PEM, vu que PEM implique toujours des signatures numériques, jamais des enveloppes seules.

Type EnvelopedData

Le type de contenu donnée enveloppée devrait avoir le type ASN.1:
EnvelopedData ::= SEQUENCE {
    version Version,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo }
    
RecipientInfos ::= SET OF RecipientInfo
    
EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm
        ContentEncryptionAlgorithmIdentifier,
    encryptedContent
        [0] IMPLICIT EncryptedContent OPTIONAL }
    
EncryptedContent ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
recipientInfos Est une collection d'information par destinataires. Il doit y avoir au moins un élément dans la collection
encryptedContentInfo Est l'information de contenu chiffré
contentType Indique le type de contenu
contentEncryptionAlgorithm Identifie l'algorithme de chiffrement de contenu et ses paramètres associés sous lequel le contenu est chiffré. Le processus de chiffrement de contenu est décris plus bas. Cet algorithme est le même pour tous les destinataires.
encryptedContent Est le résultat du chiffrement du contenu. Ce champ est optionnel, et si non présent, sa valeur doit être fournie par d'autres moyens.

   Note: Le fait que le champ recipientInfos vient avant le champ encryptedContentInfo rend possible le traitement d'une valeur EnvelopedData en une seule passe.

Type RecipientInfo

Les informations par destinataire sont représentés dans le type RecipientInfo:
RecipientInfo ::= SEQUENCE {
    version Version,
    issuerAndSerialNumber IssuerAndSerialNumber,
    keyEncryptionAlgorithm
    
        KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }
    
EncryptedKey ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
issuerAndSerialNumber Spécifie le certificat du destinataire ( et donc sont dn et sa clé publique ) par dn de fournisseur et numéro de série.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé ( et ses paramètres associés ) avec lequel la clé de chiffrement de contenu est chiffrée avec la clé publique du destinataire.
encryptedKey Est le résultat du chiffrement de la clé de chiffrement de contenu avec la clé publique du destinataire.

Processus de chiffrement de contenu

   L'entrée pour le processus de chiffrement de contenu est la valeur du contenu à envelopper. Spécifiquement, l'entrée sont les octets du contenu de longueur définie encodée BER du champ content de la valeur ContentInfo pour lequel le processus d'enveloppe est appliqué. Seul les octets de contenu de l'encodé BER sont chiffrés, et non les octets identifiant ou les octets de longueur; ces octets ne sont pas représentés du tout.

   Quand le contenu à envelopper à un contenu de type donnée, seule la valeur de la donnée ( par ex. le contenu d'un fichier ) est chiffré. Cela a l'avantage que la longueur du contenu à chiffrer n'a pas besoin d'être connus à l'avance. Cette méthode est compatible avec PEM.

   Les octets identifiant et les octets de longueur ne sont pas chiffrés. Les octets de longueur peuvent être protégés implicitement par le processus de chiffrement, dépendant de l'algorithme de chiffrement. Les octets identifiant ne sont pas protégés du tout, bien qu'ils puissent être récupérés depuis le type de contenu, assumant que le type de contenu détermine de manière unique les octets identifiant. La protection explicite de l'identifiant et de la longueur nécessite que le type donnée signée et enveloppée soit employé, ou que les type de contenu donnée hashé, donnée enveloppée soient appliqués successivement.

Notes

1. La raison qu'un encodé BER de longueur définie est requise est que le bit indiquant si la longueur est définie ou indéfinie n'est pas enregistrée dans le type de contenu donnée enveloppée. L'encodage de longueur définie est plus appropriée pour des types simple tels que les chaîne d'octets.
2. Certains algorithmes de chiffrement de contenu assument que la longueur d'entrée est un multiple de k octets, où k › 1, et laissent l'application définir une méthode pour manipuler l'entrée dont la longueur ne serait pas un multiple de k octets. Pour de tels algorithmes, la méthode devrait être de compléter l'entrée à la fin avec k - (l mod k) octets, tous ayant la valeur k - (l mod k), où l est la longueur de l'entrée. En d'autre termes, l'entrée est remplie à la fin avec une des chaînes suivante:


01 -- if l mod k = k-1
02 02 -- if l mod k = k-2
    
    k k ... k k -- if l mod k = 0

           Le padding peut être supprimé de manière non-ambigu vu que toute l'entrée est remplie et qu'aucune chaîne de padding n'est un suffixe d'un autre. Cette méthode est définie si et seulement si k ‹ 256; les méthodes pour k supérieur sont un problème.

Processus de chiffrement de clé

   L'entrée du processus de chiffrement de clé - la valeur fournie à l'algorithme de chiffrement de clé du destinataire - est simplement la valeur de la clé de chiffrement de contenu.

Type de contenu donnée signée et enveloppée

   Cette section définis le type de contenu donnée signée et enveloppée. Pour faire court, le principal de cette section sont exprimée en terme des 2 sections précédentes.

   Le type de contenu donnée signée et enveloppée consiste d'un contenu chiffré de n'importe quel type, des clés de chiffrement de contenu chiffré pour un ou plusieurs destinataires, et du hash doublement chiffrés pour un ou plusieurs signataires. Le double chiffrement consiste d'un chiffrement avec la clé privée du signataire suivi par un chiffrement avec la clé de chiffrement de contenu.

   La combinaison du contenu chiffré et de la clé de chiffrement de contenu chiffré pour un destinataire est une enveloppe numérique pour ce destinataire. Le hash chiffré récupéré pour un signataire est une signature numérique sur le contenu récupéré pour ce signataire. Tout tupe de contenu peut être enveloppé pour des destinataire et signé par des signataire en parallèle.

   Il est prévu que l'application typique d'un type de contenu donnée enveloppée et signée est de représenter la signature numérique d'un signataire et une ou plusieurs enveloppe numérique d'un ou plusieurs destinataires dans le contenu du type de contenu donnée. Le processus pour signer et envelopper est construit selon les étapes suivantes:

1. Une clé de chiffrement pour un algorithme de chiffrement de contenu particulier est généré aléatoirement.
2. Pour chaque destinataire, la clé de chiffrement de contenu est chiffrée avec la clé publique du destinataire
3. Pour chaque destinataire, la clé de chiffrement de contenu chiffrée et d'autres informations spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Pour chaque signataire, un hash est calculé sur le contenu avec un algorithme de hash spécifique au signataire. ( si 2 signataires emploient le même algorithme de hash, le hash doit être calculé une seule fois ).
5. Pour chaque signataire, le hash est les informations associées sont chiffrées avec la clé privée du signataire, et le résultat est chiffré avec la clé de chiffrement de contenu. ( le deuxième chiffrement peut nécessiter que le résultat du premier chiffrement soit padded à un multiple d'un taille de block)
6. Pour chaque signataire, le hash et les informations spécifique doublement chiffrés sont collecté dans une valeur SignerInfo.
7. Le contenu est chiffré avec la clé de chiffrement de contenu.
8. Les algorithmes de hash pour tous les signataires, les valeurs SignerInfo pour tous les signataires et les valeurs RecipientInfo pour tous les destinataires sont collecté ensemble avec le contenu chiffré dans une valeur SignedAndEnvelopedData.

   Un destinataire ouvre les enveloppes et vérifie les signature en 2 étapes. D'abord, celle contenant les clé de chiffrement de contenu est déchiffrée avec la clé privée du destinataire, et le contenu chiffré est déchiffré avec la clé de chiffrement de contenu récupéré. Ensuite, le hash doublement chiffré pour chaque signataire est déchiffré avec la clé de chiffrement de contenu récupérée, le résultat est déchiffré avec la clé publique du signataire et le hash récupéré est comparé avec un hash calculé indépendemment.

   Cette section est divisée en 3 parties. La première décris le type SignedAndEnvelopedData et la deuxième décris le processus de chiffrement. Les autres types et processus sont les même que dans les sections précédente. La troisième partie est un sommaire de compatibilité avec PEM.

   Note: Le type de contenu donnée signée et enveloppée fournis un amélioration cryptographique similaire à celui résultant d'un combinaison séquentielle des type de contenu donnée signée et donnée enveloppée. Cependant, vu que le type de contenu donnée signée et enveloppée n'a pas d'attributs authentifié ou non-authentifié, ni ne fournis d'enveloppe pour les information de signataire autre que la signature, la combinaison séquentielle est généralement préférable au contenu SignedAndEnvelopedData. Excepté quand la compatibilité avec le type de processus ENCRYPTED dans PEM est recherché.

Type SignedAndEnvelopedData

Le type de contenu donnée signée et enveloppée devrait avoir le type ASN.1:
SignedAndEnvelopedData ::= SEQUENCE {
    version Version,
    recipientInfos RecipientInfos,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encryptedContentInfo EncryptedContentInfo,
    certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
            OPTIONAL,
    crls
        [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
recipientInfos Est une collection d'information par destinataires. Il doit y avoir au moins un élément dans la collection
digestAlgorithms Est une collection d'identifiants d'algorithme de hashage.
encryptedContentInfo Est le contenu chiffré. Il peut avoir tout type de contenu
certificates Est un jeu de certificats PKCS#6 et de certificats X.509
crls Est un jeu de listes de révocation de certificat
signerInfos Est une collection d'information par signataire. Il doit y avoir au moins un élément dans la collection.

Notes

1. Le fait que les champs recipientInfos et digestAlgorithms soient avant les champs contentInfo et signerInfos rend possible de traiter un valeur SignedAndEnvelopedData en une passe.
2. La différence entre les version 0 et 1 de SignedAndEnvelopedData est que le champ crls est permis dans la version 1, mais pas dans la version 0.

Processus de chiffrement de hash

   L'entrée du processus de chiffrement est la même que pour processus de chiffrement de hash, mais le processus lui-même est différent. Spécifiquement, le processus à 2 étapes. D'abord, l'entrée est fournie à l'algorithme de chiffrement de hash du signataire. Ensuite, le résultat est chiffré avec la clé de chiffrement de contenu. Il n'y a pas d'encodage DER entre les 2 étapes; la valeur de sortie de la première étape est entrée directement dans la seconde étape. Ce processus est compatible avec le processus ENCRYPTED dans PEM.

   Note: Le but de la seconde étape est d'empêcher un adversaire de récupérer le hash du contenu. Sinon, un adversaire sera capable de déterminer qui d'une liste de contenus candidats est le contenu actuel en comparant leur hash.

Compatibilité avec PEM

   La compatibilité avec le type de processus ENCRYPTED de PEM se produit quand le type de contenu de la valeur ContentInfo à signer et envelopper est une donnée, l'algorithme de hash est md2 ou md5, l'algorithme de chiffrement est DES en mode CBC, l'algorithme de chiffrement de hash est rsaEncryption, et l'algorithme de chiffrement de clé est rsaEncryption. Sous toutes ces conditions, le hash doublement chiffré et la clé de chiffrement de contenu chiffré matchent celui produit dans PEM parce que les raisons données plus haut sont similaires aussi bien que les suivantes:

1. La valeur d'entrée de l'algorithme de chiffrement de contenu dans PEM est la même que dans ce document. DES en mode CBC est le même que desCBC.
2. La valeur d'entrée de l'algorithme de chiffrement de clé dans PEM est la même que dans ce document. RSA dans PEM est le même que rsaEncryption.
3. Le processus de double chiffrement appliqué au hash dans ce document et dans PEM sont les même

   Les autres parties du type de contenu donnée signée et enveloppée ( certificates, CRLs, algorithm identifiers, etc. ) sont facilement transposables depuis et vers leur composant PEM.

Type de contenu donnée hashé

   Le type de contenu donnée hashée consiste du contenu de n'importe quel type et un hash du contenu. Il est prévu que l'application typique du type de contenu donnée hashée est d'ajouter l'intégrité du contenu d'entrée au type de contenu donnée enveloppée. Le processus par lequel une donnée hashée est construite est constituée des étapes suivantes:

1. Un hash est calculé sur le contenu avec un algorithme de hashage
2. L'algorithme de hashage est le hash sont collecté ensemble avec le contenu dans une valeur DigestedData.

   Un destinataire vérifie le hash en comparant ce hash avec un hash calculé indépendamment.

Le type de contenu donnée hashée devrait avoir le type ASN.1:
DigestedData ::= SEQUENCE {
    version Version,
    digestAlgorithm DigestAlgorithmIdentifier,
    contentInfo ContentInfo,
    digest Digest }
    
Digest ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
digestAlgorithm Identifie l'algorithme de hashage et ses paramètres associés avec lequel le contenu est hashé.
contentInfo Est le contenu qui est hashé
digest Est le résulta du processus de hashage

   Note: Le fait que le champ digestAlgorithm vient avant le champ contentInfo est le champ digest vient aprés rend possible le traitement d'une valeur DigestedData en une seule passe.

Type de contenu donnée chiffrée

   Le type de contenu donnée chiffrée consiste d'un contenu chiffré de n'importe quel type. À la différence du type de contenu donnée enveloppée, le type de contenu donnée chiffrée n'a ni destinataire ni clé de chiffrement de contenu. Les clé sont supposés être gérées par d'autres moyens.

   Il est prévu que l'application typique du type de contenu donnée chiffrée est de chiffrer le contenu du type de contenu donnée pour stochage local, où la clé de chiffrement peut être un mot de passe.

Le type de contenu donnée chiffrée devrait avoir le type ASN.1:
EncryptedData ::= SEQUENCE {
    version Version,
    encryptedContentInfo EncryptedContentInfo }

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
encryptedContentInfo contient les information sur le contenu chiffré

Object Identifiers

   Ce document définis 7 identifiant d'objet: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, et encryptedData.

L'identifiant d'objet pkcs-7 identifie ce document
pkcs-7 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 7 }

Les OID data, signedData, envelopedData, signedAndEnvelopedData, digestedData, et encryptedData, identifient, respectivement, les type de contenu donnée, donnée signée, donnée enveloppée, donnée signée et enveloppée, donnée hashée et donnée chiffrée.
data OBJECT IDENTIFIER ::= { pkcs-7 1 }
    signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
    envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
    signedAndEnvelopedData OBJECT IDENTIFIER ::= { pkcs-7 4 }
    digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
    encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }

   Ces OID sont prévus pour être utilisé dans le champ contentType d'une valeur de type ContentInfo.
^
15 avril 2013

htmlpdflatexmanmd




OpenSSL - x509v3_config

OpenSSL - x509v3_config

Format de configuration des extensions de certificat X509 v3

   Le format est le suivant:

  extension_name=[critical,] extension_options

  Si critical est présent, l’extension est critique. Il y’a 4 types d’extension: chaînes, multi-valué, raw, et arbitraire.

exemple chaîne:
nsComment="This is a Comment"
exemple multi-valué:
basicConstraints=critical,CA:true,pathlen:1
variante d’un multivalué:
basicConstraints=critical,@bs_section
[bs_section]
CA=true
pathlen=1

Extensions standard

Contraintes de base Extension multi-valué qui indique si un certificat est un certificat de CA


basicConstraints=CA:TRUE
basicConstraints=CA:FALSE
basicConstraints=critical,CA:TRUE, pathlen:0

   Un certificat de CA doit avoir basicContraints à TRUE et optionnellement un pathlen qui indique le nombre maximum de CA qui peut apparaitre sous celle-ci dans une chaîne. A 0, peut seulement signer des certificats finaux.

Utilisation de clé Extension multi-valué consistant d’une liste de noms d’utilisation de clé permis Les noms supportés sont : digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly et decipherOnly.

exemple:
keyUsage=digitalSignature, nonRepudiation
keyUsage=critical, keyCertSign

Utilisation de clé étendue Consiste en une liste d’utilisation indiquant l’utilisation de la clé publique. Peut être un nom court, ou un OID:

Value Meaning
----- -------
serverAuth SSL/TLS Web Server Authentication.
clientAuth SSL/TLS Web Client Authentication.
codeSigning Code signing.
emailProtection E-mail Protection (S/MIME).
timeStamping Trusted Timestamping
msCodeInd Microsoft Individual Code Signing (authenticode)
msCodeCom Microsoft Commercial Code Signing (authenticode)
msCTLSign Microsoft Trust List Signing
msSGC Microsoft Server Gated Crypto
msEFS Microsoft Encrypted File System
nsSGC Netscape Server Gated Crypto

exemple:
extendedKeyUsage=critical,codeSigning,1.2.3.4
extendedKeyUsage=nsSGC,msSGC

Identifiant de clé du sujet Extention de type chaîne qui prend 2 valeurs : hash qui suit la rfc3280 ou une chaîne hexa donnant la valeur de l’extension à inclure

exemple:
subjectKeyIdentifier=hash

Identifiant de clé d’autorité Permet 2 options, keyid et issuer et peuvent prendre optionnellement la valeur always

           Avec keyid, tente de copier le subject key identifier depuis le certificat parent. Avec always, une erreur est retourné si l’option échoue.

  avec issuer, copie l’issuer et le numéro de série de l’issuer

exemple:
authorityKeyIdentifier=keyid,issuer

Subject Alternative Name L’extention subjectAltName permet d’inclure divers valeurs : email, URI, DNS, RID (ID:Object Identitifer), IP, dirName (un DN) et otherName.

        email contient une options spécial ’copy’ qui inclus automatiquement les emails contenus dans le sujet dans l’extension
        dirName devrait pointer vers une section contenant un DN à utiliser.
        otherName peut inclure des données arbitraires associées avec un OID

exemple:
subjectAltName=email:copy,email:my@other.address,URI :http://my.url.here/
subjectAltName=IP:192.168.7.1
subjectAltName=IP:13::17
subjectAltName=email:my@other.address,RID:1.2.3.4
subjectAltName=otherName:1.2.3.4;UTF8:some other identifier
    
subjectAltName=dirName:dir_sect
    
[dir_sect]
C=UK
O=My Organization
OU=My Unit
CN=My Name

Issuer Alternative Name Supporte toutes les options litéral de subjectAltName. Il ne supporte pas l’option mail:copy. Il supporte issuer:copy qui copie tous les subjectAltName du certificat de l’issuer

exemple:
issuerAltName = issuer:copy

Authority Info Access Extension d’accès aux informations de l’authorité donne des détails sur la mannière d’accéder à certaines informations lié à la CA. la syntaxe est accessOID;location, où location a la même syntaxe qu’un subjectAltName (excepté email:copy) accessOID peut être un OID valide mais seul certaines valeurs ont une signification, par exemple OCSP et calssuers

exemple:
authorityInfoAccess = OCSP;URI:http://ocsp.my.host/
authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html

Point de distribution de CRL Extension multi-valuée qui peut être un nom:valeur utilisant la même forme qu’un subjectAltName

   Dans le cas d’une simple option, la section indiquée contient les valeurs pour chaque champs. dans cette section:

  Si le nom est fullname la valeur devrait contenir le nom complet du point de distribution dans le même format que subjectAltName.

  Si le nom est relativename, la valeur devrait contenir un nom de section dont le contenu représente un DN

  Le nom CRLIssuer devrait contenir une valeur pour ce champ au format subjectAltName

  Si le nom est reasons, la valeur devrait consister en un champ contenant les raisons: keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, AACompromise.

exemple:
crlDistributionPoints=URI:http://myhost.com/myca.crl
crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth...
crlDistributionPoints=crldistpoint1_section
    
[crldistpoint1_section]
fullname=URI:http://myhost.com/myca.crl
CRLissuer=dirName:issuer_sect
reasons=keyCompromise, CACompromise
    
[issuer_sect]
C=UK
O=Organisation
CN=Some Name

Issuing Distribution Point Devrait seulement apparaître dans les CRL. Extension multi-valuée dont la syntaxe est similaire à la section pointé par l’extension de point de distribution de CRL avec quelques différences

   Les noms reasons et CRLIssuer ne sont pas reconnus

  Le nom onlysomereasons est accepté. La valeur est au même format que le champ reasons des crlDistributionPoints. Les noms onlyuser, onlyCA, onlyAA et indirectCRL sont aussi acceptés et sont des booléen.

exemple:
issuingDistributionPoint=critical, @idp_section
[idp_section]
fullname=URI:http://myhost.com/myca.crl
indirectCRL=TRUE
onlysomereasons=keyCompromise,CACompromise
[issuer_sect]
C=UK
O=Organisation
CN=Some Name

Certificate Policies Extension raw

Si on suit la recommandation PKIX, en utilisant des OID:
certificatePolicies= 1.2.4.5, 1.1.3.4

   Si on inclus des qualifiers, les OID de stratégie et les qualifieurs doivent être spécifiés dans une section séparée (sous la forme @section) La section référée doit inclure l’OID de stratégie en utilisant policyIdentifier. les qualifiers cPSuri peuvent être inclus avec cette syntaxe:


CPS.nnn=value

les qualifiers userNotice peuvent être définis avec:
userNotice.nnn=@notice

   Cette section peut inclure explicitText, organization et noticeNumbers.

exemple:
certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect
[polsect]
policyIdentifier = 1.3.5.8
CPS.1="http://my.host.name/";
CPS.2="http://my.your.name/";
userNotice.1=@notice
[notice]
explicitText="Explicit Text Here"
organization="Organisation Name"
noticeNumbers=1,2,3,4

   Si userNotice est utilisé avec IE5, il faut l’option ia5org avant pour modifier l’encodage. Cette options modifie le type de champs organization dans la rfc2459, il peut seulement être de type DisplayText. Dans la rfc3280 IA5String est aussi permis.

Policy Constraints Extension multivaluée consistant de nom requireExplicitPolicy ou inhibitPolicyMapping et une valeur entière non négative Au moins un composant doit être présent.

exemple:
policyConstraints = requireExplicitPolicy:3

Inhibit Any Policy Extension chaîne consistant de valeurs non négatives

exemple:
inhibitAnyPolicy = 2

Name Constraints Extension multi-valuée. Le nom devrait commencer avec le mot permitted ou excluded, suivi par un ';' le reste suivi la syntaxe subjectAltName excepté email:copy et IP

exemple:
nameConstraints=permitted;IP:192.168.0.0/255.255.0.0
nameConstraints=permitted;email:.somedomain.com
nameConstraints=excluded;email:.com
issuingDistributionPoint = idp_section

OCSP No Check Extension chaîne, mais sa valeur est ignored

exemple:
noCheck = ignored

Extensions arbitraires

   Si une extension n’est pas supportée par OpenSSL, elle doit être encodé en utilisant le format arbitraire. Il est possible d’utiliser ce format pour les extensions connues.

  Il y’a 2 manières d’écrire des extensions de type arbitraire:

Utiliser le mot ASN1 suivi de l’extension en utilisant la même syntaxe que ASN1_generate_nconf(3):
1.2.3.4=critical,ASN1:UTF8String:Some random data
1.2.3.4=ASN1:SEQUENCE:seq_sect
[seq_sect]
field1 = UTF8:field1
field2 = UTF8:field2

Utiliser le mot DER pour inclure les donnée brutes:
1.2.3.4=critical,DER:01:02:03:04
1.2.3.4=DER:01020304

La valeur après DER est un dump DER d’une extension. Une extension peut être placée dans cette forme pour remplacer le mode par défaut :
basicConstraints=critical,DER:00:01:02:03

Notes

Si une extension est multi-valué et un champs doit contenir un ',', la forme longue doit être utilisée sinon le séparateur sera mal interprété:
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar


va produire une erreur, mais ceci est valide:
subjectAltName=@subject_alt_section
[subject_alt_section]
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar

Due à la librairie conf, le même nom de champ ne peut se trouver qu’une seul fois. Celà signifie que:
subjectAltName=@alt_section
[alt_section]
email=steve@here
email=steve@there

Va seulement reconnaître la dernière valeur, alors que ceci reconnaîtra toutes les valeurs:
[alt_section]
email.1=steve@here
email.2=steve@there

^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - x509

OpenSSL - x509

Utilitaire de manipulation de certificat

OPTIONS

-inform DER|PEM|NET Format du fichier x509 en entrée
-outform DER|PEM|NET Format du fichier en sortie
-in filename Fichier en entrée
-out filename Fichier de sortie
-md2|-md5|-sha1|-mdc2 Message digest à utiliser
-engine id x509 va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Options d'affichage

-text Affiche le certificat au format texte.
-certopt option Personnalise la sortie utilisée avec -text liste d’options à afficher. Peut être spécifié plusieurs fois
-noout N’affiche pas la version encodée de la requête
-pubkey Affiche le block SubjectPublicKeyInfo du certificat au format PEM
-modulus Affiche la valeur du modulo de la clé publique contenue dans le certificat
-serial Affiche le numéro de série du certificat
-subject_hash Affiche le hash du nom du certificat
-issuer_hash Affiche le hash de l’issuer du certificat
-hash idem à -subject_hash
-subject_hash_old Affiche le hash du nom du certificat en utilisant l’ancien algorithme pré v1
-issuer_hash_old Affiche le hash de l’issuer du certificat en utilisant l’ancien algorithme pré v1
-subject Affiche le sujet
-issuer Affiche le fournisseur
-nameopt option Détermine comment le sujet et l’issuer sont affichés (voir options de nom)
-email Affiche les adresses email
-ocsp_uri Affiche les adresses de répondeur OCSP
-startdate Affiche la date de début de validité du certificat
-enddate Affiche la date de fin de validité du certificat
-dates Affiche la date de début et d’expiration du certificat
-fingerprint Affiche le digest de la version encodé DER du certificat
-C Affiche le certificat sous la forme d’un source C

Paramètres de confiance

-trustout Sort un certifcat de confiance.
-setalias arg Définis l’alias du certificat
-alias Affiche l’alias du certificat, s’il existe
-clrtrust Efface toutes les utilisations de confiance et permises du certificat
-clrreject Efface toutes les utilisations rejetée ou interdites du certificat
-addtrust arg Ajoute une utilisation de certifiaction de confiance. (clientAuth, serverAuth, emailProtection)
-addreject arg Ajoute une utilisation interdite. Accèpte lesmême valeurs que -addtrust
-purpose Effectue des tests sur les extensions du certificat et affiche le résultat (voir les extensions de certificat)

Options de signature

-signkey filename Signe le fichier en entrée avec la clé privée spécifiée. Si l’entrée est une requête de certificat, génère un certificat auto-signé
-clrext Supprime des extensions d’un certificat
-keyform PEM|DER Format de la clé privée
-days arg Spécifie le nombre de jours pour créer une validité pour le certificat
-x509toreq Convertit un certificat en une requête
-req L’entrée est une requete au lieu d’un certificat
-set_serial n Numéro de série à utiliser en décimal ou hexa
-CA filename Certificat de la CA à utiliser pour signer le certificat
-CAkey filename Clé privée de la CA
-CAserial filename Définis le fichier de numéro de série à utiliser
-CAcreateserial Créé le fichier de numéro de série s’il n’existe pas
-extfile filename Fichier contenant les extensions à utiliser
-extensions section Section où se trouvent les extensions à ajouter

Options de nommage

compat Utiliser l’ancien formats, équivalent à ne spécifier aucune option de nommage
RFC2253 Affiche les noms compatibles avec la rfc2253 equivalent à spécifier: esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_unknown, dump_der, sep_comma_plus, dn_rev et sname
oneline Format oneline, plus lisible que rfc2253. equivalent à spécifier: esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_der, use_quote, sep_comma_plus_space, space_eq et sname
multiline Format multiligne. équivalent à spécifier: esc_ctrl, esc_msb, sep_multiline, space_eq, lname et align.
esc_2253 Échappe les caractères spéciaux (,+"‹› ;#) requis par la rfc2253
esc_ctrl Échappe les caractères de contrôle d’échappement
esc_msb Echappe les caractères avec le MSB mis, c’est à dire les valeurs ASCII › 127
use_quote Échappe certains caractères en les plaçant entre "" au lieu de \
utf8 Convertit toutes les chaînes en UTF8
no_type Ne tente pas d’interpréter les caractères multi-octets
show_type Affiche le type de chaîne caractère ASN1
dump_der Dump en encodé DER les champs qui doivent être dumpé en hexa
dump_nostr Dump les types de chaînes non caractères
dump_all Dump tous les champs
dump_unknown Dump les champs dont l’OID n’est pas reconnus par openssl
sep_comma_plus
sep_comma_plus_space
sep_semi_plus_space
sep_multiline Déterminent les séparateurs de champs
dn_rev Renverse les champs d’un DN
nofname
sname
lname
oid Altère la manière dont le nom des champs est affiché
align Aligne les valeurs de champs
space_eq Met des espace autour du caractère ’=’

Options de texte

compatible Utiliser l’ancien formats, équivalent à ne spécifier aucune option de sortie
no_header N’affiche pas les en-têtes
no_version N’affiche pas le numéro de version
no_serial N’affiche pas le numéro de série
no_signame N’affiche pas l’algorithme de signature utilisé
no_validity N’affiche pas la validité
no_subject N’affiche pas le sujet
no_issuer N’affiche pas l’issuer
no_pubkey N’affiche pas la clé publique
no_sigdump Ne dump par la signature du certificat
no_aux N’affiche pas les informations de trust du certificat
no_extensions N’affiche pas les extensions X509v3
ext_default Tente d’afficher les extensions de certificat non supportés
ext_error Affiche une erreur pour les extensions de certificat non supportés
ext_parse Parse en ASN1 les extensions non supportés
ext_dump Dumps en hexa les extensions non supportés
ca_default Valeur utilisé par l’utilitaire ca. equivalent à o_issuer, no_pubkey, no_header, no_version, no_sigdump et no_signame

Exemples

Afficher le contenu d’un certificat:
openssl x509 -in cert.pem -noout -text
Afficher le numérode série d’un certificat:
openssl x509 -in cert.pem -noout -serial
Affiche le sujet d’un certificat:
openssl x509 -in cert.pem -noout -subject
Afficher le sujet du certificat sous la forme RFC2253:
openssl x509 -in cert.pem -noout -subject -nameopt RFC2253
Afficher le sujet du certificat en une ligne et en utf8:
openssl x509 -in cert.pem -noout -subject -nameopt oneline,-esc_msb
Affiche l’empreinte MD5 du certificat:
openssl x509 -in cert.pem -noout -fingerprint
Affiche l’empreinte SHA1 du certificat:
openssl x509 -sha1 -in cert.pem -noout -fingerprint
Convertir un certificat PEM en DER:
openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
Convertit un certificat en requête:
openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem
Convertit une requête en un certificat auto-signé utilisant des extensions:
openssl x509 -req -in careq.pem -extfile openssl.cnf -extensions v3_ca -signkey key.pem -out cacert.pem
Signer une requête en utilisant le certificat d’un CA et en ajoutant des extensions utilisateur:
openssl x509 -req -in req.pem -extfile openssl.cnf -extensions v3_usr -CA cacert.pem -CAkey key.pem -CAcreateserial
Définis un certificat à truster pour un client SSL et changer son alias en "Steve’s Class 1 CA":
openssl x509 -in cert.pem -addtrust clientAuth -setalias "Steve’s Class 1 CA" -out trust.pem

Notes

Le format PEM utilise les élements suivants:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

ou:
-----BEGIN X509 CERTIFICATE-----
-----END X509 CERTIFICATE-----

Les certificats trustés auronts les lignes:
-----BEGIN TRUSTED CERTIFICATE-----
-----END TRUSTED CERTIFICATE-----

Extensions de certificat

   l’option -purpose vérifie les extensions de certificat et détermine l’utilisation du certificat.

basicContraints (Bool)Cette extension est utilisé pour déterminer si le certificat peut être utilisé comme CA.
keyUsage Cette extension contient des restrictions sur l’utilisation du certificat. Un certificat CA doit avoir le but keyCertSign mis si cette extension est présente.

Description de chaque tests

SSL Client L’extension d’utilisation de clé doit être absent ou inclure l’OID web client authentication. keyUsage doit être absent ou avoir le bit digitalSignature mis.
SSL Client CA L’extension d’utilisation de clé doit être absent ou inclure l’OID web client authentication.
SSL Server L’extension d’utilisation de clé doit être absent ou inclure l’OID web server authentication et/ou un OID SGC. keyUsage doit être absent ou avoir le bit digitalSignature et/ou keyEncipherment mis.
SSL Server CA L’extension d’utilisation de clé doit être absent ou inclure l’OID web server authentication et/ou un OID SGC.
Netscape SSL Server Pour que les clients Netscape se connectent à un serveur SSL il doitavoir le bit keyEncipherment mis si keyUsage est présent
Common S/MIME Client Tests L’extension d’utilisation de clé doit être absent ou inclure l’OID email protection.
S/MIME Signing idem, et test le bit digitalSignature sur keyUsage est présent
S/MIME Encryption idem et test le bit keyEncipherment sur keyUsage est présent
S/MIME CA L’extension d’utilisation de clé doit être absent ou inclure l’OID email protection.
CRL Signing KeyUsage doit être absent ou avoir le bit CRL Signing mis.
CRL Signing CA Test normal CA, excepté que l’extention basicContraints ne doit pas être présent
^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - version

OpenSSL - version

Affiche les informations de version d’openssl

OPTIONS

-a Toutes les informations
-v Version courante d’openssl
-b La date de buid de la version courante
-o Information optionnelles
-c Flags de compilation
-p Paramètre de plateforme
-d Paramètre OPENSSLDIR
^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - verify

OpenSSL - verify

Vérifier les chaînes de certificat

OPTIONS

-CApath directory Répertoire des certificats de confiance
-CAfile file Fichier de certificats de confiance
-untrusted file Fichiers de certificats non trustés
-purpose purpose Utilisation du certificat
-verbose mode verbeux
-issuer_checks Affiche des info liés à la recherche du certifieurs.
-policy arg Active le traitement de stratégie et ajoute ’arg’ au user-initial-policy-set (RFC5280)
-policy_check Active le traitement de stratégie de certificat
-explicit_policy définis require-explicite-policy (RFC5280)
-inhibit_any définis inhibit-any-policy (see RFC5280)
-inhibit_map définis inhibit-policy-mapping (see RFC5280)
-policy_print Affiche des info sur le traitement des tratégies
-crl_check Vérifie la crl
-crl_check_all Vérifie la validité de toute la chaîne de certificat
-ignore_critical Ignore les extension critique non gérées
-x509_strict mode strict X.509 compliance
-extended_crl Active les fonctionnalités étendues de CRL
-use_deltas Active le support des CRL delta
-check_ss_sig Vérifie la signature du root CA
indique la dernière option, les arguments suivants sont des certificats
certificates Un ou plusieurs certificats à vérifier

Opérations de vérification

   verify utilise les même fonctions que la vérification SSL et S/MIME. La différence entre verify et les opérations de vérification est que verify peut passer les erreurs et de continuer les opérations de vérifications.

Diagnostique

Quand une opération échoue, un message d’erreur est affiché du type:
server.pem: /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Test CA (1024 bit)
error 24 at 1 depth lookup:invalid CA certificate

La première ligne contient le nom du certificat qui a été vérifié, suivi du sujet.
La seconde ligne contient le numéro d’erreur est une courte description de l’erreur


0 X509_V_OK : ok
2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT : unable to get issuer certificate
3 X509_V_ERR_UNABLE_TO_GET_CRL : unable to get certificate CRL
4 X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE : unable to decrypt certificate’s signature
5 X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE : unable to decrypt CRL’s signature
6 X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY : unable to decode issuer public key
7 X509_V_ERR_CERT_SIGNATURE_FAILURE : certificate signature failure
8 X509_V_ERR_CRL_SIGNATURE_FAILURE : CRL signature failure
9 X509_V_ERR_CERT_NOT_YET_VALID : certificate is not yet valid
10 X509_V_ERR_CERT_HAS_EXPIRED : certificate has expired
11 X509_V_ERR_CRL_NOT_YET_VALID : CRL is not yet valid
12 X509_V_ERR_CRL_HAS_EXPIRED : CRL has expired
13 X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD : format error in certificate’s notBefore field
14 X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD : format error in certificate’s notAfter field
15 X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD : format error in CRL’s lastUpdate field
16 X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD : format error in CRL’s nextUpdate field
17 X509_V_ERR_OUT_OF_MEM : out of memory
18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT : self signed certificate
19 X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN : self signed certificate in certificate chain
20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY : unable to get local issuer certificate
21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE : unable to verify the first certificate
22 X509_V_ERR_CERT_CHAIN_TOO_LONG : certificate chain too long
23 X509_V_ERR_CERT_REVOKED : certificate revoked
24 X509_V_ERR_INVALID_CA : invalid CA certificate
25 X509_V_ERR_PATH_LENGTH_EXCEEDED : path length constraint exceeded
26 X509_V_ERR_INVALID_PURPOSE : unsupported certificate purpose
27 X509_V_ERR_CERT_UNTRUSTED : certificate not trusted
28 X509_V_ERR_CERT_REJECTED : certificate rejected
29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH : subject issuer mismatch
30 X509_V_ERR_AKID_SKID_MISMATCH : authority and subject key identifier mismatch
31 X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH : authority and issuer serial number mismatch
32 X509_V_ERR_KEYUSAGE_NO_CERTSIGN:key usage does not include certificate signing
50 X509_V_ERR_APPLICATION_VERIFICATION : application verification failure

^
14 avril 2013

htmlpdflatexmanmd




OpenSSL - ts

OpenSSL - ts

Outil de Time Stamping Authority (TSA) client/serveur

   ts est un outil de base TSA client/serveur comme spécifié dans la RFC3161. Un TSA peut être une partie d’une PKI et son rôle est de fournir une preuve à long terme de l’existence d’un horodatage avant une date particulière. Brève description du protocole:

        1. Le client TSA calcule un hash 'one-way' pour un fichier de données et l’envoie au TSA.
        2. Le TSA attache la date et l’heure courante au hash reçu, signe le tout et renvoie ce token au client.
        3. Le client TSA reçoit le token et vérifie la signature. Il vérifie également si le token contient le même hash qu’il avait envoyé au TSA.

Génération de requête et Time Stamp

-query Permet de générer une requête avec les options suivantes:

        -rand file:file... Fichier contenant les données pour le générateur pseudo-aléatoire, plusieurs fichiers peuvent être utilisés
        -config configfile Fichier de configuration à utiliser. Seul la section OID est utilisée (remplace la variable OPENSSL_CONF)
        -data file_to_hash Fichier de donnée pour lequel la requête doit être crée.
        -digest digest_bytes Permet de spécifier l’empreinte du message sans le fichier de donnée, au format hexadécimal
        -md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|... Message digest à appliquer au fichier de données
        -policy object_id Stratégie que le client s’attend à ce que le TSA utilise pour créer le time stamp. Sous forme OID numérique ou nom IOD.
        -no_nonce Aucun nonce n’est utilisé, sinon un nombre pseudo-aléatoire 64 bits est inclus dans la requête. nonce est recommandé.
        -cert Le TSA doit inclure son certificat de signature dans la réponse
        -in request.tsq Spécifie une précédente requête time stamp en DER à afficher en sortie
        -out request.tsq Nom du fichier de sortie pour écrire la requête.
        -text Affiche la sortie compréhensible au lieu du DER.

Génération d'une réponse Time Stamp

-reply Créer une réponse time stamp, incluant le status de la réponse et le token lui-même, avec les options suivantes:

        -config configfile Fichier de configuration à utiliser. (remplace la variableOPENSSL_CONF)
        -section tsa_section Nom de la section contenant les paramètres pour la génération de la réponse
        -queryfile request.tsq Nom du fichier contenant la requête timestamp encodée en DER
        -passin password_src Source du mot de passe pour la clé provée du TSA
        -signer tsa_cert.pem Certificat du signataire du TSA au format PEM. Doit avoir eactement un extension d’utilisation de clé ’timeStamping’ et doit être critique
        -inkey private.pem clé privée du signataire du TSA au format PEM
        -chain certs_file.pem Certification au format PEM à inclure dans la répnose en plus du certificat u signataire
        -policy object_id Stratégie par défaut à utiliser pour la réponse à moins que le client en demande une. (nom ou OID)
        -in response.tsr Spécifie une réponse timestamp créé précédemment ou un tocken timestamp au format DER qui sera écrit dns le fichier de sortie. Ne requière pas de requête. Permet d’examiner le contenu d’une réponse
        -token_in avec -in, indique que l’entrée est un otken timestamp DER (ContentInfo) au lieu d’une réponse (TimeStampResp)
        -out response.tsr Fichier de sortie
        -token_out La sortie est un timestamp token (ContentInfo) au lieu d’une réponse (TimeStampResp)
        -text Sort au format human-readable au lieu d’un DER
        -engine id ts va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Vérification de réponse Time Stamp

-verify permet de vérifier une réponse ou un jeton, il accèpte les options suivante:

        -data file_to_hash La réponse ou le token doit être vérifié avec. Ce fihcier est hashé avec le message digest spécifié dans le token.
        -digest digest_bytes La réponse ou le token doit être vérifié avec le message digest
        -queryfile request.tsq La requête originale en DER
        -in response.tsr La réponse qui doit être vérifiée au format DER
        -token_in avec -in, indique que l’entrée est un token DER (ContentInfo) au lie d’une réponse (TimeStampResp)
        -CApath trusted_cert_path Répertoire contenant Les certificats de CA du client
        -CAfile trusted_certs.pem Le nom du fichier contenant un jeu de certificats PEM de ca
        -untrusted cert_file.pem Définis des certificats non-trustés PEM qui peuvent être nécessaire pour créer une chaîne de certificat

Options de configuration

tsa section, default_tsa Section principale. Spécifie le nom d’une autre section qui contient toutes les autres options pour la commande -reply
oid_file voir ca
oid_section voir ca
RANDFILE voir ca
serial Voir le nom du fichier qui contient le numéro de série héxa de la dernière réponse timestamp. il est incréménté de 1
crypto_device Moteur openssl par défaut pour tous les algorithmes disponibles
signer_cert PEM certificat de signature TSA (idem à -signer)
certs Fichier contenant les certificats PEM à inclure dans la réponse (idem à -chain)
signer_key Clé privée du TSA en PEM
default_policy Stratégie par défaut (idem à -policy)
other_policies Liste de stratégies accèptés par le TSA
digests Liste des algorithmes de messages digest accéptès par le TSA
accuracy Source de précision du temps de TSA en secondes, millisecondes et microsecondes
clock_precision_digits Nombre maximum de chiffre représentant la fraction de secondes à inclure dans le champs time (max : 6)
ordering à yes, la réponse générée par ce TSA peut toujour être ordonnée, même si la différence de temps entre 2 réponses est inférieurs à la précision du temps
tsa_name à yes, le sujet du TSA doit est inclus dans le champs name de la réponse
ess_cert_id_chain les objets SignedData créés par le TSA contiennent toujours l’id du certificat du signataire dans l’attribut signed (RC2634)

Exemples

Créé une requêtes pour design.txt avec SHA-1 sans nonce ni stratégie ni certificat dans la réponse:
openssl ts -query -data design1.txt -no_nonce -out design1.tsq
Similaire en spécifiant le digest:
openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b -no_nonce -out design1.tsq
Afficher le contenu des requêtes précédentes:
openssl ts -query -in design1.tsq -text
Créer une requête qui inclus MD5 de design2.txt, le certificat du signataire et nonce et spécifie la stratégie:
openssl ts -query -data design2.txt -md5 -policy tsa_policy1 -cert -out design2.tsq
Créer une réponse:
openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem -signer tsacert.pem -out design1.tsr
idem en utilisant les paramètres dans un fichierde configuration:
openssl ts -reply -queryfile design1.tsq -out design1.tsr
Afficher la réponse:
openssl ts -reply -in design1.tsr -text
Créer un token:
openssl ts -reply -queryfile design1.tsq -out design1_token.der -token_out
Afficher un token
openssl ts -reply -in design1_token.der -token_in -text -token_out
Extraire le token d’un réponse:
openssl ts -reply -in design1.tsr -out design1_token.der -token_out
Ajouter le status ’granted à un token en crént une réponse valide:
openssl ts -reply -in design1_token.der -token_in -out design1.tsr
Vérifier une réponse avec la requête:
openssl ts -verify -queryfile design1.tsq -in design1.tsr -CAfile cacert.pem -untrusted tsacert.pem
Vérifier une réponse qui inclus la chaîne de certificat:
openssl ts -verify -queryfile design2.tsq -in design2.tsr -CAfile cacert.pem
Pour vérifier un token avec le fichier originel:
openssl ts -verify -data design2.txt -in design2.tsr -CAfile cacert.pem
Pour vérifier un token avec une empreinte:
openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b -in design2.tsr -CAfile cacert.pem
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - spkac

OpenSSL - spkac

Utilitaire d’affichage et de génération SPKAC (Signed Public Key And Challenge)

OPTIONS

-in filename Fichier en entrée
-out filename Fichier de sortie
key keyfile Crée un fichier SPKAC en utilisant la clé privée spécifiée -in, -noout, -spksect et -verify seront ignorés
-passin password Source du mot de passe du fichier d’entrée
-challenge string challenge si un SPKAC est créé.
-spkac spkacname Permet une forme alternative de la variable contenant le SPKAC. (Défaut : SPKAC)
-spksect section Spécifie une forme alternative de la section contenant le SPKAC.
-noout N’affiche pas la version texte du SPKAC
-pubkey Affiche la clé publique d’un SPKAC
-verify Vérifie la signature du SPKAC fournis
-engine id spkac va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Exemples

Afficher le contenu d’un SPKAC:
openssl spkac -in spkac.cnf
Vérifier la signature d’un SPKAC:
openssl spkac -in spkac.cnf -noout -verify
Créer un SPKAC en utilisant le challenge 'hello':
openssl spkac -key key.pem -challenge hello -out spkac.cnf
Exemple d’un SPKAC:
SPKAC=MIG5MGUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEA1cCoq2Wa3Ixs47uI7FPVwHVIPDx5yso105Y6zpozam135a
8R0CpoRvkkigIyXfcCjiVi5oWk+6FfPaD03uPFoQIDAQABFgVoZWxsbzANBgkqhkiG9w0BAQQFAANBAFpQtY/FojdwkJ
h1bEIYuc2EeM2KHTWPEepWYeawvHD0gQ3DngSC75YCWnnDdq+NQ3F+X4deMx9AaEglZtULwV4=
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - speed

OpenSSL - speed

Test de performances des algorithmes

OPTIONS

-engine id speed va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
[0 ou plusieurs algorithmes] si aucun algorithme n’est spécifié, test tous les algorithmes disponibles.
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - smime

OpenSSL - smime

Utilitaire smime

OPTIONS

-encrypt Chiffrer un mail.
-decrypt Déchiffrer un mail
-sign Signer un mail
-verify Vérifier un mail signé
-pk7out Prend un message et le sort sous forme d’une structure PKCS#7 PEM
-resign Resigne un message
-in filename Ficher d’entrée
-inform SMIME|PEM-DER Format du fichier d’entrée
-out filename Fichier de sortie
-outform SMIME|PEM|DER Format du fichier de sortie
-stream -indef sont équivalent et activent le streaming I/O pour les opérations d’encodage. Permet de traiter en une seule passe sans maintenir toutes les données en mémoire.
-noindef Désactive le streaming I/O
-content filename Ficher contenant le contenu détaché. Utilisable si la structure PKCS#7 utilise la signature détachée, où le contenu n’est pas inclus.
-text Ajoute les en-têtes MIME en texte clair.
-CAfile file Fichier contenant la chaînes des certificats à truster, utilisé avec -verify
-CApath dir Répertoire contenant les certificats CA en ’hash form’
-md digest Algorithme de digest à utiliser pour signer ou resigner. (Défaut SHA1)
-[cipher] Algorithme de chiffrement à utiliser (défaut RC2 40bits)
-nointern Normalement lors de la vérification d’un message, les certificats inclus dans le message sont recherché pour valider la signature. Cette options utilise ceux spécifié avec -certfile.
-noverify Ne pas vérifier le certificat du signataire d’un message signé
-nochain Ne pas vérifier la chaîne de certificats des signataires.
-nosigs Ne tente pas de vérifier les signatures dans le message
-nocerts En signant un message, le certificat du signataire est normalement inclus. Cette option ne l’inclus pas.
-noattr Normalement un message signé inclus des attributs dont la date de signature et les algorithmes symmétriques supportés. Cette option ne les inclus pas.
-binary Normalement le message est convertit au format canonique utilisant CR et LF comme fin de ligne comme requis dans la spécification S/MIME. Avec cette option, aucune traduction n’est faite.
-nodetach En signant un message avec une signature opaque, plus résistant aux traductions par relais mais ne peuvent pas être lus pas des MTA qui ne supportent pas S/MIME. Avec cette option, aucune traduction n’est faite.
-certfile file Certificats PEM additionnels à inclure avec le message.
-signer file Certificats des signataires si un message est vérifié avec succès, ces certificats seront écris dans le fichier.
-recip file Certificat pour déchiffrer un message. Doit matcher un des bénéficiaires du message.
-inkey file La clé privée à utiliser pour signer ou déchiffrer. Peut être spécifié plusieurs fois.
-passin arg Source du mot de passe de la clé privée.
-rand file(s) fichier(s) contenant les données pour le générateur de nombre aléatoire.
cert.pem Un ou plusieurs certificats utilisés pour chiffrer un message
-to, -from, -subject Champs d’en-tête du mail
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all, -policy_check,
-extended_crl, -x509_strict, -policy -check_ss_sig Diverses options de vérification de chaîne de certificat. voir verify

Notes

   Cette version ne permet qu’un seul signataire, mais permet de vérifier des messages contenant plusieurs signataires.

Codes de sortie

0 succès de l’opération
1 Une erreur s’est produite en parsant les options
2 Un des fichiers en entrée ne peut être lu
3 Une erreur s’est produite en créant un fichier PKCS #7 ou en lisant un message SMIME
4 Une erreur s’est produite en déchiffrant ou en vérifiant le message
5 Le message a été vérifié correctement mais une erreur s’est produite en écrivant les certificats des signataires

Exemples

Créer un message signé en texte clair:
openssl smime -sign -in message.txt -text -out mail.msg -signer mycert.pem
Créer un message signé opaque:
openssl smime -sign -in message.txt -text -out mail.msg -nodetach -signer mycert.pem
Créer un message signé, incluant des certificats additionnels et en lisant la clé privée depuis un autre fichier:
openssl smime -sign -in in.txt -text -out mail.msg -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
Créer un message signé par 2 signataires:
openssl smime -sign -in message.txt -text -out mail.msg -signer mycert.pem -signer othercert.pem
Envoyer un message signé à sendmail, incluant des en-têtes:
openssl smime -sign -in in.txt -text -signer mycert.pem -from steve@openssl.org -to someone@somewhere -subject "Signed message" | sendmail someone@somewhere
Vérifier un message et extraire le certificat du signataire:
openssl smime -verify -in mail.msg -signer user.pem -out signedtext.txt
Envoyer un message chiffré avec 3DES:
openssl smime -encrypt -in in.txt -from steve@openssl.org -to someone@somewhere -subject "Encrypted message" -des3 user.pem -out mail.msg
Signer et chiffrer un mail:
openssl smime -sign -in ml.txt -signer my.pem -text | openssl smime -encrypt -out mail.msg -from steve@openssl.org -to someone@somewhere -subject "Signed and Encrypted message" -des3 user.pem
Déchiffrer un mail:
openssl smime -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
Créer un message chiffrer avec Camellia 128bits:
openssl smime -encrypt -in plain.txt -camellia128 -out mail.msg cert.pem
Ajouter un signataire à un message:
openssl smime -resign -in mail.msg -signer newsign.pem -out mail2.msg
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - sess_id

OpenSSL - sess_id

Utilitaire pour manipuler et afficher les ID de session SSL/TLS

OPTIONS

-inform DER|PEM Format d’entrée
-outform DER|PEM Format de sortie
-in filename Fichier d’entrée contenant les informations de session
-out filename Fichier de sortie où écrire les informations de session
-text Affiche les composante clé privée et publique en texte clair en plus de la version encodée
-cert Si un certificat est présent dans la session il sera sortie, si -text il sera affiché
-noout Ne sort pas la version encodée de la session
-context ID Spécifie l’id de session

Sortie


SSL-Session :
Protocol : TLSv1
Cipher : 0016
Session-ID : 871E62626C554CE95488823752CBD5F3673A3EF3DCE9C67BD916C809914B40ED
Session-ID-ctx : 01000000
Master-Key : A7CEFC571974BE02CAC305269DC59F76EA9F0B180CB6642697A68251F2D2BB57E51DBBB4C7885573192AE9AEE220FACD
Key-Arg : None
Start Time : 948459261
Timeout : 300 (sec)
Verify return code 0 (ok)

Détails

Protocol Protocole utilisé (TLSv1, SSLv2 ou SSLv3)
Cipher Chiffrement utilisé
Session-ID L’id de session en hexa
Session-ID-ctx Contexte de l’id de session en hexa
Master-Key Clé maître de session SSL
Key-Arg Argument clé, utilisé en SSLv2
Start Time Heure de début de la session au format Unix standard
Timeout timeout en secondes
Verify return code code de retour quand le certificat client est vérifié

Notes

La version PEM du fichier de session utilise:
-----BEGIN SSL SESSION PARAMETERS-----
-----END SSL SESSION PARAMETERS-----

^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - s_time

OpenSSL - s_time

Programme de test de performance SSL/TLS

OPTIONS

-connect host:port Spécifie l’hôte:port distant
-www page Spécifie la page à GET. Sans cette options, s_time effectue simplement un handshake pour établir la connexion SSL, mais ne transfère pas de données payload.
-cert certname Certificat à utiliser (PEM)
-key keyfile Clé privée à utiliser
-verify depth Active la vérification du certificat du serveur et spécifie la longueur max de la chaine de certificat du serveur
-CApath directory Répertoire à utiliser pour la vérification du certificat du serveur. doit être un ’hash format’
-CAfile file Fichier contenant les certificats à truster
-new Effectue un test de temps en utilisant un nouvel ID de session pour chaque connexion.
-reuse Effectue un test de temps en utilisant le même ID de session.
-nbio Active l’I/O non bloquant
-ssl2, -ssl3 Désactive l’utilisation de certains protocoles SSL. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveurs et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-cipher cipherlist Permet d’envoyer la liste des chiffrements à modifier. Le serveur détermine quelle suite est utilisée et devrait prendre la première supportée dans la liste.
-time length Spécifie le temps en second que s_time devrait mettre pour établir les connections et optionnellement transférer les données payload du serveur.

Notes

s_time peut être utilisé pour mesurer les performances d’une connexion SSL. Pour se connecter à un serveur SSL HTTP et obtenir la page par défaut:
openssl s_time -connect servername:443 -www / -CApath yourdir -CAfile yourfile.pem -cipher commoncipher [-ssl3]
^
03 juin 2012

htmlpdflatexmanmd




OpenSSL - s_server

OpenSSL - s_server

Serveur SSL/TLS

OPTIONS

-accept port Port TCP d’écoute (défaut : 4433)
-context id ID de Context SSL. Peut être une valeur chaîne.
-cert certname Certificat à utiliser.
-certform PEM|DER Format du certificat
-key keyfile Clé privée à utiliser
-keyform PEM|DER Format de la clé privée
-pass arg Source du mot de passe de la clé privée
-dcert filename, -dkey keyname Certificat et clé privée additionnel
-dcertform format, -dkeyform format, -dpass arg Le format du certificat et de la clé privée supplémentaire, et la source du mot de passe.
-nocert Ne pas utiliser de certificat. Restreint la suite de chiffrements à anonymous DH.
-dhparam filename Fichier de paramètres DH à utiliser
-no_dhe Ne charge aucun paramètre DH et désactive les suites de chiffrement ephemeral DH.
-no_tmp_rsa Pour les suites utilisant une clé RSA temporaire, désactive la génération d’une telle clé.
-verify depth, -Verify depth Spécifie la longueur max de la chaîne de certificat client et force le serveur à demander le certificat du client. -verifie, le client n’a pas à fournir de certificat, -Verify l’oblige.
-crl_check, -crl_check_all Vérifie la CRL. Les crl sont ajoutés au fichier de certificat.
-CApath directory Répertoire contenant les certificats de la CA au ’hash format’
-CAfile file Un fichier contenant les certificats de confiance
-state Affiche l’état de session SSL
-debug Affiche des informations de débogage incluant un dump hexa de tout le trafic
-msg Affiche tous les messages de protocoles avec dump hexa
-nbio_test Tests IO non bloquant
-nbio Active l’I/O non bloquant
-crlf Traduit un line feed depuis le terminal en CR+LF
-quiet Inhibe l’affichage de session et des informations de certificat
-psk_hint hint Utilise l’identité PSK en utilisant la suite de chiffrement PSK.
-psk key Utilise la clé PSK spécifié. La clé est donnée en hexa sans 0x, exemple : 1a2b3c4d
-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1 Désactive l’utilisation de certains protocoles SSL ou TLS. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveurs et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-hack Active une solution de contournement pour certaines anciennes versions de Netscape SSL.
-cipher cipherlist Permet de modifier la liste des chiffrements utilisés par le serveur.
-tlsextdebug Affiche un dump hexa des extensions TLS reçue
-no_ticket Désactive le support de ticket de session RFC4507bis
-www Envoie un message de statut au client quand il se connecte. Inclus beaucoup d’informations sur les chiffrements utilisé et divers paramètres de session, la sortie est au format HTML.
-WWW Emule un serveur web simple. Les pages chargées sont relatives au répertoire courant. (Ex : https://myhost/page.html charge ./page.html)
-HTTP idem, mais les pages chargée contiennent une réponse HTTP complète et correcte.
-engine id s_server va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
-id_prefix arg Génère un ID de session SSL/TLS préfixé par arg.
-rand file(s) Le(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.

Commandes connectées

   Si une connexion est établie avec un client SSL et ni -www ni -WWW n’est utilisé, les données du client sont affichées et l’appuie sur une touche sera envoyé au client:

q Termine la connexion SSL courante, mais accepte les nouvelles connections
Q Termine la connexion SSL courante et quitte.
r Renégocie la session SSL
R Renégocie la session SSL et demande un certificat client
P Envoie un texte en clair à la connexion TCP : devrait forcer le client à se déconnecter dû à une violation de protocole.
S Affiche les informations de statut du cache de session

Notes

s_server peut être utilisé pour débugger les clients SSL. Pour accepter les connections depuis un navigateur web:
openssl s_server -accept 443 -www
Beaucoup de navigateurs ne supportent que les suites de chiffrement RSA. Les paramètres de session peuvent être imprimés avec sess_id.
^
09 avril 2012

htmlpdflatexmanmd




OpenSSL - s_client

OpenSSL - s_client

Programme client SSL/TLS qui peut se connecter à un hôte distant en utilisant SSL/TLS. Utilitaire de diagnostique très utile

OPTIONS

-connect host:port Hôte et port distant (défaut : localhost:4433)
-cert certname Le certificat à utiliser (défaut : n’utilise pas de certificat)
-certform format Format du certificat, DER ou PEM
-key keyfile La clé privée à utiliser
-keyform format Le format de la clé privée, DER ou PEM
-pass arg Source du mot de passe de la clé privée
-verify depth Active la vérification du certificat du serveur et spécifie la longueur max de la chaine de certificat du serveur
-CApath directory Répertoire à utiliser pour la vérification du certificat du serveur. doit être un ’hash format’
-CAfile file Fichier contenant les certificats à truster
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all,
-policy_check, -extended_crl, -x509_strict, -policy -check_ss_sig Définir divers options de validation de la chaîne de certificat (voir verify)
-reconnect Se reconnecte au même serveur 5 fois avec le même session ID, utile pour tester le cache de session.
-pause effectue une pause d’une seconde entre chaque appel de lecture et d’écriture
-showcerts Affiche la chaîne entière de certificat (défaut : seul le certificat du serveur est affiché)
-prexit Affiche les informations de session quand le programme quitte.
-state Affiche les statistiques de session SSL
-debug Affiche des informations additionnelles, incluant un dump hexa de tout le traffic
-msg Affiche tous les messages de protocole avec un dump hexa
-nbio_test Tests IO non bloquant
-nbio Active l’I/O non bloquant
-crlf Traduit un line feed depuis le terminal en CR+LF
-ign_eof Inhibe la fin de connection quand la fon du fichier est atteind
-quiet N’affiche pas d’information de session et des certificats. active implicitement -ign_oef
-psk_identity identity Utilise l’identité PSK lors de l’utilisation de la suite de chiffrement PSK
-psk key Sépcifie la clé PSK lors de l’utilisation de la suite de chiffrement PSK. La clé est donnée en nombre hexa sans le 0x, par exemple : -psk 1a2b3c4d
-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1 Désactive l’utilisation de certains protocoles SSL ou TLS. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveur et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-cipher cipherlist Permet d’envoyer la liste des chiffrements à modifier. Le serveur détermine quelle suite est utilisée et devrait prendre la première supportée dans la liste.
-starttls protocol Envoie les messages spécifique au protocole pour passer en TLS pour les communications. le protocole est un mot clé pour le protocole (smtp, pop3, imap et ftp)
-tlsextdebug Affiche un dump hexa des extensions TLS reçues du serveur
-no_ticket Désactive le support de ticket de session RFC4507bis
-sess_out filename sort la session SSL dans le fichier
-sess_in sess.pem Charge la session SSL depuis le fichier. Le client va tenter de résumer une connection depuis cette session.
-engin id s_client va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
-rand file(s) Le(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.

Exemples

se connecter à un serveur SSL distant:
openssl s_client -connect servername:443
^
09 avril 2012

htmlpdflatexmanmd




OpenSSL - rsautl

OpenSSL - rsautl

Utilitaire rsa

OPTIONS

-in filename Fichier d’entrée
-out filename Fichier de sortie
-inkey file Fichier de clé privée RSA en entrée
-pubin Le fichier d’entrée est une clé publique RSA
-certin L’entrée est un certificat contenant une clé publique RSA
-sign Signe la donnée en entrée et sort le résultat signé. requière une clé privée RSA
-verify Vérifie les données en entrée et sort les données récupérées
-encrypt Chiffre l’entrée en utilisant la clé publique RSA
-decrypt Déchiffre l’entrée en utilisant la clé privée RSA
-pkcs, -oeap, -ssl, -raw Le padding à utiliser (respectivement PKCS#1 v1.5, PKCS#1 OEAP, padding utilisé dans ssl v2, aucun padding). pour les signatures, seul -pkcs et -raw sont utilisé
-hexdump Dump en hexa les données en sortie
-asn1parse asn1parse la sortie. utile avec -verify

Notes

   rsautl utilise directement l’algorithme RSA, il ne peut être utlisé que pour de petites portions de données.

Exemples

Signer des données en utilisant une clé privée:
openssl rsautl -sign -in file -inkey key.pem -out sig
Récupérer les données signées:
openssl rsautl -verify -in sig -inkey key.pem
Examiner les données signées en raw:
openssl rsautl -verify -in file -inkey key.pem -raw -hexdump


0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ................
0070 - ff ff ff ff 00 68 65 6c-6c 6f 20 77 6f 72 6c 64 .....hello world

   Ce block est formaté PKCS#1. çà été fait en utilisant encrypt puis en déchiffrant le block detype 2 (le 2eme octet) et un padding aléatoire visible à la place des octets 0xff. Il est possible d’analyser la signature des certificats en utilisant rsautl avec asn1parse.

En considérant un exemple auto-signé dans certs/pca-cert.pem:
openssl asn1parse -in pca-cert.pem


0:d=0 hl=4 l= 742 cons : SEQUENCE
4:d=1 hl=4 l= 591 cons : SEQUENCE
8:d=2 hl=2 l= 3 cons : cont [ 0 ]
10:d=3 hl=2 l= 1 prim : INTEGER :02
13:d=2 hl=2 l= 1 prim : INTEGER :00
16:d=2 hl=2 l= 13 cons : SEQUENCE
18:d=3 hl=2 l= 9 prim : OBJECT :md5WithRSAEncryption
29:d=3 hl=2 l= 0 prim : NULL
31:d=2 hl=2 l= 92 cons : SEQUENCE
33:d=3 hl=2 l= 11 cons : SET
35:d=4 hl=2 l= 9 cons : SEQUENCE
37:d=5 hl=2 l= 3 prim : OBJECT :countryName
42:d=5 hl=2 l= 2 prim : PRINTABLESTRING :AU
....
599:d=1 hl=2 l= 13 cons : SEQUENCE
601:d=2 hl=2 l= 9 prim : OBJECT :md5WithRSAEncryption
612:d=2 hl=2 l= 0 prim : NULL
614:d=1 hl=3 l= 129 prim : BIT STRING

Le BIT STRING final contient la signature actuelle, et peut être extrait avec:
openssl asn1parse -in pca-cert.pem -out sig -noout -strparse 614
La clé publique du certificat peut être extrait avec:
openssl x509 -in test/testx509.pem -pubkey -noout ›pubkey.pem
La signature peut être analysée avec:
openssl rsautl -in sig -verify -asn1parse -inkey pubkey.pem -pubin


0:d=0 hl=2 l= 32 cons : SEQUENCE
2:d=1 hl=2 l= 12 cons : SEQUENCE
4:d=2 hl=2 l= 8 prim : OBJECT :md5
14:d=2 hl=2 l= 0 prim : NULL
16:d=1 hl=2 l= 16 prim : OCTET STRING
0000 - f3 46 9e aa 1a 4a 73 c9-37 ea 93 00 48 25 08 b5 .F...Js.7...H%..

C’est la version parsée d’une structure ASN1 DigestInfo, ici avec un digest md5.
La partie du certificat qui a été signée peut être extraite avec:
openssl asn1parse -in pca-cert.pem -out tbs -noout -strparse 4
et son digest calculé avec:
openssl md5 -c tbs
MD5(tbs)= f3:46:9e:aa:1a:4a:73:c9:37:ea:93:00:48:25:08:b5
Qui peut être récupéré avec cette valeur.
^
09 avril 2012

htmlpdflatexmanmd




OpenSSL - rsa

OpenSSL - rsa

Traitement des clés rsa

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie où écrire la clé
-passout password source du mot de passe du fichier de sortie
-sgckey Utilisé pour l’algorithme modifié NET utilisé avec certaines versions de Microsoft IIS et les clé SGC.
-des|-des3|-idea Algorithme utilisé pour chiffrer la clé privée.
-text Affiche des infos sur les clés privée et publique
-noout N’affiche pas la version encodée de la clé
-modulus Affiche la valeur du modulo de la clé
-check Vérifie la consistance de la clé privée RSA
-pubin Lit une clé publique en entrée plutôt qu’une clé privée
-pubout Sort une clé publique plutôt qu’une clé privée
-engine id rsa va tenter d’obtenir une référence fonctionnelle de ce moteur.

Notes

la forme PEM de la clé privée contient:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

la forme PEM de la clé publique contient:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

Exemples

Supprimer le passphrase d’une clé privée:
openssl rsa -in key.pem -out keyout.pem
Chiffrer une clé privée avec triple DES:
openssl rsa -in key.pem -des3 -out keyout.pem
Convertir une cléprivée PEM en DER:
openssl rsa -in key.pem -outform DER -out keyout.der
Afficher les composantes de la clé privée:
openssl rsa -in key.pem -text -noout
Afficher la partie publique de la clé privée:
openssl rsa -in key.pem -pubout -out pubkey.pem
^
31 mars 2012

htmlpdflatexmanmd




OpenSSL - req

OpenSSL - req

Utilitaire pour créer et traiter des requêtes pkcs#10

OPTIONS

-inform PEM|DER Format du fichier d’entrée
-outform PEM|DER Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie
-passout arg Source du mot de passe pour le fichier de sortie
-text Affiche la requête en clair
-subject Affiche le sujet de la requête
-pubkey Affiche la clé publique
-noout N’affiche pas la version encodée de la requête
-modulus Affiche le modulo de la clé publique contenue dans la requête
-verify Vérifie la signature de la requête
-new Génère une nouvelle requête de certificat.
-subj arg Remplace le champ sujet dans la requête d’entrée doit être au format /type0=value0/type1=value1/typeN=valueN...
-rand file(s) Fichier(s) contenant les données aléatoire pour le générateur de nombre aléatoire.
-newkey arg Crée une nouvelle requête de certificat et une nouvelle clé privée. arg peut être sous la forme rsa:nbits où nbits est la longueur de la clé RSA. Tous les autres algorithmes supportent la forme alg:file où file est un fichier de paramètre. param:file utilise le fichier de paramètre ou le certificat spécifié par file. L’algorithme est déterminé par les paramètres.
-pkeyopt opt:value Définie une options d’algorithme. (Voir genpkey)
-key filename Spécifie le fichier contenant la clé privée à lire. Accepte le format PKCS#8.
-keyform PEM-DER Le format du fichier de clé privée.
-keyout filename Nom du fichier où écrire la clé privée.
-nodes Si cette option est spécifiée, la clé privée créée n’est pas chiffrée
-[digest] Spécifie le message digest à utiliser pour signer la requête.
-multivalue-rdn Permet d’interpréter -subj au format RDN multi-valué (exemple : /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe, sinon le format sera : 123456+CN=John Doe)
-x509 Sort un certificat auto-signé au lieu d’une requête de certificat.
-days -n avec -x509, spécifie la durée de validité du certificat (défaut : 30jours)
-set_serial n Définis le numéro de série du certificat auto-signé. Peut-être en décimal ou en hexa.
-extensions section
-reqexts section Spécifient les sections alternatives à inclure dans la requête.
-utf8 interprète les valeurs de champs au format UTF8
-nameopt option détermine comment le sujet et l’issuer sont affichés (voir x509)
-repopt Personnalise le format de sortie avec -text. l’argument peut être une simple options ou plusieurs, séparés par des ’,’ (voir x509)
-asn1-kludge Par défaut, req sort les requêtes de certificat ne contenant pas d’attributs dans le format PKCS#10 correct. Cependant, certaines CA acceptent uniquement les requêtes ne contenant pas d’attributs dans une forme invalide : cette options produit ce format invalide (les attributs dans une requête PKCS#10 sont définis comme un set d’attribut SET OF. Ils ne sont pas optionnels donc si aucun attribut n’est présent, il devrait être encodé comme un SET OF vide, une forme invalide ne contient pas ce SET OF vide)
-no-asn1-kludge Inverse l’effet de -asn1-kludge
-newhdr Ajoute le mot NEW dans l’en-tête et pied de page PEM.
-batch Mode non-interactif
-verbose Affiche les détails sur l’opération courante
-engine id req va tenter d’obtenir une référence fonctionnelle du moteur spécifié
-keygen_engine id Spécifie un moteur qui devrait être utilisé pour les opérations de génération de clé.

Format du fichier de configuration

input_password output_password Les mots de passe pour les fichier de clé privée d’entrée et de sortie (remplace passin et passout)
default_keyfile Taille en bits de la clé (défaut 512, remplace -newkey)
oid_file Spécifie un fichier contenant des OID additionnels. Chaque ligne consiste de l’oid suivi d’un espace blanc, suivi du nom cours, suivi par un blanc et suivi par un nom long.
oid_section Spécifie la section dans le fichier de configuration contenant les oid supplémentaires
RANDFILE Spécifie un nom de fichier contenant les données aléatoires à utiliser par le moteur de génération de nombres pseudo-aléatoires
encrypt_key à no, la clé privée n’est pas chiffrée. (Remplace -nodes)
default_md Spécifie l’algorithme digest à utiliser. (md5, sha1 ou mdc2, défaut : md5)
string_mask Masque l’utilisation de certaines chaines dans certains champs. default utilise PrintableStrings, T61Strings et BMPStrings.
pkix utilise PrintableStrings et BMPStrings. utf8only utilise UTF8Strings. nombstr utilise PrintableStrings et T61Strings.
req_extensions Spécifie la section du fichier de configuration contenant la liste des extensions à ajouter à une requête (remplace -reqexts)
x509_extensions Spécifie la section du fichier de configuration contenant un liste des extensions à ajouter au certificat généré avec -x509 (remplace -extensions)
prompt à no désactive la demande des champs du certificat et prend les valeurs dans le fichier de configuration
utf8 à yes les valeurs de champs sont interprétés en utf8 (ASCII par défaut)
attributes Spécifie la section contenant les attributs de requête. Identique à distinguished_name. Actuellement ignoré par OpenSSL.
distinguished_name Spécifie la section contenant les champs dn à demander pour générer un certificat ou une requête.

Format des sections Distinguished Name et Attribute

Il y’a 2 formats pour ces sections. Si l’option prompt est à no, ces sections consistent de noms de champs et de valeur. Par exemple:
CN=My Name
OU=My Organization
emailAddress=someone@somewhere.org

Si prompt est absent ou à yes, ces sections contiennent la liste des champs à demander:
fieldName="prompt"
fieldName_default="default field value"
fieldName_min= 2
fieldName_max= 4

fieldname est le nom d’un champs, par exemple commonName ou CN. "prompt" est utilisé pour demander à l’utilisateur d’entrer les informations du champ. Si l’utilisateur n’entre rien, ce champ est omis.
- Si une valeur par défaut est définie, elle sera utilisée si l’utilisateur n’entre rien. L’utilisateur peut outrepasser cette valeur par défaut en entrant le caractère '.'
- Les limites min et max peuvent être utilisé pour limiter les valeurs de champs. Par exemple, countryName peut seulement avoir 2 caractères et doivent être correspondre à un PrintableString
- Certains champs comme organizationName peuvent être utilisé plus d’une fois dans un DN. Un second organizationName peut être entré en l’appelant 1.organizationName
- Les noms de champs permis sont des noms cours ou long d’object identifier. Incluant : commonName, countryName, localityName, organizationName, organizationUnitName, stateOrProvinceName. emailAddress, name, surname, givenName, dnQualifier.
- Des object identifier additionnels peuvent être définis avec les options oid_file et oid_section dans le fichier de configuration. Ces champs additionnels seront traités comme si c’était un DirectoryString

Exemples

Examiner et vérifier une requête de certificat:
openssl req -in req.pem -text -verify -noout
Créer une clé privée et générer une requête de certificat:
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out req.pem
Idem en utilisant uniquement req:
openssl req -newkey rsa:1024 -keyout key.pem -out req.pem
Générer un certificat root auto-signé:
openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem
Exemple de fichier pointé par l’option oid_file:
1.2.3.4 shortName A longer Name
1.2.3.6 otherName Other longer Name
Exemple d’une section pointée par oid_section:
testoid1=1.2.3.5
testoid2=$testoid1.6

Exemple de fichier de configuration demandant les valeurs de champs


[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
    
dirstring_type = nobmp
    
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
    
localityName = Locality Name (eg, city)
    
organizationalUnitName = Organizational Unit Name (eg, section)
    
commonName = Common Name (eg, YOUR name)
commonName_max = 64
    
emailAddress = Email Address
emailAddress_max = 40
    
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
    
[ v3_ca ]
    
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

Exemple de configuration contenant toutes les valeurs de champs


RANDFILE = $ENV ::HOME/.rnd
    
[ req ]
default_bits = 1024
default_keyfile = keyfile.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
prompt = no
output_password = mypass
    
[ req_distinguished_name ]
C = GB
ST = Test State or Province
L = Test Locality
O = Organization Name
OU = Organizational Unit Name
CN = Common Name
emailAddress = test@email.address
    
[ req_attributes ]
challengePassword = A challenge password

Notes

Le format PEM inclus:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----

Certains logiciels comme Netscape certificate server nécessitent:
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----

Variables d'environnement

OPENSSL_CONF peut être utilisé comme emplacement de fichier de configuration alternatif.
^
31 mars 2012

htmlpdflatexmanmd




OpenSSL - rand

OpenSSL - rand

Générateur pseudo-aléatoire

OPTIONS

-out file Spécifie le fichier à écrire
-rand file(s) Utilise le(s) fichier(s) pour le moteur de nombre aléatoire.
-base64 Effectue un encodage en base 64 sur la sortie
-hex Affiche la sortie en hexa.
^
31 mars 2012

htmlpdflatexmanmd




OpenSSL - pkeyutl

OpenSSL - pkeyutl

Utilitaire de manipulation de clé publique

OPTIONS

-in filename Spécifie le nom du fichier d’entrée
-out filename Spécifie le fichier de sortie
-inkey file fichier clé d’entrée, par défaut devrait être une clé privée.
-keyform PEM|DER Format de clé PEM, DER ou ENGINE
-passin arg Source du mot de passe de la clé en entrée
-peerkey file Fichier de clé pair, utilisé par les opérations de dérivation de clé
-peerform PEM|DER Format du fichier de clé pair PEM, DER ou ENGINE
-engine id pkeyutil va tenter d’obtenir une référence fonctionnelle de ce moteur.
-pubin Le fichier d’entrée est une clé publique
-certin L’entrée est un certificat contenant une clé publique
-rev Renverse l’ordre du tampon d’entrée. Utile pour certains libraires comme CryptoAPI qui présente l’entrée au format little endian
-sign Signe les données d’entrée et sort le résultat signé, requière une clé privée.
-verify Vérifie les données en entrée avec le fichier de signature et indique si l’opération à réussie ou non
-verifyrecover Vérifie les données entrée et sort les données récupérées
-encrypt Chiffre les données en entrée en utilisant un clé publique
-decrypt Déchiffre les données en entrée en utilisant une clé privée
-derive Dérive une clé partagée en utilisant une clé paire
-hexdump Dump en hexa les données sorties
-asn1parse asn1parse les données en sortie. Utilisé avec -verifyrecover

Notes

   Les opérations et options dépendent de l’algorithme de clé et de son implémentation. Tous les algorithmes supportent l’option digest:alg qui spécifie le digest à utiliser pour les opérations de signature et vérification.

RSA

   RSA supporte les opérations de chiffrement, déchiffrement, signature et vérification.

-rsa_padding_mode:mode Définis le padding RSA. (pkcs1, sslv23, none oaep, x931 et pss). oeap supporte uniquement le chiffrement et déchiffrement. pss support uniquement la signature et la vérification. rsa_pss_saltlen:len pour le mode pss, spécifie la longueur du salt. (Valeurs spéciales : -1 - le salt est à la longueur du digest, -2 - valeur maximum permise).

DSA

   DSA support les opérations de signature et de vérification uniquement.

DH

   DH supporte uniquement les opérations de dérivation

EC

   EC supporte les opérations de signature, de vérification et de dérivation. La signature et vérification utilise ECDSA et la dérivation ECDH.

Exemples

Signer des données en utilisant une clé privée:
openssl pkeyutl -sign -in file -inkey key.pem -out sig
Récupérer des données signées:
openssl pkeyutl -verifyrecover -in sig -inkey key.pem
Vérifier la signature:
openssl pkeyutl -verify -in file -sigfile sig -inkey key.pem
Signer les données en utilisant un message digest:
openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256
Dériver une clé secrète partagée:
openssl pkeyutl -derive -inkey key.pem -peerkey pubkey.pem -out secret
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkeyparam

OpenSSL - pkeyparam

Outil de traitement de paramètres d'algorithme de clé publique

OPTIONS

-in filename Fichier à lire au format PEM
-out filename Fichier à écrire au format PEM
-text Affiche les paramètres en clair en plus de la version encodée
-noout Ne sort pas la version encodée des paramètres
-engine id pkeyparam va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Afficher la version des paramètres:
openssl pkeyparam -in param.pem -text
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkey

OpenSSL - pkey

Outil de traitement de clé privée ou publique

OPTIONS

-inform DER|PEM Format du fichier d’entrée
-outform DER|PEM Spécifie le format de sortie
-in filename Fichier à lire
-out filename Fichier à écrire
-passin arg source du mot de passe du fichier d’entrée
-passout password source du mot de passe du fichier de sortie.
-cipher Chiffre la clé privée avec le chiffrement spécifié
-text Affiche les composant de clé privée ou publique en texte clair en plus de la version encodée.
-text_pub Affiche uniquement la composante clé publique.
-noout Ne sort pas la version encodée de la clé
-pubin Par défaut, la clé privée est lue depuis le fichier d’entrée, cette option lit une clé publique à la place
-pubout Par défaut une clé privée est écrite en sortie. Cette option sort une clé publique.
-engine id pkey va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Enlever un passphrase d’une clé RSA:
openssl pkey -in key.pem -out keyout.pem
Chiffrer une clé publique avec 3DES:
openssl pkey -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl pkey -in key.pem -outform DER -out keyout.der
Afficher les composants de clé privée:
openssl pkey -in key.pem -text -noout
Afficher les composants publics d’une clé privée:
openssl pkey -in key.pem -text_pub -noout
Sortie la partie publique d’une clé privée:
openssl pkey -in key.pem -pubout -out pubkey.pem
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkcs7

OpenSSL - pkcs7

Utilitaire pkcs #7

OPTIONS

-inform DER|PEM Spécifie le format d’entrée
-outform DER|PEM Spécifie le format de sortie
-in filename Fichier à lire
-out filename Fichier à écrire
-print-certs Affiche les certificats et CRL contenus dans le fichier.
-text Affiche les détails des certificats
-noout Ne sort pas la version encodée de la structure PKCS #7
-engine id pkcs7 va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Convertir un fichier PKCS #7 PEM en DER:
openssl pkcs7 -in file.pem -outform DER -out file.der
Afficher tous les certificats dans un fichier:
openssl pkcs7 -in file.pem -print_certs -out certs.pem

Notes

Le format PKCS #7 PEM utilise:
-----BEGIN PKCS7-----
-----END PKCS7-----

Pour assurer la compatibilité avec certaines CA, il accepte également:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - pkcs12

OpenSSL - pkcs12

Utilitaire pkcs #12

Options de lecture

-in filename Fichier pkcs#12 à lire
-out filename Fichier où écrire les certificats et clé privée au format PEM.
-pass arg, -passin arg passphrase pour chiffrer les clés privées
-noout Ne sort pas les clé et certificats dans le fichier de sortie.
-clcerts sort uniquement les certificats clients (pas de certificat CA)
-cacerts sort uniquement les certificats CA
-nocerts Ne sort pas les certificats
-nokeys Ne sort pas les clés privées
-info Affiche des informations additionnelles sur la structure du fichier PKCS#12
-des|-des3|-idea|-aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256 Algorithme à utiliser pour chiffrer la clé privée.(défaut : des3)
-nodes Ne chiffre pas les clés privées
-nomacver Ne tente pas de vérifier l’intégrité MAC avant de lire le fichier
-twopass Séparer l’intégrité et le chiffrement du mot de passe. Peut rendre le fichier illisible.

Options de création

-export Spécifie une création de fichier PKCS#12
-out filename Nom du fichier PKCS#12 à créer
-in filename Fichier à lire contenant les certificats et clé privées au format PEM
-inkey filename fichier contenant la clé privée à lire.
-name friendlyname ’friendly name’ pour le certificat et sa clé privée.
-certfile filename Fichier où lire les certificats additionnels
-caname friendlyname friendly name’ pour les autres certificats. Peut-être spécifié plusieurs fois
-pass arg, -passout arg source du mot de passe pour le fichier de sortie.
-passin password Source du mot de passe pour déchiffrer la clé privée.
-chain Tente d’inclure toute la chaîne de certificat
-descert Chiffre le certificat en utilisant 3des (défaut : des3 pour la clé privée et RC2-40bits pour le certificat)
-keypbe alg, -certpbe alg Algorithme utilisé pour chiffrer la clé et les certificats. peut-être un algorithme PKCS#15 ou PKCS#12 PBE.
-keyex|-keysig Spécifie que la clé privée doit être utilisé pour un échange de clé ou juste signer. Uniquement interprété par MSIE et logiciels MS.
-macalg digest Spécifie l’algorithme digest MAC (défaut : SHA1)
-nomaciter, -noiter Affecte le compteur d’itération dans les algorithmes de clé et MAC.(défaut : 2048)
-maciter Inclus pour compatibilité avec les versions précédentes.
-nomac Ne tente pas de fournir l’intégrité MAC.
-rand file(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.
-CAfile file Fichier de la CA
-CAptah dir Répertoire contenant les certificats CA.
-CSP name Ecrit le nom sous la forme Microsoft CSP name.

Exemples

Lire un fichier PKCS #12 et le sortir dans un fichier:
openssl pkcs12 -in file.p12 -out file.pem
Sortie seulement les certificats clients dans un fichier:
openssl pkcs12 -in file.p12 -clcerts -out file.pem
Sortir uniquement la clé privée dans un fichier:
openssl pkcs12 -in file.p12 -nocerts -out file.pem
Ne pas chiffrer la clé privée:
openssl pkcs12 -in file.p12 -out file.pem -nodes
Afficher des informations sur le fichier PKCS #12:
openssl pkcs12 -in file.p12 -info -noout
Créer un fichier PKCS #12:
openssl pkcs12 -export -in file.pem -out file.p12 -name "My Certificate"
Inclure des certificats supplémentaires:
openssl pkcs12 -export -in file.pem -out file.p12 -name "My Certificate" -certfile othercerts.pem
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - passwd

OpenSSL - passwd

Calcul des hash de mot de passe

OPTIONS

-crypt Utilise l’algorithme crypt (défaut)
-1 Utilise l’algorithme MD5 type BSD 1
-apr1 utilise l’algorithme aprl (variante apache de l’algorithme BSD)
-salt string Spécifier le salt à utiliser. Implique -noverify
-in file Fichier contenant les mots de passes
-stdin Lit les mots de passe depuis stdin
-noverify n’effectue pas de vérification lors de la lecture d’un mot de passe depuis le terminal
-quiet n’affiche pas d’alertes quand les mots de passe donnés sur la ligne de commande sont tronqués.
-table Dans la liste de sortie, ajoute les mots de passe en texte clair, suivi d’un TAB et du hash.

Exemples

openssl passwd -crypt -salt xx password:
xxj31ZMTZzkVA
openssl passwd -1 -salt xxxxxxxx password:
$1$xxxxxxxx$UYCIxa628.9qXjpQCjM4a.
openssl passwd -apr1 -salt xxxxxxxx password:
$apr1$xxxxxxxx$dxHfLAsjHkDRmG83UXe8K0
^
18 mars 2012

htmlpdflatexmanmd




OpenSSL - ocsp

OpenSSL - ocsp

Utilitaire OCSP

Options client

-out filename Fichier de sortie
-issuer filename Spécifie l’issuer du certificat courant. Peut-être spécifié plusieurs fois et doit être au format PEM. Doit être spécifié avant -cert
-cert filename Ajoute le certificat spécifié à la requête.
-serial num Idem à cert excepté que le certificat avec le numéro de série spécifié est ajouté à la requête, en entier décimal précédé par 0x. Des valeurs négatives sont acceptées.
-signer filename, -signkey filename Signe la requête OCSP en utilisant le certificat spécifié par signer et la clé privée spécifiée par signkey. Sans signkey, lit la clé privée depuis le certificat du signer. Sans ces 2 options, la requête n’est pas signée.
-sign_other filename Certificats additionnels à inclure dans la requête signée.
-nonce, -no-once Ajoute ou désactive une extension OCSP nonce d’une requête. Normalement si une requête OCSP est entrée en utilisant respin, nonce n’est pas ajouté. Si une requête OCSP est créée, un nonce est automatiquement ajouté.
-req_text, -resp_text, -text Affiche la forme texte d’une requête ou d’une réponse OCSP ou les 2 respectivement.
-reqout file, respout file Écrit la requête ou la réponse en DER
-reqin file, respin file Lit la requête ou la réponse depuis le fichier spécifié.
-url responder_url Spécifie l’url du répondeur.
-host hostname:port, path pathname La requête est envoyée à l’hôte spécifié, ou le chemin HTTP (défaut : /)
-CAfile file, -CApath pathname Fichier ou répertoire contenant les certificats CA. Utilisé pour vérifier la réponse OCSP.
-verify_other file Fichier contenant des certificats additionnels à rechercher lors de la tentative de localisation du certificat de signature de la réponse OCSP.
-trust_other Les certificats spécifié par -verify_other sont explicitement trustés sans vérification additionnelles. Utile pour une chaîne complète de certificat.
-VAfile file Fichier contenant les certificats du répondeur trustés explicitement. Equivalent à -verify_other et -trust_other.
-noverify Ne vérifie par la signature du répondeur OCSP ou les valeurs nonce.
-no_intern Ignore les certificats contenus dans la réponse OCSP lors de la recherche du certificat du signataire.
-no_signature_verify Ne vérifie pas la signature de la réponse OCSP.
-no_cert_verify Ne vérifie par les certifications des signataires de la réponse OCSP.
-no_chain N’utilise pas les certificats dans la réponse comme certificats CA additionnels non-trustés.
-no_cert_checks N’effectue aucune vérification supplémentaire sur les certificats des signataires de la réponse OCSP
-validity_period nsec, -status_age age Spécifie la plage de temps en secondes toléré dans une réponse OCSP. Chaque réponse de statut de certificat inclus notBefore et notAfter. Le temps courant devrait être entre ces 2 valeurs. Cette options permet de spécifier une autre plage de temps.
-md5|-sha1|-sha256|-ripemod160|... Définis l’algorithme digest à utiliser pour l’identification du certificat dans la requête OCSP. Défaut : SHA1.

Options serveur

-index indexfile Fichier d’index au format ca contenant les informations de révocation de certificat. Si cette option est spécifiée, ocsp est en mode répondeur, sinon il est en mode client.
-CA file Certificat CA correspondant aux informations de révocation dans indexfile.
-rsigner file Certificat pour signer les réponses
-rother file Certificats additionnels à inclure dans la réponse
-resp_no_certs N’inclus pas de certificat dans la réponse.
-resp_key_id Identifie le certificat signataire en utilisant l’ID de clé. Défaut : utilise le nom du sujet.
-rkey file La clé privée pour signer les réponses.
-port portnum Port d’écoute des requêtes OCSP. Doit être spécifié dans l’option url.
-nrequest number Le serveur va quitter après avoir reçu number requêtes, défaut : illimité.
-nmin minutes, -ndays days Nombre de minutes ou de jours où de nouvelles informations de révocation sont disponibles. Utilisé dans le champ nextUpdate. Sans cette option, ce champ est omis, les nouvelles informations sont immédiatement disponible.

Exemples

Créer une requête OCSP et l’écrire dans un fichier:
openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -reqout req.der
Envoyer une requête à un répondeur OCSP:
openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -url http://ocsp.myhost.com/ -resp_text -respout resp.der
Lire une réponse OCSP et l’afficher au format texte:
openssl ocsp -respin resp.der -text
Serveur OCSP sur le port 8888 en utilisant une configuration standard CA, et un certificat de répondeur séparé:
openssl ocsp -index demoCA/index.txt -port 8888 -rsigner rcert.pem -CA demoCA/cacert.pem -text -out log.txt
Idem, mais quitte après 1 requête:
openssl ocsp -index demoCA/index.txt -port 8888 -rsigner rcert.pem -CA demoCA/cacert.pem -nrequest 1
Demander des informations de statut en utilisant une requête générée en interne:
openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA demoCA/cacert.pem -issuer demoCA/cacert.pem -serial 1
Demander des informations de statut en utilisant une requête lu depuis un fichier, sort la réponse dans un autre fichier:
openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA demoCA/cacert.pem -reqin req.der -respout resp.der
^
09 mars 2012

htmlpdflatexmanmd




OpenSSL - nseq

OpenSSL - nseq

Créer ou examiner une séquence de certificat Netscape

OPTIONS

-in filename Fichier à examiner
-out filename Fichier de sortie
-toseq Normalement, une séquence de certificat Netscape sera fournis et la sortie contient les certificats.et cette option, la situation et inversée.

Exemples

Sortir les certificats d’une séquence de certificat Netscape:
openssl nseq -in nseq.pem -out certs.pem
Créer une séquence de certificat Netscape:
openssl nseq -in certs.pem -toseq -out nseq.pem

Notes

La forme PEM utilise:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

^
09 mars 2012

htmlpdflatexmanmd




OpenSSL - genrsa

OpenSSL - genrsa

Outil de génération de clé RSA, remplacé par genpkey

OPTIONS

-out filename Nom du fichier de sortie
-passout arg Source du mot de passe pour le fichier de sortie
-des|-des3|-idea Algorithme à utiliser pour chiffrer la clé privée
-F4|-3 L’exposant publique à utiliser, soit 65537 ou 3. (défaut 65537)
-rand file(s) fichier(s) contenant les données aléatoires utilisée par le générateur de nombre aléatoire.
-engine id genrsa va tenter d’obtenir une référence fonctionnelle pour le moteur spécifié.
numbits Taille de la clé privée, doit être le dernier argument (défaut 512)
^
09 mars 2012

htmlpdflatexmanmd




OpenSSL - genpkey

OpenSSL - genpkey

Génération de clé privée

OPTIONS

-out filename Nom du fichier de sortie
-outform PEM|DER Format du fichier de sortie
-pass arg Source du mot de passe du fichier de sortie
-cipher Algorithme à utiliser pour chiffrer la clé privée.
-engine id genpkey va tenter d’obtenir une référence fonctionnelle pour le moteur spécifié.
-algorithm alg Algorithme de clé publique à utiliser tel que RSA, DSA ou DH. Doit précéder -pkeyopt
-pkeyopt opt:value Définis une option pour l’algorithme de clé publique.
-genparam Génère un jeu de paramètres au lieu d’une clé privée. Doit précéder -algorithm, -paramfile ou -pkeyopt
-paramfile filename Fichier contenant les paramètres à utiliser pour générer la clé privée. Doit précéder -pkeyopt.
-text Affiche une représentation texte des clés publique et privée et des paramètres.

Options de génération de clé

   Les options prises en charge par chaque algorithme et même chaque mise en œuvre d’un algorithme peut varier.

Options de génération de clé RSA

rsa_keygen_bits:numbits Nombre de bits dans la clé générée. (défaut : 1024)
rsa_keygen_pubexp:value Valeur d’exposant publique RSA, en décimal ou hexa (défaut : 65537)

Options de génération de clé DSA

dsa_paramgen_bits:numbits Nombre de bits dans les paramètres générés (défaut 1024)

Options de génération de paramètres DH

dh_paramgen_prime_len:numbits Nombre de bits dans le paramètre p
dh_paramgen_generator:value valeur à utiliser pour le générateur g
dh_rfc5114:num Applique les paramètres RFC5114. num peut être (1 : groupe de 1024 avec sous-groupe 160bits, 2 : groupe de 2048 avec sous-groupe 224bits ,3 : groupe de 2048 avec sous-groupe 256bits).

Options de génération de paramètres EC

ec_paramgen_curve:curve La courbe EC à utiliser

Options de paramètres et de génération de clé GOST2001

paramset:name Spécifie le paramètre GOST R 34.10-2001 en accord avec la RFC 4357. Les paramètres suivants sont supportés

paramset   OID               Usage
A 1.2.643.2.2.35.1 Signature
B 1.2.643.2.2.35.2 Signature
C 1.2.643.2.2.35.3 Signature
XA 1.2.643.2.2.36.0 Key exchange
XB 1.2.643.2.2.36.1 Key exchange
test 1.2.643.2.2.35.0 Test purposes

Exemples

Générer une clé privée RSA en utilisant les paramètres par défaut:
openssl genpkey -algorithm RSA -out key.pem
Chiffrer une clé privée en utilisant AES128 et la passphrase 'hello':
openssl genpkey -algorithm RSA -out key.pem -aes-128-cbc -pass pass:hello
Générer une clé RSA 2048bits et un exposant publique 3:
openssl genpkey -algorithm RSA -out key.pem -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:3
Générer des paramètres DSA 1024bits:
openssl genpkey -genparam -algorithm DSA -out dsap.pem -pkeyopt dsa_paramgen_bits:1024
Générer une clé DSA depuis des paramètres:
openssl genpkey -paramfile dsap.pem -out dsakey.pem
Générer des paramètres DH 1024bits:
openssl genpkey -genparam -algorithm DH -out dhp.pem -pkeyopt dh_paramgen_prime_len:1024
sortir des paramètres DH RFC5114 type 2:
openssl genpkey -genparam -algorithm DH -out dhp.pem -pkeyopt dh_rfc5114:2
Générer une clé DH depuis des paramètres:
openssl genpkey -paramfile dhp.pem -out dhkey.pem
^
07 mars 2012

htmlpdflatexmanmd




OpenSSL - gendsa

OpenSSL - gendsa

Génère des clés privées DSA à partir de fichiers de paramètres DSA

OPTIONS

-des|-des3|-idea Algorithme à utiliser pour chiffrer la clé privée.
-rand file(s) Fichiers utilisés pour le génération de nombre aléatoire
-engine id gendsa va tenter d’obtenir un référence fonctionnelle pour le moteur spécifié.
^
07 mars 2012

htmlpdflatexmanmd




PKCS#3

PKCS#3

Diffie-Hellman Key-Agreement Standard

   L’échange de clé Diffie-Hellman est une méthode par laquelle 2 personnes peuvent se mettre d’accord sur un nombre qu’ils peuvent utiliser pour chiffrer des données.

Exemple

1. 2 utilisateurs A et B choisisent un nombre premier p et une base g: p=23, et g=3
2. L’utilisateur A choisi un nombre secret a=6
3. L’utilisateur A envoie la valeur A = ga [mod p] = 36 [23] = 16
4. L’utilisateur B choisit un nombre secret b=15
5. L’utilisateur B envoie la valeur B = gb [mod p] = 315 [23] = 12
6. L’utilisateur A calcule la clé secrète K : (gb [mod p])a [mod p] = 126 [23] = 9
7. L’utilisateur B calcule la clé secrète K : (ga [mod p])b [mod p] = 1615 [23] = 9

   Il est nécessaire d’utiliser des nombres suffisamment grand pour éviter une attaque par recherche exhaustive.

  Diffie-Hellman est vulnérable aux attaques MITM. Pour parer à cette attaque, on peut signer les échanges avec une paire de clés asymétriques.
^
06 mars 2012

htmlpdflatexmanmd




OpenSSL - ErrStr

OpenSSL - ErrStr

Utilitaire pour afficher la description d'un code d'erreur

Exemple

le code d’erreur suivant:
27594:error:2006D080:lib(32):func(109):reason(128):bss_file.c:107:
avec openssl errstr 2006D080 produit:
error:2006D080:BIO routines:BIO_new_file:no such file
^
06 mars 2012

htmlpdflatexmanmd




OpenSSL - enc

OpenSSL - enc

Routines de chiffrements symétriques

   Permet de chiffrer ou déchiffrer des données en utilisant divers block ou flux de chiffrement en utilisant des clés basé sur mot de passe ou fournis explicitement. L’encodage/décodage en base 64 peut également être effectué en plus du chiffrement/déchiffrement.

OPTIONS

-in filename Fichier d’entrée
-out filename Fichier de sortie
-pass arg Source du mot de passe
-salt Utilise un Salt dans les routines de dérivation de clé pendant le chiffrement (défaut). Généré aléatoirement avec l’option -S
-nosalt N’utilise pas de Salt. Ne doit être utilisé que pour des tests un pour compatibilité avec des anciennes versions d’OpenSSL.
-S salt Le Salt à utiliser au format hexa
-e  Chiffre la donnée en entrée (défaut)
-d Déchiffre la donnée en entrée
-a Traite les données en base 64.
-base64 Idem à -a
-A si -a, le traitement base64 se fait sur une ligne
-k password Le mot de passe à dériver de la clé. Pour la compatibilité avec d’anciennes versions d’OpenSSL. Remplacé par -pass
-kfile filename Le mot de passe à dériver de la clé depuis ce fichier. Pour la compatibilité avec d’anciennes versions d’OpenSSL. Remplacé par -pass
-K key La clé à utiliser en hexa. IV doit être spécifié avec -iv. Si la clé et le mot de passe sont spécifiés, IV est généré depuis le mot de passe.
-iv IV L’IV à utiliser en hexa
-p Afficher la clé et l’IV utilisé
-P Idem à -p mais quitte immédiatement
-bufsize number Définis la taille du tampon pour les E/S
-nopad Désactive le padding de block standard
-debug Débug les BIO utilisé pour les E/S
-z Compresse ou décompresse en texte clair en utilisant zlib avant le chiffrement ou après le déchiffrement.
-none Utilise le chiffrement NULL

Notes

   Les moteurs qui fournissent de nouveaux algorithmes de chiffrement (tel que ccgost qui fournis l’algorithme gost89) devraient être configurés dans le fichier de configuration. Les moteurs spécifiés sur la ligne de commande peuvent seulement être utilisé avec des implémentations de chiffrement assisté par hardware supportés par OpenSSL core.

Chiffrements supportés

Noter que certains chiffrements peuvent être désactivés à la compilation.
base64 Base 64
    
bf-cbc Blowfish in CBC mode
bf Alias for bf-cbc
bf-cfb Blowfish in CFB mode
bf-ecb Blowfish in ECB mode
bf-ofb Blowfish in OFB mode
    
cast-cbc CAST in CBC mode
cast Alias for cast-cbc
cast5-cbc CAST5 in CBC mode
cast5-cfb CAST5 in CFB mode
cast5-ecb CAST5 in ECB mode
cast5-ofb CAST5 in OFB mode
    
des-cbc DES in CBC mode
des Alias for des-cbc
des-cfb DES in CBC mode
des-ofb DES in OFB mode
des-ecb DES in ECB mode
    
des-ede-cbc Two key triple DES EDE in CBC mode
des-ede Two key triple DES EDE in ECB mode
des-ede-cfb Two key triple DES EDE in CFB mode
des-ede-ofb Two key triple DES EDE in OFB mode
    
des-ede3-cbc Three key triple DES EDE in CBC mode
des-ede3 Three key triple DES EDE in ECB mode
des3 Alias for des-ede3-cbc
des-ede3-cfb Three key triple DES EDE CFB mode
des-ede3-ofb Three key triple DES EDE in OFB mode
    
desx DESX algorithm.
    
gost89 GOST 28147-89 in CFB mode (provided by ccgost engine)
gost89-cnt `GOST 28147-89 in CNT mode (provided by ccgost engine)
    
idea-cbc IDEA algorithm in CBC mode
idea same as idea-cbc
idea-cfb IDEA in CFB mode
idea-ecb IDEA in ECB mode
idea-ofb IDEA in OFB mode
    
rc2-cbc 128 bit RC2 in CBC mode
rc2 Alias for rc2-cbc
rc2-cfb 128 bit RC2 in CFB mode
rc2-ecb 128 bit RC2 in ECB mode
rc2-ofb 128 bit RC2 in OFB mode
rc2-64-cbc 64 bit RC2 in CBC mode
rc2-40-cbc 40 bit RC2 in CBC mode
    
rc4 128 bit RC4
rc4-64 64 bit RC4
rc4-40 40 bit RC4
    
rc5-cbc RC5 cipher in CBC mode
rc5 Alias for rc5-cbc
rc5-cfb RC5 cipher in CFB mode
rc5-ecb RC5 cipher in ECB mode
rc5-ofb RC5 cipher in OFB mode
    
aes-[128|192|256]-cbc 128/192/256 bit AES in CBC mode
aes-[128|192|256] Alias for aes-[128|192|256]-cbc
aes-[128|192|256]-cfb 128/192/256 bit AES in 128 bit CFB mode
aes-[128|192|256]-cfb1 128/192/256 bit AES in 1 bit CFB mode
aes-[128|192|256]-cfb8 128/192/256 bit AES in 8 bit CFB mode
aes-[128|192|256]-ecb 128/192/256 bit AES in ECB mode
aes-[128|192|256]-ofb 128/192/256 bit AES in OFB mode

Exemples

Encoder un fichier binaire en base 64
openssl base64 -in file.bin -out file.b64
Décoder le même fichier
openssl base64 -f -in file.b64 -out file.bin
Chiffrer un fichier avec 3DES en mode CBC
openssl des3 -salt -in file.txt -out file.des3
Déchiffrer un fichier en fournissant le mot de passe
openssl des3 -d -salt -in file.des3 -out file.txt -k mypassword
Chiffrer un fichier puis l’encoder en base 64 avec blowfish en mode CBC
openssl bf -a -salt -in file.txt -out file.bf
Décode un fichier base 64 et le déchiffrer
openssl bf -d -salt -a -in file.bf -out file.txt
Déchiffre des données en utilisant une clé RC4 40 Bits
openssl rc4-40 -in file.rc4 -out file.txt -K 0102030405
^
05 mars 2012

htmlpdflatexmanmd




PKCS#1

PKCS#1

RSA Cryptography Standard

   RSA (Rivest Shamir Adleman) est un algorithme asymétrique.

Génération des clés

Pour calculer une paire de clé privée/publique RSA, l’algorithme s’appuie sur 2 nombres premiers, p et q. Une fois ces 2 nombres déterminés, on obtient 2 nombres:
n = p x q
z = ( p - 1 ) x ( q - 1 )
On calcul ensuite l’indicatrice d’Euler e de z (inférieur à z), qui doit nécessairement être premier avec z:
d = e-1 mod((p - 1)(q - 1))

   le couple (n,e) est la clé publique, le couple (n,d) est la clé privée. Une fois e, d et n caclulés, il faut détruire p, q, et z pour des raisons évidentes de sécurité. La clé privée est généralement chiffrée avec un algorithme symmetrique pour la conserver de façon sûre.

Chiffrement et déchiffrement

Pour chiffrer un nombre, il faut le mettre à la puissance de e. Le reste modulo n représente le nombre chiffré:
c = te mod n
pour déchiffrer, on utilise la même opération, mais à la puissance d:
t = cd mod n
exemple simple utilisant de petits nombres:
pour chiffrer le texte suivant: "Hello World", on choisis p = 37 et q = 43.
on déduit :
n = 37 x 43 = 1591
z = 36 x 42 = 1512
on choisit e = 19, premier avec 1512. L’inverse de 19 modulo 1512 est d = 955.
pour chiffrer chaque caractère:
Hello World = 72 101 108 108 111 32 87 111 114 108 100


H___e___l___l___o___ ___W___o___r___l___d
72__101_108_108_111_32__87__111_114_108_100

on caclule chaque caractère avec:
7219 [1591] = 335 ; 10119 [1591] = 1174 ; etc…


72____101____108____108____111___32____87____111___114___108____100
335___1174___1329___1329___703___930___431___703___632___1329___396

On déchiffre avec:
335955 [1591] = 72 ; 1174955 [1591] = 101 ; etc…

Notes

   Plusieurs techniques permettent de déchiffrer ou déduire la clé privée:

- si p et q sont trop petits, un brute force ne prend que très peu de temps à déterminer la clé privée. il faut donc choisir des valeures très grandes (minimum 1024 bits)
- Le chiffrement par caractère comme dans l’exemple ci-dessus, peut être cassé en déterminant la fréquence des octets (analyse fréquentielle). Il est préférable de chiffrer un bloc d’octets.
- n ne doit pas être inférieur au bloc d’octets à chiffrer, sinon plusieurs valeurs initiales peuvent donner le même nombre chiffré, donnant des erreurs au déchiffrement.
- on peut déterminer la taille d’une clé privée en déterminant le temps que prend le déchiffrement d’un message. Toute la sécurité RSA repose sur le temp nécessaire pour calculer p et q à partir de n.
^
01 mars 2012

htmlpdflatexmanmd




OpenSSL - dsaparam

OpenSSL - dsaparam

Manipulation et génération de paramètres DSA

OPTIONS

-inform DER|PEM Format du fichier d’entrée. DER avec une clé privée utilise une forme encodée ASN1 DER d’une séquence ASN.1 consistant de valeurs de version (0 actuellement), p, q, g, les clés publique et privée en tant qu’entier ASN.1.
-outform DER|PEM Format de la sortie.
-in filename Fichier contenant les paramètres à lire
-out filename fichier de sortie où écrire les paramètres
-text Affiche les paramètres DSA de manière compréhensible
-noout n’affiche pas la version encodée des paramètres
-C Convertir les paramètres en code C.
-genkey Génère un DSA en utilisant soit les paramètres spécifiés, soit les paramètres générés.
-rand file(s) Le(s) fichier(s) utilisé par le générateur de nombre aléatoire.
numbits Taille en bits des paramètres générés.
-engine id dsaparam va tenter d’obtenir une référence fonctionnelle au moteur spécifié.

Notes

Les paramètres DSA PEM utilisent:
-----BEGIN DSA PARAMETERS-----
-----END DSA PARAMETERS-----

^
01 mars 2012

htmlpdflatexmanmd




OpenSSL - dsa

OpenSSL - dsa

Traitement des clés dsa. Utilise le format compatible SSLeay pour le chiffrement des clés privées, les applications devraient utiliser pkcs8, plus sécure.

OPTIONS

-inform DER|PEM Format du fichier d’entrée. DER avec une clé privée utilise une forme encodée ASN1 DER d’une séquence ASN.1 consistant de valeurs de version (0 actuellement), p, q, g, les clés publique et privée en tant qu’entier ASN.1.
-outform DER|PEM Format de la sortie.
-in filename Fichier contenant la clé à lire
-passing arg Source du mot de passe du fichier d’entrée.
-out filename fichier de sortie où écrire une clé.
-passout arg source du mot de passe du fichier de sortie
-des|des3|-idea Algorithme utilisé pour chiffrer la clé privée.
-text Affiche la clé privée, publique et les paramètres
-noout n’affiche pas la sortie encodée de la clé
-modulus Affiche la valeur de la composante clé publique de la clé
-pubin Par défaut, la clé privée est lue depuis le fichier d’entrée. Cette option lit une clé publique à la place.
-pubout Par défaut, une clé privée est sortie. Avec cette option, une clé publique est sortie.
-engine id dsa va tenter d’obtenir une référence fonctionnelle au moteur spécifié.

Notes

Le format de clé privée PEM utilise:
-----BEGIN DSA PRIVATE KEY-----
-----END DSA PRIVATE KEY-----
Le format de clé publique PEM utilise:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

Exemples

Supprimer une passphrase d’une clé privée DSA:
openssl dsa -in key.pem -out keyout.pem
Chiffrer une clé privée en utilisant 3DES:
openssl dsa -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl dsa -in key.pem -outform DER -out keyout.der
Afficher les composants d’une clé privée sur stdout:
openssl dsa -in key.pem -text -noout
Affiche la partie publique d’une clé privée:
openssl dsa -in key.pem -pubout -out pubkey.pem
^
29 février 2012

htmlpdflatexmanmd




OpenSSL - dgst

OpenSSL - dgst

Afficher le message digest en hexa d’un ou plusieurs fichiers. Peut également être utilisé pour les signatures numérique et la vérification.

OPTIONS

-c Affiche le digest en 2 groupes de chiffre séparés par un ’:’
-d Affiche des informations de debuggage BIO
-hex Affiche le digests en tant que dump hexa. Défaut pour les digest normaux en opposé aux signatures numériques.
-binary Affiche le digest au format binaire
-out filename Nom du fichier de sortie
-sign filename Signe numérique le digest en utilisant la clé privée dans le fichier spécifié.
-keyform PEM|ENGINE Spécifie le format de la clé pour signer le digest.
-engine id Utilise l’id pour les opérations (incluant le stockage de la clé privée). Ce moteur n’est pas utilisé comme source pour les algorithmes digest, à moins qu’il soit également spécifié dans le fichier de configuration
-sigopt nm:v Passer des options à l’algorithme de signature durant les opérations de signature et de vérification.
-passing arg Mot de passe de la source du mot de passe.
-verify filename Vérifie la signature en utilisant la clé publique dans le fichier spécifié.
-prverify filename Vérifie la signature en utilisant la clé privée dans le fichier spécifié.
-signature filename La signature à vérifier
-hmac key Créé un MAC hashé en utilisant la clé spécifiée.
-mac alg Créer un MAC en utilisant l’algorithme spécifié.
-macopt nm:v Passer des options à l’algorithme MAC
-rand file(s) Spécifier le(s) fichier(s) à utiliser pour le générateur de nombre aléatoire, ou un socket EGD.
file... Fichier en entrée pour les opération de digest.
^
28 février 2012

htmlpdflatexmanmd




OpenSSL - crl2pkcs7

OpenSSL - crl2pkcs7

Utilitaire pour créer une structure PKCS #7 depuis une CRL et des certificats

OPTIONS

-infor DER|PEM Format de la CRL d’entrée.
-outform DER|PEM Spécifie le format de la structure PKCS #7 en sortie
-in filename Spécifier la CRL d’entrée
-out filename Spécifier le fichier de sortie
-certfile filename Spécifie un fichier contenant un ou plusieurs certificats au format PEM. Tous ces certificats seront ajoutés à la structure PKCS #7. Peut-être spécifié plusieurs fois.
-nocrl N’inclue pas de CRL dans le fichier de sortie.

Exemples

Créer une structure PKCS #7 depuis un certificat et une CRL
openssl crl2pkcs7 -in crl.pem -certfile cert.pem -out p7.pem
Créer une structure PKCS #7 au format DES sans CRL et depuis différent certificats
openssl crl2pkcs7 -nocrl -certfile newcert.pem -certfile demoCA/cacert.pem -outform DER -out p7.der
^
28 février 2012

htmlpdflatexmanmd




OpenSSL - crl

OpenSSL - crl

Utilitaire de traitement des fichiers CRL

OPTIONS

-infor DER|PEM Format du fichier d’entrée.
-outform DER|PEM Spécifie le format de la sortie
-in filename Spécifier le fichier d’entrée
-out filename Spécifier le fichier de sortie
-text Affiche la CRL au format texte
-noout Ne sort pas la version encodée de la CRL
-hash Sort un hash de nom de l’émetteur. Peut être utilisé pour rechercher les CRL dans un répertoire par émetteur
-issuer Affiche le nom de l’émetteur
-lastupdate affiche le champ lastUpdate
-nextupdate Affiche le champ nextUpdate
-CAfile file Vérifie l signature d’un CRL avec le certificat spécifié
-CApath dir Vérifie la signature d’une CRL en recherchant le certificat dabs DIR. Ce répertoire doit être un répertoire de certificat standard: un hash du nom du sujet est lié à chaque certificat (x509 -hash)

Notes

Le format PEM utilise les en-tête et pieds de page suivante:
-----BEGIN X509 CRL-----
-----END X509 CRL-----

Exemples

Convertir une CRL PEM en DER
openssl crl -in crl.pem -outform DER -out crl.der
Afficher un certificat DER en texte clair
openssl crl -in crl.der -text noout
^
28 février 2012

htmlpdflatexmanmd




OpenSSL - cms

OpenSSL - cms

Utilitaire CMS (Cryptographic Message Syntax)

OPTIONS

-encrypt Chiffre un mail avec le certificat donné. Le fichier d’entrée est le message à chiffrer. Le fichier de sortie est le mail chiffré au format MIME. Le type de CMS actuel est EnvelopedData.
-decrypt Déchiffre un mail en utilisant le certificat et la clé privée spécifiée. Le fichier d’entrée est un mail au format MIME. le fichier de sortie est le mail déchiffré.
-sign Signe un mail en utilisant le certificat et la clé privée spécifiée. Le fichier d’entrée est le message à signer, le fichier de sortie est le message signé au format MIME.
-verify Vérifie le mail signé. L’entrée est le mail signé, le fichier de sortie et la sortie est la donnée signée.
-cmsout Prend un message en entrée et écrit une structure CMS encodée PEM
-resign Re-signe un message: prend un message existant et un ou plusieurs nouveaux signataires.
-data_create Créé un type CMS Data
-data_out Type une donnée et sort le contenu
-digest_create Crée un type CMS DigestedData
-digestVerify Vérifie un CMS DigestedData et sort le contenu
-compress Créé un CMS CompressedData. OpenSSL doit être compilé avec zlib pour que cette option fonctionne.
-uncompress Décompresse un CMS CompressedData.
-EncryptedData_encrypt Chiffre le contenu en utilisant une clé symétrique et un algorithme CMS EncryptedData et sort le contenu.
-sign_receipt Génère et sort un reçu signé pour le message spécifié. Le message d’entrée doit contenir une requête de reçu signée.
-verify_receipt receipt Vérifie un reçu signé dans le fichier spécifié. Le message d’entrée doit contenir une requête de reçu.
-in filename Fichier d’entrée
-inform SMIME|PEM|DER Format du fichier d’entrée, à utiliser avec -receipt_verify
-out filename Fichier de sortie
-outform SMIME|PEM|DER Spécifie le format du fichier de sortie (défaut SMIME)
-stream -indef -stream et indef sont équivalent et permettent le streaming I/O pour les opérations d’encodage. Cela permet un traitement en une passe de donnée sans nécessiter de maintenir tout le contenu en mémoire.
-noindef Désactive le streaming I/O.
-content filename spécifie un fichier contenant le contenu détaché. Seulement utile avec -verify et si la structure CMS utilise une signature détachée du contenu.
-text Ajoute des en-têtes text/plain au message fournis.
-noout Ne sort par la structure CMS parsée. Utile avec -print
-print pour -cmsout, affiche tous les champs de la structure CMS.
-CAfile file Un fichier contenant les certificats trustés. Utile avec -verify
-CApath dir Un répertoire contenant les certificats CA. Utile avec -verify
-md digest Algorithme digest à utiliser pour signer ou re-signer.
-[ciphers] L’algorithme de chiffrement à utiliser. Voir enc pour la liste des chiffrements supportés. (Défaut : 3DES)
-nointern En vérifiant un message, les certificats inclus dans le message sont utilisé pour vérifier la signature. Avec cette option, seul les certificats spécifiés avec -certfile sont utilisés.
-no_signer_cert_verify Ne vérifie pas le certificat du message signé.
-nocerts En signant un message, le certificat du signataire est inclus. Cette option l’empêche.
-noattr Normalement quand un message est signé, des attributs sont inclus dont la date de signature et les algorithmes symétriques supportés. Cette option ne les inclus pas.
-nosmimecap Exclus la liste des algorithmes supportés pour les attributs signés. D’autres options telles que la date de signature et le type de contenu sont inclus.
-binary Normalement, le message d’entrée est convertit au format canonique qui utilise CR et LF comme fin de ligne comme requis par la spécification S/MIME. Avec cette option, aucune conversion n’est faite.
-nodetach En signant un message en utilisant une signature opaque la forme est plus résistante aux translations par les relais, mais ne peut pas être lus par les agents qui ne supportent pas S/MIME. Sans cette option, la signature en texte clair est utilisée.
-certfile file Permet de spécifier des certificats additionnels, qui seront inclus dans le message. Ces certificats devraient être au format PEM.
-certsout file Tout certificat contenus dans le message sont écris dans le fichier spécifié
-signer file Un certificat de signature. Peut-être spécifiée plusieurs fois.
-recip file Le certificat pour le déchiffrement d’un message. Ce certificat doit matcher un des destinataires du message.
-keyid Utilise le subject key identifier pour identifier les certificats au lieu du nom et du numéro de série. Le certificat doit inclure une extension subject key identifier.
-receipt_request_all -receipt_request_first Pour que l’option -sign inclue une requête de reçu. Indique que les requêtes devraient être fournies par tous les destinataires ou le premier tiers des destinataires.
-receipt_request_to_emailaddress Ajoute une adresse mail où les reçus signés devraient être envoyés. Doit être fournis si un reçu signé est demandé.
-receipt_request_print Pour -verify, affiche le contenu des demandes de reçus signés.
-secretkey key Spécifie la clé symétrique à utiliser. La clé doit être fournie en hexa.
-secretkeyid id L’identifiant de clé pour la clé symétrique fournies pour le type KEKRecipentInfo.
-econtent_type type Définis le type de contenu encapsulé. Peut-être un OID soit en texte soit sous forme numérique.
-inkey file La clé privée à utiliser pour signer ou déchiffrer.
-passin arg Le mot de passe pour la clé privée.
-rand file(s) Un ou plusieurs fichiers contenant des données aléatoires utilisée pour le générateur de nombre aléatoires, ou un socket EGD.
cert.pem... Un ou plusieurs certificats de destinataire de message à utiliser pour chiffrer un message
-to, -from -subject Les en-têtes du mail.
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all, -policy_check, -extended_crl, -x509_strict, -policy -check_ss_sig Diverse options de validation de la chaîne de certificat. Voir verify.

Codes de sortie

0 succès de l’opération
1 Erreur en parsant les options
2 Un des fichiers d’entrée ne peut pas être lu
3 Une erreur s’est produite en créant le fichier CMS ou en lisnt le message MIME
4 Erreur durant la vérification ou le déchiffrement du message
5 Le message a été vérifié correctement mais une erreur s’est produite en écrivant les certificats des signeurs.

Compatibilité avec le format PKCS #7

   l’utilitaire smime peut seulement traiter l’ancien format pkcs #7. L’utilitaire cms supporte le format CMS.

        L’utilisation de -keyid avec -sign ou -encrypt
        L’option -outform PEM
        L’option -compress
        L’option -secretkey avec -encrypt
        -EncryptedData_create et -data_create ne peuvent être traitée par les commandes smime.

Exemples

Créer un message signé en texte clair:
openssl cms -sign -in message.txt -text -out mail.msg -signer mycert.pem
Créer un message signé opaque:
openssl cms -sign -in message.txt -text -out mail.msg -nodetach -signer mycert.pem
Créer un message signé, incluant des certificats additionnels et lire la clé privée depuis un autre fichier:
openssl cms -sign -in in.txt -text -out mail.msg -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
Créer un message signé avec 2 signataires, utiliser un identifier de clé:
openssl cms -sign -in message.txt -text -out mail.msg -signer mycert.pem -signer othercert.pem -keyid
Envoyer un message signé sous Unix directement à sendmail, incluant les en-têtes:
openssl cms -sign -in in.txt -text -signer mycert.pem -from steve@openssl.org -to someone@somewhere -subject "Signed message" | sendmail someone@somewhere
Vérifier un message et extraire le certificat du signataire en cas de réussite:
openssl cms -verify -in mail.msg -signer user.pem -out signedtext.txt
Envoyer un mail chiffré avec 3DES:
openssl cms -encrypt -in in.txt -from steve@openssl.org -to someone@somewhere -subject "Encrypted message" -des3 user.pem -out mail.msg
Signer et chiffrer un mail:
openssl cms -sign -in ml.txt -signer my.pem -text | openssl cms -encrypt -out mail.msg -from steve@openssl.org -to someone@somewhere -subject "Signed and Encrypted message" -des3 user.pem
Déchiffrer un mail:
openssl cms -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
La sortie de la Netscape est une structure PKCS #7 avec le format de signature détachée. Pour vérifier la signature, mettre la structure codé en base 64 entre:
-----BEGIN PKCS7-----
-----END PKCS7-----
Et utiliser la commande:
openssl cms -verify -inform PEM -in signature.pem -content content.txt
Alternativement vous pouvez décoder la signature et utiliser:
openssl cms -verify -inform DER -in signature.der -content content.txt
Créer et chiffrer un message en utilisant Camellia 128 bits:
openssl cms -encrypt -in plain.txt -camellia128 -out mail.msg cert.pem
Ajouter un signataire à un message existant:
openssl cms -resign -in mail.msg -signer newsign.pem -out mail2.msg
^
27 février 2012

htmlpdflatexmanmd




OpenSSL - ciphers

OpenSSL - ciphers

Convertis les listes de chiffrement en liste de préférence ordonnées. Peut être utilisé comme outil de test pour déterminer la liste de chiffrement.

OPTIONS

-v mode verbeux
-V idem à -v mais inclus les codes des suites de chiffrements en hexa.
-ssl3 Uniquement les chiffrements SSL v3
-ssl2 Uniquement les chiffrements SSL v2
-tls1 Uniquement les chiffrements TLS v1
cipherlist Une liste de chiffrement à convertir en une liste de préférence de chiffrement.

Format de liste de chiffrement

   Une liste consiste en une ou plusieurs chaîne de chiffrement séparés par des ':'. Une liste peut être une suite de chiffrements simple comme RC4-SHA. Elle peut représenter un certain algorithme. Par exemple SHA1 représente toutes les suites utilisant cet algorithme, et SSLv3 représente tous les algorithmes SSLv3.

  Les listes de suite de chiffrement peuvent être combinées en une simple chaîne en utilisant le '+' (est un ET logique), un '!' pour les chiffrements à supprimer de la liste, un '-' pour ceux à supprimer, mais qui peuvent être rajoutés ultérieurement. En plus, la chaine de chiffrement @STRENGTH peut être utilisée pour trier la liste de chiffrement courante dans l'ordre de longueur de clé de chiffrement.

Chaînes de chiffrement

   Liste des chaînes de chiffrement permises et leur signification:

DEFAULT Liste de chiffrement par défaut. Déterminé à la compilation. (pour openssl v1.0.0 est normalement à ALL:!aNULL:!eNULL). Doit être la première chaîne de chiffrement spécifiée.
COMPLEMENTOFDEFAULT Les chiffrement inclus dans ALL, mais non actifs par défaut.
ALL Toutes les suites de chiffrement sauf eNULL
COMPLEMENTOFALL Les suites de chiffrement non activés par ALL, actuellement eNULL.
HIGH Suites de chiffrements élevés. Actuellement, signifie toutes les longueurs de clé supérieurs à 128 bits, et certains chiffrements avec clé 128 bits.
MEDIUM Suites de chiffrements moyens. Actuellement, signifie toutes les longueurs de clé à 128 bits.
LOW Suites de chiffrements faibles. Actuellement, signifie toutes les longueurs de clé supérieurs à 56 ou 64 bits mais exclus les suites de chiffrement d’export
EXP, EXPORT Algorithmes de chiffrement d’export, incluant les clés à 56 et 64 bits.
EXPORT40 Algorithmes de chiffrement d’export de 40 bits
EXPORT56 Algorithmes de chiffrement d’export de 56 bits
eNULL, NULL Chiffrement qui n’offrent pas de cryptage.
aNULL Suites de chiffrement n’offrant pas d’authentification. Actuellement, les algorithmes DH anonymes. Vulnérables aux attaques MITM.
kRSA, RSA Suites de chiffrement utilisant les échanges de clé RSA
kEDH Suites de chiffrement utilisant les agréments de clé DH éphémères
kDHr, kDHd Suites de chiffrement utilisant les agréments de clé DH et les certificats DH signés par CA avec des clé RSA et DSS, respectivement.
aRSA Suites de chiffrement utilisant l’authentification RSA.
aDSS, DSS Suites de chiffrement utilisant l’authentification DSS
aDH Suites de chiffrement utilisant effectivement l’authentification DH.
kFZA, aFZA, eFZA, FZA Suites de chiffrement utilisant l’échange de clé, l’authentification et/ou le chiffrement FORTEZZA
TLSv1, SSLv3, SSLv2 Suites de chiffrement utilisant respectivement TLS v1, SSL v3 et SSL v2.
DH Suites de chiffrement utilisant DH, incluant DH anonyme.
ADH Suites de chiffrement utilisant DH anonyme.
AES Suites de chiffrement utilisant AES
CAMELLIA Suites de chiffrement utilisant Camellia
3DES Suites de chiffrement utilisant 3DES
DES Suites de chiffrement utilisant DES
RC4 Suites de chiffrement utilisant RC4
RC2 Suites de chiffrement utilisant RC2
IDEA Suites de chiffrement utilisant IDEA
SEED Suites de chiffrement utilisant SEED
MD5 Suites de chiffrement utilisant MD5
SHA1, SHA Suites de chiffrement utilisant SHA1
aGOST Suites de chiffrement utilisant GOST R 34.10 (soit 2001 soit 94) pour l’authentification
aGOST01 Suites de chiffrement utilisant l’authentification GOST R 34.10-2001
aGOST94 Suites de chiffrement utilisant L’authentification GOST R 34.10-94
kGOST Suites de chiffrement utilisant l’échange de clé VKO 34.10 (RFC 4357)
GOST94 Suites de chiffrement utilisant HMAC basé sur GOST R 34.10-94
GOST89MAC Suites de chiffrement utilisant GOST 28147-89 MAC

Noms des suites de chiffrement

   Les listes suivantes donnent les noms des suites de chiffrement SSL ou TLS et leur équivalent OpenSSL.

Suites de chiffrement SSL v3.0


SSL_RSA_WITH_NULL_MD5 NULL-MD5
SSL_RSA_WITH_NULL_SHA NULL-SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
SSL_RSA_WITH_RC4_128_MD5 RC4-MD5
SSL_RSA_WITH_RC4_128_SHA RC4-SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
SSL_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
    
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA Not implemented.
SSL_DH_DSS_WITH_DES_CBC_SHA Not implemented.
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA Not implemented.
SSL_DH_RSA_WITH_DES_CBC_SHA Not implemented.
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA Not implemented.
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA
    
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5
SSL_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA
SSL_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA
    
SSL_FORTEZZA_KEA_WITH_NULL_SHA Not implemented.
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA Not implemented.
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA Not implemented.

Suites de chiffrement TLS v1.0


TLS_RSA_WITH_NULL_MD5 NULL-MD5
TLS_RSA_WITH_NULL_SHA NULL-SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
TLS_RSA_WITH_RC4_128_MD5 RC4-MD5
TLS_RSA_WITH_RC4_128_SHA RC4-SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
TLS_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
TLS_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
    
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_DES_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_DES_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA Not implemented.
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA
    
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5
TLS_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA
TLS_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA

Suites de chiffrement AES de la rfc3268, étendant TLS v1.0


TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
    
TLS_DH_DSS_WITH_AES_128_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_AES_256_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_AES_128_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_AES_256_CBC_SHA Not implemented.
    
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE-DSS-AES128-SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-DSS-AES256-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA
    
TLS_DH_anon_WITH_AES_128_CBC_SHA ADH-AES128-SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA ADH-AES256-SHA

Suites de chiffrement Camellia de la rfc4132, étendant TLS v1.0


TLS_RSA_WITH_CAMELLIA_128_CBC_SHA CAMELLIA128-SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA CAMELLIA256-SHA
    
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA Not implemented.
    
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE-DSS-CAMELLIA128-SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE-DSS-CAMELLIA256-SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE-RSA-CAMELLIA128-SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE-RSA-CAMELLIA256-SHA
    
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA ADH-CAMELLIA128-SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA ADH-CAMELLIA256-SHA

Suites de chiffrement SEED de la rfc4162, étendant TLS v1.0


TLS_RSA_WITH_SEED_CBC_SHA SEED-SHA
    
TLS_DH_DSS_WITH_SEED_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_SEED_CBC_SHA Not implemented.
    
TLS_DHE_DSS_WITH_SEED_CBC_SHA DHE-DSS-SEED-SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA DHE-RSA-SEED-SHA
    
TLS_DH_anon_WITH_SEED_CBC_SHA ADH-SEED-SHA

Suites de chiffrement GOST du draft-chudov-cryptopro-cptls, étendant TLS v1.0

Note: Ces chiffrements nécessitent un moteur qui inclut les algorithmes cryptographique GOST tel que le moteur ccgost, inclus dans OpenSSL.
TLS_GOSTR341094_WITH_28147_CNT_IMIT GOST94-GOST89-GOST89
TLS_GOSTR341001_WITH_28147_CNT_IMIT GOST2001-GOST89-GOST89
TLS_GOSTR341094_WITH_NULL_GOSTR3411 GOST94-NULL-GOST94
TLS_GOSTR341001_WITH_NULL_GOSTR3411 GOST2001-NULL-GOST94

Exports additionnels 1024 et autres suites de chiffrement

Note: Ces chiffrements peuvent aussi être utilisé dans SSL v3
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DES-CBC-SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA EXP1024-RC4-SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DHE-DSS-DES-CBC-SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA EXP1024-DHE-DSS-RC4-SHA
TLS_DHE_DSS_WITH_RC4_128_SHA DHE-DSS-RC4-SHA

Suites de chiffrement SSL v2.0


SSL_CK_RC4_128_WITH_MD5 RC4-MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5 EXP-RC4-MD5
SSL_CK_RC2_128_CBC_WITH_MD5 RC2-MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 EXP-RC2-MD5
SSL_CK_IDEA_128_CBC_WITH_MD5 IDEA-CBC-MD5
SSL_CK_DES_64_CBC_WITH_MD5 DES-CBC-MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 DES-CBC3-MD5

Exemples

Lister tous les chiffrements OpenSSL incluant les chiffrements NULL:
openssl ciphers -v ’ALL:eNULL’
Inclure tous les chiffrements excepté NULL et DH anonyme, et trier par force:
openssl ciphers -v ’ALL : !ADH :@STRENGTH’
Inclure seulement les chiffrements 3DES puis placer RSA en dernier:
openssl ciphers -v ’3DES :+RSA’
Inclure tous les chiffrements RC4 mais laisser ceux sans authentification:
openssl ciphers -v ’RC4 : !COMPLEMENTOFDEFAULT’
Inclure tous les chiffrements avec authentification RSA mais laisser les chiffrements sans cryptage:
openssl ciphers -v ’RSA : !COMPLEMENTOFALL’
^
26 février 2012

htmlpdflatexmanmd




OpenSSL - ca

OpenSSL - ca

Application CA minimaliste. Peut être utilisé pour signer des requêtes de certificats et générer des CRL. Maintient également une base des certificats délivrés et leur status.

Options CA

-config filename Spécifie le fichier de configuration à utiliser
-name section Spécifie la section du fichier de configuration à utiliser
-in filename Fichier source contenant une requête de certificat à signer
-ss_cert filename un certificat auto-signé à signer par la CA
-spkac filename Un fichier contenant une clé publique signée Netscape, un challenge et des valeurs de champs assitionnels à signer par la CA.
-infiles Si présent doit être la dernière option. Tous les arguments qui suivent sont traités comme des noms de fichier contenant des requêtes.
-out filename Fichier de sortie. (défaut : stdout)
-outdir directory Répertoire où placer les certificats de sortie. Le certificat sera nommé avec un numéro hexa et l’extension pem.
-cert Fichier du certificat CA
-keyfile filename La clé privée à utiliser pour signer la requête
-key password Le mot de passe à utiliser pour chiffrer la clé privée
-selfsign indique que les certificats délivrés doivent être signés avec la clé qui a servit à signer la requête (spécifié avec -keyfile). Les requêtes signées avec un certificat différent sont ignorés. si spkac, ss_cert ou gencrl sont spécifiés, cette option est ignorée.
-passin arg La source du mot de passe.
-verbose mode verbeux
-notext N’affiche pas la forme texte dans le fichier de sortie
-startdate date Permet de définir la date de début au format YYMMDDHHMMSSZ (structure ASN1 UTCTime)
-enddate date Permet de définir la date d’expiration au format YYMMDDHHMMSSZ (structure ASN1 UTCTime)
-days arg Le nombre de jours pendant lesquels certifier ce certificat
-md alg Le message digest à utiliser (md5 sha1 et mdc2)
-policy arg Spécifie la stratégie CA à utiliser. C’est une section dans le fichier de configuration
-msie_hack Permet un fonctionnemnt avec les très vieux contrôle d’enrollement de certificat IE ’certenr3’.
-preserveDN Normalement l’ordre du DN est le même que l’ordre des champs dans la section de stratégie. Avec cette option, l’ordre est le même que dans la requête
-noemailDN Le DN d’un certificat peut contenir le champ email s’il est présent dans le DN de la requête ; cependantil est préférable d’avoir l’email dans l’extnsion altName. Avec cette option, le champs email est supprimé du sujet du certificat et définis dans les extensions si présent.
-batch Dans ce mode tous les certificats sont certifiés automatiquement sans poser de questions.
-extensions section La section du fichier de configuration contenant les extensions à ajouter quand un certificat est délivré. Sans extention, un V1 est créé, si une extension est présente, même vide, un v3 est créé.
-extfile file Un fichier de configuration additionnel contenant les extensions à ajouter.
-engine id Spécifie le type de moteur. peut être définis à default pour tous les algorithmes disponibles
-subj arg Remplace le sujet dans la reque^te. doitêtre au format /type0=value0/type1=value1/type2=...
-utf8 Les valeurs dns les champs sont interprétés comme chaînes UTF-8 (par défaut en ASCII)
-multivalue-rdn l’argument -subj est interprété comme RDN multivalué. ex : /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe (sans cette option : 123456+CN=John Doe)

Options CRL

-gencrl Génère une CRL basé sur les informations dans le fichier d’index
-crldays num Nombre de jours avant la prochaine CRL. valeur placée dans le champ nextUpdate de la CRL.
-crlhours num Nombre d’heure avant la prochaine CRL.
-revoke filename Un nom de fichier contenant un certificat à révoquer.
-crl_reason reason Raison dela révocation. Peut être (unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold ou removeFromCRL). Définis une raison de révocation va créer une CRL v2.
-crl_hold instruction Définis la raison de révocation à certificateHold et l’instruction doit etre un OID (pet être à holdInstructioNone (=obsolete), holdInstructionCallIssuer ou HoldInstructionReject)
-crl_compromise time Définis la raison de révocation keyCompromise et le temps au format YYYYMMDDHHMMSSZ.
-crl_CA_compromise time Idem pour CACompromise
-crlexts section Section dans le fichier de configuration contenant les extensions CRL à inclure. Sans extension, une CRL v1 st générée.

Options du fichier de configuration

   La section par défaut doit être nommée dans l’option default_ca de la section ca (ou de la section par défaut).

oid_file Spécifie le fichier contenant des oid additionnels, un par ligne.
oid_section Spécifie la section dans le fichier de configuration contenant les oid additionnels.
new_certs_dir Idem à -outdir
certificate idem à -cert
private_key idem à -keyfile
RANDFILE un fichier utilisé pour lire et écrire des informations de nombre aléatoire.
default_startdate idem à -startdate
default_enddate idem à -enddate
default_crl_hours idem à -crlhours
default_crl_days idem à -crldays
default_md idem à -md
database le fichier de données à utiliser
unique_subject à yes, les certificats doivent avoir un sujet unique
serial Fichier texte contenant le prochain numéro de CRL en hexa à utiliser.
x509_extensions idem à -extensions
crl_extensions idem à -crlexts
preserve idem à -preserveDN
email_in_dn idem à -noemailDN
msie_hack idem à -msie_hack
policy idem à -policy
name_opt, cert_opt Permettent au format utilisé d’afficher les détails du certificat lorsqu’il est demandé à l’utilisateur de confirmer la signature.
copy_extensions Détermine comment les extensions dans la requête sont manipulés. non spécifié ou à none, lesextensions sont ignorés. à copy, les extensions non encore présentes sont copiées dans le certificat. a copyall, toutes les extensions sont copiées en supprimant celles déjà présentes

Exemples

Signer une requête de certificat:
openssl ca -in req.pem -out newcert.pem
signer une requête e certificat, en utilisant les extensions de CA:
openssl ca -in req.pem -extensions v3_ca -out newcert.pem
Générer une CRL:
openssl ca -gencrl -out crl.pem
signer plusieurs requêtes:
openssl ca -infiles req1.pem req2.pem req3.pem
Certifier un SPKAC Netscape:
openssl ca -spkac spkac.txt
exemple de fichier SPKAC (tronquée pour plus de clarté):
SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5
CN=Steve Test
emailAddress=steve@openssl.org
0.OU=OpenSSL Group
1.OU=Another Group

Exemple de section ca dans la configuration


[ ca ]
default_ca = CA_default # Section ca par défaut
    
[ CA_default ]
dir = ./demoCA # Répertoire de base
database = $dir/index.txt # fichier d’index
new_certs_dir = $dir/newcerts # Répertoire pour les nouveaux certificats délivrés
    
certificate = $dir/cacert.pem # Certificat racine
serial = $dir/serial # fichier serial
private_key = $dir/private/cakey.pem# Clé privée de la ca
RANDFILE = $dir/private/.rand # Fichier de nombres aléatoire
    
default_days = 365 # Durée de validité du certificat
default_crl_days= 30 # Durée de la CRL
default_md = md5 # md à utiliser
    
policy = policy_any # Stratégie par défaut
email_in_dn = no # Ne pas ajouter le mail dans le DN
    
name_opt = ca_default # Option d’affichage du nom du sujet
cert_opt = ca_default # Option d’affichage du certificat
copy_extensions = none # Ne pas copier les extensions depuis la requête
    
[ policy_any ]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Variables d'environnement

OPENSSL_CONF Réflète l’emplacement du fichier de configuration maître (idem à -config)
^
19 février 2012

htmlpdflatexmanmd




OpenSSL - asn1parse

OpenSSL - asn1parse

Parser les structures ASN.1, ou extraire les données ASN.1

OPTIONS

-inform DER|PEM Format d’entrée (DER : binaire, PEM : base64)
-in filename Fichier d’entrée
-out filename Fichier de sortie où placer les données DER.
-noout Ne sort pas la version parsée du fichier en entrée
-offset number Commence à parser à l’offset spécifié
-length number Nombre d’octets à parser
-i Indenter la sortie en accord avec le "depth" des structures
-oid filename Un fichier contenant un OID additionnel.
-stdparse offset Parse le contenu des octets de l’objet ASN.1 en commençant à l’offset spécifié. Peut être spécifié plusieurs fois.
-genstr string, -genconf file Génère des données encodée basé sur la chaîne ou le fichier spécifié en utilisant le format ASN1_generate_nconf

SORTIE

La sortie contient des lignes de ce type:
0:d=0 hl=4 l= 681 prim : SEQUENCE
.....
229:d=3 hl=3 l= 141 prim : BIT STRING
373:d=2 hl=3 l= 162 cons : cont [ 3 ]
376:d=3 hl=3 l= 159 cons : SEQUENCE
379:d=4 hl=2 l= 29 cons : SEQUENCE
381:d=5 hl=2 l= 3 prim : OBJECT

   Chaque ligne commence avec un offset décimal. d=xx spécifie la profondeur courante. hl=XX donne la longueur d’en-tête du type courant. l=XX donne la longueur du contenu.

Exemples

parser un fichier
openssl asn1parse -in file.pem
parser un fichier DER
openssl asn1parse -inform DER -in file.der
générer un UTF8String simple
openssl asn1parse -genstr ’UTF8:Hello World’
Générer un UTF8String, ne pas parser la sortie
openssl asn1parse -genstr ’UTF8:Hello World’ -noout -out utf8.der
génerer en utilisant un fichier de configuration
openssl asn1parse -genconf asn1.cnf -noout -out asn1.der
exemple de fichier de configuration
asn1=SEQUENCE:seq_sect
[seq_sect]
field1=BOOL:TRUE
field2=EXP:0, UTF8some random string
^
19 février 2012

htmlpdflatexmanmd




OpenSSL - présentation

OpenSSL - présentation

Utilitaire cryptographique

   OpenSSL est un utilitaire cryptographique implémentant SSL v2/v3 et TLS v1 et les standards cryptographiques liés. Il permet de:

        - Crée des paramètres de clé RSA, DH et DSA
        - Créer des certificats X.509, CSR et CRL
        - Calculer les digests de messages
        - Crypter et décrypter avec chiffrement
        - Tests client/serveur SSL/TLS
        - Manipuler les mails signé ou chiffré S/MIME

Sommaire des commandes

list-standard-commands Affiche la liste des commandes standards
list-message-digest-commands Affiche la liste des commandes Digest standard
list-cipher-commands Affiche la liste des commandes de chiffrement standard
list-public-key-algorithms Liste les algorithmes de clé publique supportés.
no-‹commande› test si une commande est disponible. (Sort 0 si la commande existe, 1 sinon)

Commandes standards

asn1parse Parse une séquence ASN.1
ca Gestion de CA
ciphers Détermine le Cipher Suite Description
cms Utilitaire CMS
crl Gestion de CRL
crl2pkcs7 Conversion de CRL vers pkcs7
dgst Calcul de Message Digest
dh Gestion des paramètre Diffie Hellman
dhparam Génération et gestion des paramètres Diffie Hellman
dsa Gestion des données DSA
dsaparam Génération des paramètres DSA
ec Traitement de clé EC
ecparam Génération et manipulation de paramètres EC
enc Encodage avec Chiffrement
engine Information et manipulation du moteur
errstr Conversion des numéro d’erreur en message d’erreur
gendh Génération des paramètres Diffie Hellman
gendsa Génération des paramètres DSA
genrsa Génération des paramètres RSA
genpkey Génération des clés privée ou paramètres
nseq Créer ou examiner une séquence de certificat Netscape
ocsp Utilitaire pour le protocole Online Certificate Status
passwd Génération de hash de mot de passe
pkcs12 Gestion des données PKCS #12
pkcs7 Gestion des données PKCS #7
pkey Gestion de clé publique et privée
pkeyparam Gestion des paramètres d’algorithme de clé publique
pkeyutl Utilitaire pour les opérations cryptographique de clé publique
rand Génère des octets pseudo-aléatoire
req Gestion des CSR
rsa Gestion des données RSA
rsautil Utilitaire RSA pour signer, vérifier, chiffrer et déchiffrer
s_client Implémente un client générique SSL/TLS pour établir une connexion transparente à un serveur distant.
s_server Implémente un serveur SSL/TLS qui accepte les connections depuis des clients distant.
s_time Timer de connexion SSL
sess_id Gestion de données de session SSL
smime Traitement des mail S/MIME
speed Mesure de vitesse des algorithmes
spkac Utilitaire de génération et d’affichage SPKAC
ts Outil client/serveur d’autorité TimeStamping
verify Vérification de certificats X.509
version Information de version d’openssl
x509 Gestion des données des certificats x509

Commandes Digest Standards

md2 digest md2
md5 Digest md5
mdc2 digest mdc2
rmd160 digestion RMD-160
sha digest sha
sha1 digest sha-1
sha224 digest sha-224
sha256 digest sha-256
sha384 digest sha-384
sha512 digest sha-512

Commandes d’encodage et de chiffrement

base64 Encodage en base64
bf bf-cbc bf-cfb bf-ecb bf-ofb Chiffrement blowfish
cast cast-cbc Chiffrement CAST
cast5-cbc cast5-cfb cast5-ecb cast5-ofb Chiffrement CAST5
des des-cbc des-cfb des-ecb des-ede des-ebe-cbc des-ebe-cfb des-ebe-ofb des-ofb Chiffrement DES
des3 desx des-ede3 des-ede3-cdc des-ede3-cfb des-ede3-ofb Chiffrement TRIPLE-DES
idea idea-cbc idea-cfb idea-ecb idea-ofb Chiffrement IDEA
rc2 rc2-cbc rc2-ecb rc2-ofb Chiffrement RC2
rc4 Chiffrement rc4
rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb Chiffrement rc5

Arguments de pass-phrase

pass:password Le mot de passe actuel est password.
env:var Obtenir le mot de pass depuis la variable d’environnement var
file:pathname La première ligne du fichier est le mot de passe. Si ce même fichier est spécifié à -passin et -passout, la première ligne est pour l’entrée la ligne suivante est pour la sortie
fd:number Lit le mot de passe depuis le descripteur de fichier spécifié
stdin Lit le mot de passe depuis l’entrée standard
^
13 février 2012

htmlpdflatexmanmd




OpenSC

OpenSC

Librairie PKCS#11

   OpenSC est une librairie PKCS #11 ainsi qu'une API pour l'utiliser. Sur la carte, OpenSC implémente PKCS #15

^
13 février 2012

htmlpdflatexmanmd




opensc.conf

opensc.conf

Fichier de configuration pour OpenSC


app default {
    debug = 0 ; # niveau de debug
    debug_file = "/var/log/opensc-debug.log" ; # Fichier où ecrire les informations de debug (défaut : stdout)
    error_file = "/var/log/opensc-errors.log" ; # Fichier où ecrire les information d’erreur (défaut : stderr)
    profile_dir = PKGDATADIR ; # Répertoire de profil pour pkcs15-init (défaut : /usr/share/opensc)
    reader_drivers = pcsc, openct, ctapi ; # pilotes à charger au démarrage. ’internal’ va charger tous les pilote liés statiquement (défaut)
}
    
    {
        reader_driver ctapi { # configuration pour le pilote ctapi
            module /usr/local/towitoko/lib/libtowitoko.so {
                ports = 0 ; # port CT-API 0..3 (COM1..4) 4 (printer) 5 (modem) 6..7 (LPT1..2)
            }
        }
    
        reader_driver pcsc { # configuration pour le pilote pcsc
            max_send_size = 252 ; # Taille max des données envoyée et reçues. Vérifier avec lsusb -vv pour dwMaxIFSD
            max_recv_size = 252 ;
            connect_exclusive = false ; # connecter le lecteur en mode exclusif (défaut : false)
            connect_reset = true ; # réinitialiser la carte après déconnection (défaut : true)
            transaction_reset = false ; # réinitialise la carte après charque transaction (défaut : false)
            enable_pinpad = false ; # active pinpad si détecté (défaut : false)
        }
    
        reader_driver openct {
            readers = 5 ; Lecteurs virtuels à allouer (défaut : 5)
        }
    
        card_drivers = customcos, internal ; # pilotes à charger au démarrage. ’internal’ charge tous les pilotes liés dynamiquement (défaut et doit toujours être la dernière entrée)
        card_driver customcos {
            module = /usr/lib/opensc/drivers/card_customcos.so ; # emplacement du pilote
        }
    
        force_card_driver = autodetect ; # si spécifié, force OpenSC à utiliser ce pilote.(défaut : autodetect)
        # noms des pilotes internes supportés : etoken, flex, cyberflex, gpk, miocos, mcrd, setcos, starcos, tcos, openpgp, jcop, oberthur, belpic, emv, piv
        card_atr 3b:f0:0d:ca:fe { # nouvelle entrée pour le pilote flex. Format générique : card_atr ‹hex encoded ATR (case-sensitive !)›
            atrmask = "ff:ff:ff:ff:ff" ; # masque AND pour l’ATR de la carte pour la l’identification de la référence ATR.
            driver = "flex" ; # pilote à utiliser
            name = "My CryptoFlex card" ; { nom de la carte
                type = "2002" ; # type de carte (valeur entière)
                flags = "keygen", "rng", "0x80000000" ; # flags au format hexa (ou chaine pour certains : keygen = capacités de génération de clé embarqué, rng = source de nombre aléatoire embarqué) pour personnaliser les capacités de la carte.
                pkcs15emu = "custom" ; # Couche d’amulation PKCS #15, force le pilote d’émulation pour les cartes spécifiques
                force_protocol = "t0" ; # Force le protocole à utiliser (t0, t1 ou raw)
            }
            card_atr 3B:7D:96:00:00:80:31:80:65:B0:83:11:00:AC:83:00:90:00 { # les cartes PIV on besoin d’un entrée comme ceci
                name = "PIV-II" ;
                driver = "piv" ;
            }
            card_atr 3b:6e:00:ff:45:73:74:45:49:44:20:76:65:72:20:31:2e:30 { # les cartes Estonian ID et le pilote Micardo fonctionne ensemble avec T=0. Seul l’ATR ’cold’ devrait être spécifié
                force_protocol = t0 ;
            }
            card_atr 3b:fe:94:00:ff:80:b1:fa:45:1f:03:45:73:74:45:49:44:20:76:65:72:20:31:2e:30:43 {
                force_protocol = t0 ;
            }
            card_atr 3b:fe:94:00:ff:80:b1:fa:45:1f:03:45:73:74:45:49:44:20:76:65:72:20:31:2e:30:43 { # Les cartes D-Trust sont aussi basées sur micardo et T=0
                force_protocol = t0 ;
            }
            card_atr 3b:ff:94:00:ff:80:b1:fe:45:1f:03:00:68:d2:76:00:00:28:ff:05:1e:31:80:00:90:00:23 {
                force_protocol = t0 ;
            }
            card_atr 3b:ff:11:00:ff:80:b1:fe:45:1f:03:00:68:d2:76:00:00:28:ff:05:1e:31:80:00:90:00:a6 {
                force_protocol = t0 ;
            }
            framework pkcs15 { # block spécifique au framework PKCS #15
                use_caching = false ; # spécifie d’utiliser les fichier en cache dans le home de l’utilisateur en apprenant la carte (pkcs15-tool -L) (ne doit pas être utilisé en root) (défaut : false)
                enable_pkcs15_emulation = yes ; # Active l’émulation pkcs15 (défaut : yes)
                try_emulation_first = yes ; # tente d’abord l’émulation pkcs15 avant le traitement normal pkcs15 (défaut : no)
                enable_builtin_emulation = yes ; # Active l’émulation intégrée
                builtin_emulators = esteid, openpgp, tcos, starcert, infocamere, postecert, actalis, atrust-acos, gemsafe, tccardos, PIV-II ; # liste des émulateurs pkcs15 intégrés à tester
                emulate custom { # Paramètre pour un émulateur pkcs15 chargé depuis une librairie externe
                    module = /usr/lib/opensc/drivers/p15emu_custom.so ; # emplacement de la librairie
                }
            }
        }
    
        app opensc-pkcs11 { # paramètres pour le module PKCS11 OpenSC
        pkcs11 {
            num_slots = 4 ; # Nombre de slot maximum par carte à puce
            hide_empty_tokens = yes ; # Cache les slots vides
            lock_login = true ; # opensc tente de locker la carte une fois authentifiée via C_Login. (défaut : false)
            cache_pins = true # normalement le module pkcs11 ne met pas en cache le pin présenté via C_Login, mais certaines carte ne fonctionne pas correctement avec opensc (défaut : true)
            soft_keygen_allowed = true ; # Force la génération de pair de clé embarqué (défaut : true)
            }
        }

^
13 février 2012

htmlpdflatexmanmd




smartcard_list.txt

smartcard_list.txt

Correspondance ATR - type de carte

   Ce fichier contient les référence entre un ATR et un type de carte. La liste la plus récente peut être téléchargée à http://ludovic.rousseau.free.fr/softwares/pcsc-tools/smartcard_list.txt

Syntaxe

Pour une association ATR - type de carte:
ATR sous la forme d'une expression régulière
[tab] Texte descriptif
[tab] Texte descriptif
[tab] Texte descriptif
ligne vide
^
13 février 2012

htmlpdflatexmanmd




opensc-tool

opensc-tool

Utilitaire générique pour cartes à puce

OPTIONS

--atr, -a Affiche l’Answer To Reset de la carte, au format hexa
--serial Afficher le numéro de série de la carte (ICCSN) en hexa
--send-apdu, -s Envoie un APDU arbitraire à la carte au format AA:BB:CC:DD:EE:FF...
--list-files, -f Liste tous les fichiers stockés sur la carte
--list-readers, -l Liste tous les lecteurs configurés
--list-drivers, -D Liste tous les pilotes de carte installés
--list-rdrivers, -R Liste tous les pilotes de lecteur installés
--reader, -r Numéro du lecteur --card-driver, -c
Utilise le lecteur de carte donné --verbose, -v
Mode verbeux
^
13 février 2012

htmlpdflatexmanmd




opensc-explorer

opensc-explorer

Utilitaire intéractif pour accéder aux cartes à puce

OPTIONS

--reader, -r Utilise le numéro de lecteur de carte donné
--card-driver, -c Utilise le pilote de carte donné
--verbose, -v mode verbeux

Commandes

ls Liste tous les fichiers dans le DF courant
cd file-id Changer de DF spécifié par sont file-id
info [file-id] Affiche les attributs d’un fichier spécifié par son file-id
create file-id size Crée un nouveau EF en spécifiant sont file-id et sa taille
delete file-id Supprime le EF ou DF spécifié par son file-id
verify key-typekey-id [key] Présente un PIN ou une clé à la carte. le key-type peut être CHV, KEY ou PRO, le key-id est la clé ou le PIN et les clé est la clé ou le PIN à vérifié en hexa.
change CHVid [old-pin] new-pin Changer un pin
put file-id [input] Copie un fichier local sur la carte
get file-id [output] Copie un EF dans un fichier local
mkdir file-id size Créer un DF
pksign Créer un signature de clé publique. (actuellement non implémenté)
pkdecrypt Décrypte un clé publique. (actuellement non implémenté)
erase Efface la carte
quit Quitter le programme.
^
13 février 2012

htmlpdflatexmanmd




pcscd

pcscd

Service PC/SC pour pcsclite et le framework MuscleCard

   Service PC/SC pour pcsclite et le framework MuscleCard. C’est un gestionnaire de ressource qui coordonne les communications entre les lecteur de cartes et les cartes et tokens connectés au système.

  Les pilotes de lecteur de carte série sont dans /usr/lib/pcsc/drivers. pcscd localise les pilotes en utilisant /var/lib/pcscd/reader.conf (les pilotes sont disponibles à http://www.musclecard.com/drivers.html)

  Les pilotes USB sont placés dans /usr/lib/pcscd/drivers. Vous ne devriez pas ajouter de pilote USB dans reader.conf.

Fichiers

/var/lib/pcscd/reader.conf: Fichier de configuration des lecteurs
/var/run/pcscd/pcscd.pid: process id
/usr/lib/pcsc/drivers: Répertoire des pilotes usb.

OPTIONS

-a, --apdu log les APDU et SW en utilisant la méthode de debug
-c, --config Spécifie le fichier alternatif à /var/lib/pcscd/reader.conf
-f, --foreground Ne lance pas en tâche de fond et envoie les mesage sur stderr au lieu de syslog
-d, --debug Niveau de debug
--info Utilise le niveau de log info (mode par défaut)
--error Utilise le niveau de log error
--critical Utilise le niveau de log critical
-H, --hotplug Demande à pcscd de rescanner les bus USB et relire /var/lib/pcscd/reader.conf pour détecter les lecteurs non-USB.
^
13 février 2012

htmlpdflatexmanmd




pcsc_scan

pcsc_scan

Scanner les lecteurs de carte

   Scan les lecteurs de carte à interval régulier. Il demande à pcscd la liste des lecteurs disponible. Quand une carte est insérée, il affiche diverses informations:

  Date et heure, nom du lecteur, état de la carte et évènements, ATR de la carte à l’insertion et analyse si la commande ATR_analysis est disponible

OPTIONS

-n  N’effectue pas d’analyse ATR.
^
13 février 2012

htmlpdflatexmanmd




reader.conf

reader.conf, reader.conf.d

Fichiers de configuration pour les pilotes des lecteurs pcscd

Syntaxe

   Chaque entrée doit être définie par 4 champs:

FRIENDLYNAME Texte arbitraire pour identifier le lecteur. Affiché par la commande pcsc_scan
DEVICENAME (ifdhandler ›= 3.0). Utilisé pour identifier le port physique sur lequel le lecteur est connecté
LIBPATH Nom du fichier du pilote
CHANNELD (ifdhandler ‹ 3.0). Remplacé par DEVICENAME

Exemples

Gemplus lecteur GemPCTwin avec communication série:
FRIENDLYNAME "GemPCTwin serial"
DEVICENAME /dev/ttyS0
LIBPATH /usr/lib/pcsc/drivers/serial/libccidtwin.so.0.4.1
CHANNELID 1
^
13 février 2012

htmlpdflatexmanmd




update-reader.conf

update-reader.conf

Outil pour générer reader.conf

   Outil pour regénérer /etc/reader.conf. Il tente de générer le fichier de configuration depuis les fichiers inclus dans /etc/reader.conf.d/. l’ancienne version est backupée dans /etc/reader.conf.old

OPTIONS

force Si le /etc/reader.conf ne contient pas de tag spécial sur la première ligne, il annule la régénération. Ce paramètre le force à continuer.
^
13 février 2012

htmlpdflatexmanmd




OpenCT

OpenCT

Pilotes pour cartes à puce

   Openct implémente des pilotes pour de nombreux lecteurs de carte. Ils sont fournis au format ifdhandler requis pour pcsc-lite. OpenCT a également un mécanisme primitif pour exporter les lecteurs de carte sur des machines distantes via tcp/ip.

Présentation générale

Le scénario le plus simple et recommandé est:
Application (ex : mozilla)
librairie PKCS11(ex : OpenSC)
OpenCT
Kernel Linux

   Mozilla peut charger les modules de sécurité implémentant PKCS11, opensc le fait et a une interface directe pour utiliser openCT

Parfois vous avez cette pile:
Application
PC-SC/Lite
Driver
Kernel

   PC/SC est un standard sous Windows, donc de nombreuses applications veulent l’utiliser pour communiquer avec les cartes à puce. pcsclite a besoin de pilotes au format ifdhandler. OpenCT a un pilote au format ifdhandler.

Le 3ème modèle:
Application
Driver

   est très simple et a été conçus pour DOS.Il fonctionne très bien pour une application et un utilisateur. Il n’est plus utilisé.

Système d'exploitation

   Les lecteurs de carte USB necéssitent un support USB pour que OpenCT soit notifié. hotplug tend à être remplacé par udev ou hald.

Configurer udev

Pour le support USB sous Linux vous devez avoir:
- libusb
- CONFIG_HOTPLUG pour que le kernel laisse savoir si un lecteur ou un token est branché
- udev installé
- Copier les fichiers suivant:
/lib/udev/rules.d/50-openct.rules
/lib/udev/openct_usb
/lib/udev/openct_pcmcia
/lib/udev/openct_serial

Accès au lecteur de carte distant

   cette fonctionnalité n’inclus aucun mécanisme de sécurité.

Sur la machine avec le lecteur, ajouter à openct.conf (exemple avec un lecteur série):
reader xiring {
    driver = xiring;
    device = serial:/dev/ttyS0;
};

Démarrer ifdproxy pour pointer vers la machine distante:
ifdproxy export xiring /dev/ttyS0 ‹machine-distante› :‹port›

Sur la machine avec le logiciel, ajouter dans openct.conf:
ifdhandler = /usr/sbin/ifdhandler;
ifdproxy {
    server-port = /var/run/openct/proxy,
    device-port = :6666;
};
reader xiring {
    driver = xiring;
    device = remote:serial1@/var/run/openct/proxy;
};

Démarrer openct
/etc/init.d/openct start
ifdproxy server
^
13 février 2012

htmlpdflatexmanmd




openct.conf

openct.conf

Fichier de configuration pour openct


debug = 0; # niveau de debug
hotplug = yes; # Active le mode hotplug
    
# Path to ifdhandler
ifdhandler {
    program = /usr/sbin/ifdhandler; # emplacement de l’ifdhandler
    force_poll = 1; # désactiver si ›=2.6.27.14 ou 2.6.28.3
    user = openctd;
    groups = {
        usb,
    };
};
    
ifdproxy { # configuration pour idfproxy
    server-port = /var/run/openct/.ifdproxy,
    device-port = :6666;
};
    
# Liste des lecteurs et leurs options
    
#reader towitoko {
# driver = towitoko;
# device = serial :/dev/ttyS0;
#};
    
#reader gempc {
# driver = gempc;
# device = serial :/dev/ttyS0;
#};
    
#reader cm4000 {
# driver = cm4000;
# device = pcmcia :/dev/cmm0;
#};
    
#reader cm4040 {
# driver = ccid;
# device = pcmcia_block :/dev/cmx0;
#};
    
#reader pertosmart1030 {
# driver = pertosmart1030;
# device = serial :/dev/ttyS0;
#};
    
# ID pour Hotplug
driver egate {
    ids = {
        usb:0973/0001,
    };
};

driver ePass3000 {
    ids = {
        usb:096e/0401,
    };
};

driver etoken {
    ids = {
        usb:0529/050c,
        usb:0529/0514,
    };
};
driver etoken64 {
    ids = {
        usb:0529/0600,
        usb:0529/0700,
    };
};
driver eutron {
    ids = {
        usb:073d/0005,
    };
};
driver ikey2k {
    ids = {
        usb:04b9/1202,
    };
};
driver ikey3k {
    ids = {
        usb:04b9/1300,
    };
};
driver starkey {
    ids = {
        usb:096e/0005,
    };
};
driver cardman {
    ids = {
# usb:076b/0596, # OMNIKEY CardMan 2020
# usb:076b/1784, # OMNIKEY CardMan 6020
# usb:08d4/0009, # Fujitsu Siemens SCR USB Reader
    };
};
driver ccid {
    ids = {
        usb:03f0/1024, # HP Keyboard with CCID reader
        usb:046a/0010, # Cherry smartboard G83-6744
        usb:04e6/5115,
        usb:04e6/5116,
        usb:04e6/5117, # SCM Micro token size reader
        usb:04e6/511d, # SCM Micro SCR3311
        usb:04e6/E001,
        usb:04e6/E003,
        usb:073d/0c00, # Eutron SimPocket (doesn’t work yet)
        usb:076b/1021, # OmniKey CardMan 1021
        usb:076b/3021,
        usb:076b/5121,
        usb:076b/5321, # OmniKey CardMan 5321
        usb:076b/6622, # OmniKey CardMan 6121
        usb:0783/0003,
        usb:08e6/3437, # Gemplus
        usb:08e6/3438, # Gemplus GemPC Key SmartCard Reader
        usb:08e6/4433, # Gemplus
        usb:0b97/7762, # O2 Micro, Inc. Oz776 SmartCard Reader
        usb:0b97/7772, # O2 Micro, Inc. Oz776 SmartCard Reader
        usb:0bf8/1006, # fujitsu siemens 3.5" drive size reader
        usb:0dc3/1004, # Athena Smartcard Solutions, Inc. ASEKey
        usb:0a89/0030, # Aktiv Rutoken ECP
    };
};
driver pertosmart1030 {
    ids = {
        usb:072f/0001,
        usb:072f/8009,
    };
};
driver pertosmart1038 {
    ids = {
        usb:072f/9000,
        usb:072f/9006, # ACS CryptoMate Token
        usb:072f/9007, # ACS ACR 100 SIMFlash
        usb:072f/90d0,
    };
};
#driver wbeiuu { # driver not working yet
# ids = {
# usb:104f/0004,
# };
#};
    
# Tested with USBID 0c4b:0100. These are red readers : one with LCD,
# another one without.
driver cyberjack {
    ids = {
        usb:0c4b/0100,
    };
};
driver rutoken {
    ids = {
        usb:0a89/0020, # Aktiv Rutoken S
        usb:0a89/0012, # Aktiv uaToken S
    };
};

^
13 février 2012

htmlpdflatexmanmd




openct-control

openct-control

démon openct

OPTIONS

-d mode debug
-n  Désactiver le branchement à chaud
-f Spécifier le fichier de configuration (défaut : /etc/openct.conf)

Commandes

init initialiser openct
attach driver type device Attacher un périphérique
status Affiche le status de tous les lecteurs présent
shutdown Arrête le service OpenCT

Variables d'environnement

OPENCT_SOCKETDIR Spécifie l’emplacement pour les fichiers et sockets (défaut : /var/run/openct)
^
13 février 2012

htmlpdflatexmanmd




openct-tool

openct-tool

Utilitaire pour les cartes à puces openCT

OPTIONS

-d mode debug
-f Spécifier le fichier de configuration (défaut : /etc/openct.conf)
-r Index du lecteur de carte à utiliser

Commandes

list lister les lecteurs trouvés
atr Afficher l’ATR de la carte insérée
wait Attend que la carte soit insérée
rwait Attend qu’un lecteur de carte soit inséré
mf Tente de sélectionner le répertoire principal de la carte
read dump la mémoire de la carte synchrone
^
13 février 2012

htmlpdflatexmanmd




ifdhandler

ifdhandler

Utilitaire de gestion des modules au format ifdhandler

OPTIONS

-r Index du lecteur de carte à utiliser
-F Tâche de fond
-H spécifie qu’il s’agit d’un lecteur hotplug
-p force le polling device event si les évènement sont supportés
-s Envoie les messages de debug et d’erreur à syslogd
-d mode debug (peut être spécifié plusieurs fois)
-i Affiche la liste des pilotes et protocoles disponibles
^
13 février 2012

htmlpdflatexmanmd




ifdproxy

ifdproxy

Utilitaire pour l'accès au lecteur de carte distant

OPTIONS

-d mode debug
-F Ne lance pas en tâche de fond

Commandes

server [-dF] Lance le mode serveur
export [-dF] name device address:port Exporte le lecteur de carte vers une machine distante
list [-dF] address:port Liste les périphériques sur la machine distante, ou tous les périphériques si aucune adresse n’est spécifiée
^
12 février 2012

htmlpdflatexmanmd




pam_pkcs11

pam_pkcs11

Module PAM d'authentification via une librairie PKCS #11

   Module PAM pour faire de l'authentification au moyen d'un certificat X509 au travers d'une librairie PKCS #11. Pour la vérification des certificats utilisateurs, le certificat de l'autorité stocké localement et la CRL en ligne ou locale sont utilisés. Les modules PKCS #11 doivent remplir les prérequis de RSA Asymmetric Client Signing Profil. Pour permettre au propriétaire d'un certificat de se connecter, pam_pkcs11 utilise des modules appelés des mappers, qui effectuent des mappages cert-to-login.

Configurer le package

1. créer le répertoire de base /etc/pam_pkcs11/
2. Copier ${base}/etc/pam_pkcs11.conf.example dans /etc/pam_pkcs11/ et le renommer en /etc/pam_pkcs11/pam-pkcs11.conf
3. créer /etc/pam_pkcs11/crls/ et /etc/pam_pkcs11/cacerts/. Le répertoire tools/ fournis un outil pkcs11_make_hask_link qui peut être utilisé pour créer les fichiers de hash pour chaque fichier certificat et crl valide.
4. Choisir un ou plusieurs mappers à installer, les configurer.
5. Éditer et configurer /etc/pam.d/xxx
6. Utiliser pkcs11_inspect et pklogin_finder pour voir si vous pouvez lire le certificat et effectuer un mappage correct
7. tester un login.

Configurer pam_pkcs11

la configuration de pam-pkcs11 se fait en 2 étapes:
1. configurer pam-pkcs11
2. Configurer les options PAM.

Vous devez connaître

- quel module PKCS #11 vous allez utiliser, et son fichier
- quels mappers vous voulez et comment le créer et l'éditer
- Les fichiers de l'authorité de certification et le fichier de révocation
- Une liste d'utilisateurs autorisés à se connecter, et leur certificats correspondant.

Spécifier la CRL et la CA

   pam-pkcs11 a besoin d'une liste d'authorité de certification reconnue pour valider l'utilisateur. Celà s'applique également à la CRL :

1. Créer les répertoire ca_dir et crl_dir en accord avec le fichier de configuration
2. Copier les certificats de la CA au format DER ou PEM
3. Créer un hash link vers les certificats CA, fournis avec pkcs11_make_hash_link. Noter que openSSL doit être installé :
cd /etc/pam_pkcs11/cacerts
/usr/bin/pkcs11_make_hash_link
4. Répéter la procédure pour la CRL
5. Sélectionner la stratégie de vérification de certificat (cert_policy)

   NOTE : Du à des limitations de librairie OpenSSL, les certificats de la CA doivent résider dans le système de fichier local.

Un fichier de map a la syntaxe suivante:
Certificate1 data -› login1
Certificate2 data -› login2
Certificate3 data -› login3
Ce fichier est parsé du début àla fin et la première occurence qui match est retournée.

Configuration PAM

   Configurer les fichiers pam.d

  auth sufficient pam_pkcs11.so ...

OPTIONS

debug mode debug
err_display_time Secondes à attendre après un message d'erreur pour lire le message
config_file Spécifier le fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)
nullok Autorise les mots de passe vide
use_first_pass Ne demande pas le mot de passe à l'utilisateur, mais le prend depuis le PAM_items.
try_first_pass Ne demande pas le mot de passe à l'utilisateur à moins que PAM_(OLD)AUTHOK ne soit pas mis.
use_authok Comme try_first_pass mais échoue si le nouveau PAM_AUTHOK n'a pas été précédemment mis.
pkcs11_module=‹file› Nom de fichier du module PKCS11 (défaut : /etc/pam_pkcs11/pkcs11_module.so)
slot_num=‹nb› Numéro de slot à utiliser (défaut = 0 = utiliser le premier slot disponible)
ca_dir=‹path› Répertoire contenant les certificats CA (défault : /etc/pam_pkcs11/cacerts/)
crl_dir=‹path› Répertoire contenant la CRL (défault : /etc/pam_pkcs11/crls/)
cert_policy=none, ca, signature, crl_online, crl_offline, crl_auto Spécifier la stratégie de vérification par défaut.

Utiliser la fonction d'auto-détection de LOGIN

   Depuis pam-pkcs11-0.4.2 pam-pkcs11 peut déduire le username depuis le certificat utilisateur sans utiliser le login prompt.

  Quand pam_get_user() retourne null ou une chaîne vide, pam-pkcs11 va alors utiliser la fonction ’find’ du mapper au lieu du match normal. Si le finder retourne un succès, le username est définit avec pam_set_item(PAM_USER) et PAM_AUTH_OK est retourné.

Il y’a 2 manières d’utiliser cette fonctionnalité :
a. Patcher gdm et login pour détecter la présence d’un carte et retourner null comme nom d’utilisateur
b. Utiliser une version non patchée et entrée un espace pour login et entrée pour gdm.
^
12 février 2012

htmlpdflatexmanmd




pam_pkcs11.conf

pam_pkcs11.conf

fichier de configuration pour pam_pkcs11

   Le fichier de configuration utilise la librairie scconf. Les paramètres et données sont groupées dans des blocks. ils peuvent être imbriqués.

Un fichier de configuration pam_pkcs11 ressemble à:
pam-pkcs11
    global options
    [...]
    use_pkcs11_module = pkcs11 module to be used
    pkcs11_module module1 {
        module1 specific options
    }
    pkcs11_module module2 {
        module2 specific options
    }
    [...]
    use_mappers = mapper1, mapper2,... ;
    mapper mapper1 {
        mapper1 specific options
    }
    mapper mapper2 {
        mapper2 specific options
    }
    [...]
    mapper mapperN {
        mapperN specific options
    }
}

Exemple de fichier pam_pkcs11.conf
pam_pkcs11 {
    nullok = true ; # Allow empty passwords
debug = true ; # Enable debugging support.
    use_first_pass = false ; # Do not prompt for the passwords but take them from the PAM_ items instead
    try_first_pass = false ; # Do not prompt for the passwords unless PAM_(OLD)AUTHTOK is unset.
    use_authtok = false ; # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been previously set (intended for stacking password modules only).
    use_pkcs11_module = opensc ; # Filename of the PKCS #11 module. The default value is "default"
    
pkcs11_module opensc {
    module = /usr/lib/opensc-pkcs11.so ;
    description = "OpenSC PKCS#11 module" ;
    slot_description = "none" ; # spécifier le slot à utiliser. préférer cette option à slot_num.
    # slot_num = 0 ; # spécifier soit slot_description, soit slot_num.
    ca_dir = /etc/pam_pkcs11/cacerts ; # répertoire contenant les certificats de l’autorité au format pem ou asn1 oui des liens hash.
    crl_dir = /etc/pam_pkcs11/crls ; # répertoire contenant la CRL offline
    support_threads = false ; # certaines librairies supportent le multi-thread
    cert_policy = ca,signature ; # définis la vérification de certificat
    # none aucune vérification
    # ca vérfication de la CA
    # crl_online télécharge la CRL
    # crl_offline utilise la crl offline
    # crl_auto tente d’abord la online, puis la offline
    # signature vérifie la signature
    token_type = "Smart card" ; # spécifie le type de token. sera utilisé dans le message de prompt.
    pkcs11_module etoken { # Aladdin eTokenPRO 32
        module = /usr/local/lib/libetpkcs11.so
        description = "Aladdin eTokenPRO-32" ;
    
        slot_num = 0 ;
        support_threads = true ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = ca,signature ;
    }
    pkcs11_module nss { # NSS (Network Security Service) config
        nss_dir = /etc/ssl/nssdb ;
        crl_policy = none ;
    }
    pkcs11_module default { # Default pkcs11 module
        module = @libdir@/pam_pkcs11/pkcs11_module.so ;
        description = "Default pkcs#11 module" ;
        slot_num = 0 ;
        support_threads = false ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = none ;
    }
    use_mappers = digest, cn, pwent, uid, mail, subject, null ;    # spécifie les mappers à utiliser:
        # subject    Sujet du certificat
        # pwent     CN ou gecos
        # ldap        mapper LDAP
        # opensc    Cherche le certificat dans ${HOME}/.eid/authorized_certificates
        # openssh    Cherche la clé public du certificat dans ${HOME}/.ssh/authorized_keys
        # mail        compare le champs email du certificat
        # ms        Utilise l’UPN
        # krb        Compare avec le Kerberos Principal Name
        # cn        Compare le CN
        # uid        Compare l’UID
        # digest    Certificat Digest
        # generic    Contenu définis par l’utilisateur
        # null        blind access/deny mapper
    mapper_search_path = @libdir@/pam_pkcs11 ;    # chemin des module mapper.
    mapper subject {                # Mapper le sujet du certificat pour le login, fournis dans un fichier sous la forme "Subject -› login"
        debug = false ;
        #module = @libdir@/pam_pkcs11/subject_mapper.so ;
        module = internal ;
        ignorecase = false ;
        mapfile = file :///etc/pam_pkcs11/subject_mapping ;
    }
    mapper pwent {                # map le CN à getpwent()
        debug = false ;
        ignorecase = false ;
        module = internal ;
        #module = @libdir@/pam_pkcs11/pwent_mapper.so ;
    }
    mapper ldap {                # mapper d’annuaire
        debug = false ;
        module = @libdir@/pam_pkcs11/ldap_mapper.so ;
        ldaphost = "" ;                 # fqdn du serveur ldap (utilise l’URI ldap pour en spécifier plusieurs)
        ldapport = ;                 # port du serveur ldap s’il n’est pas donné dans l’URI
        URI = "" ;                # list d’URI utilisés dans l’ordre
        scope = 2 ;                 # scope de recherche : 0 (base), 1 (one), 2 (sub)
        binddn = "cn=pam,o=example,c=com" ;     # DN du bind. doit avoir un accès en lecture
        passwd = "" ;                 # password du binddn
        base = "ou=People,o=example,c=com" ;    # base de recherche
        attribute = "userCertificate" ;        # attribut qui contient le certificat
        filter = "(&(objectClass=posixAccount)(uid=%s))" # Filtre de recherche pour les entrées utilisateurs ( doit seulement laisser passer l’entrée pour le login utilisateur )
        ssl = tls                # off (désactiver), tls (activer tls), on|ssl (activer ssl)
        tls_randfile =                 # chemin de la source entropie
        tls_cacertfile = /etc/ssl/cacert.pem    # Chemin vers le certification pour l’authentification du pair
        tls_cacertdir =                # Répertoire contenant les certificats X509 pour l’authentification du pair
        tls_checkpeer = 0            # 0 ou 1. spécifie de vérifier le certificat.
        tls_ciphers =                 # Chiffrement à utiliser
        tls_cert = ...                # Chemin du fichier contenant le certificat local pour l’authentification TLS client
        tls_key = ...                # Chemin du fichier contenant la clé privée pour l’authentification TLS client
    }
    mapper opensc {                 # recherche les certificats depuis $HOME/.eid/autorized_certificates qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/opensc_mapper.so ;
    }
    mapper openssh {                # Cherche les clés publique dans $HOME/.ssh/authorized_keys qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/openssh_mapper.so ;
    }
    mapper mail {                # Compare le champ email du certificat
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/mail_mapper.so ;
        mapfile = file :///etc/pam_pkcs11/mail_mapping ;    # Déclarer un fichier de map, ’empty’ ou vide pour ne pas utiliser de fichier de map
        ignorecase = true ;            # ignorer la casse
        ignoredomain = false ;            # Vérifie le domaine mx. en utilisant un fichier de map, cette option est ignorée.
    }
    mapper ms {                    # utilise l’UPN (login@AD_domain)
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/ms_mapper.so ;
        ignorecase = false ;
        ignoredomain = false ;
        domain = "domain.com" ;
    }
    mapper krb {                # Compare avec le principal kerberos
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/krb_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper cn {                    # le CN est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/cn_mapper.so ;
        ignorecase = true ;
        # mapfile = file :///etc/pam_pkcs11/cn_map ;
        mapfile = "none" ;
    }
    mapper uid {                # l’uid (s’il existe) est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/uid_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper digest {                # Evalue le digest du certificat et le map dans un fichier
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/digest_mapper.so ;
        algorithm = "sha1" ;             # Algorithme utilisé pour évaluer le digest ("null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160")
        mapfile = file :///etc/pam_pkcs11/digest_mapping ;
        # mapfile = "none" ;
    }
    mapper generic {                # mapper de contenu générique
        debug = true ;
        #module = @libdir@/pam_pkcs11/generic_mapper.so ;
        module = internal ;
        ignorecase = false ;            # ignirer la casse
        cert_item = cn ;             # ( "cn" , "subject" , "kpn" , "email" , "upn" ou "uid" )
        mapfile = file :///etc/pam_pkcs11/generic_mapping ;
        use_getpwent = false ;            # utiliser petpwent() pour mapper le login
    }
    mapper null {                # Pas de mappage. Quand un utilisateur match à NULL ou nobody
        debug = false ;
        # module = @libdir@/pam_pkcs11/null_mapper.so ;
        module = internal ;
        default_match = false ;            # match toujours (true) ou échoue toujours (false)
        default_user = nobody ;            # en cas de match, retourner cet utilisateur
    }
}