Ce document spécifie le format des messages des requêtes de certificats (CRMF). Cette syntaxe est utilisée pour transmettre une demande de certificat à une autorité de certification (CA) (éventuellement via une Autorité d'enregistrement (RA)), pour la création d'un certificat X.509. La requête contiendra typiquement un clé publique ainsi que des informations nécessaires à l'enregistrement.
La construction d'une demande de certification implique les étapes suivantes:
un message de requête de certificat est constitué d'une requête demande de certificat, d'un champ preuve de possession optionnelle et d'un champ d'informations d'enregistrement complémentaire.
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
Le champ preuve de possession est utilisé afin de démontrer qui l'entité qui sera associée au certificat est en possession de la clé privée correspondante. Ce champ peut être calculé à partir du contenu du champ certReq. Il varie dans la structure, le contenu en fonction du type d'algorithme à clé publique et le mode opérationnel.
Le champ regInfo ne DEVRAIT contenir des informations complémentaires liés à la demande de certificat que lorsque ces informations sont requises pour satisfaire à la demande de certificat. Ces informations DEVRAIENT inclure un contact du demandeur, des informations de facturation ou tout autre information nécessaire à remplir la requête de certificat.
Cf section 8 et l'annexe B pour des exemple de contenu de regInfo.Afin de se prémunir d'un certain nombre d'attaques et également de permettre à une CA/RA de vérifier le lien entre l'EE et une paire de clés, le protocole de gestion PKI décrit ici permet à l'EE de prouver (en utilisant) qu'elle est en possession de la clé privée correspondant à la clé publique faisant l'objet de la demande certification. Une CA/RA est libre de choisir le moyen de POP dans ses transactions de certification (ex: par des transactions hors ligne en opposition à des messages CRMF en ligne). Toutefois il est requis que les CA et RA effectue une POP, car il y a actuellement de nombreux protocoles non-PKIX qui ne vérifient pas le lien entre l'EE et la clé privée. De plus il existe des protocole effectuant la vérification (pour la signature, le chiffrement et le partage de clé) de façon ambigüe. Cette vérification ne peut être effectuée que par la CA/RA. Si cette vérification n'est pas effectuée par la CA/RA alors les certificats des infrastructures à clés publiques perdent de leur pertinence.
La façon de réaliser une POP dépend su type de clé de la demande de certificat. Si cette clé peut être servir à différents usage, (par exemple RSA) alors n'importe quelle méthode correspondant peut être utilisée.
Cette spécification autorise les cas où une POP est effectuée par la CA, la RA ou les deux. Cetaines politiques de sécurité peuvent exiger que la POP soit effectuée par la CA. Dans ce cas la RA SOIT transmettre les champs CertRequest et ProofOfPossession à la CA sans modification, et optionellement procéder elle me à la POP. Si ce n'est pas réalisable (par exemple pour une vérification hors bande), alors la RA DEVRAIT attester auprès de la CA que des preuves suffisantes ont été vérifiées. Si la CA procède à une vérification hors ligne (par exemple par la remise de la clé privée physiquement) alors le champ ProofOfPossession n'est pas utilisé.
Pour les clés de signature, l'EE peut signer une valeur pour la POP de la clé privée.
Pour les clés de chiffrement de clé, l'EE peut fournir la clé de la RA/CA ou il peut lui être demandé de déchiffrer une valeur afin de prouver la possession de la clé privée.
La méthode directe est utilisée pour des CA/RA qui effectue un contrôle aléatoire dont la réponse est requise immédiatement.
La méthode indirecte consiste en l'émission d'un certificat chiffré pour la EE (et d'obtenir un message de confirmation du déchiffrement de la part de la EE). Cela permet à la CA d'émettre un certificat de façon à ce qu'il ne soit seulement utilisable par l'EE.
Pour les clés de partage, l'EE peut utiliser n'importe quelle méthode des 3 proposées dans la section 5.2 (?) des clés de chiffrement. Pour les méthodes directes et indirectes, l'EE et l'entité de contre de la PKI (c'est à dire la RA/CA) doivent établir une clé secrète partagée afin de prouver que la EE dispose de la clé privée (c'est à dire afin de déchiffrer le certificat chiffré ou de construire la réponse au challenge engagé). Remarquons que cela n'impose pas de restriction sur les clés qui peuvent être certifiées par une CA donnée, en particulier pour les clés de type Diffie-Hellman (DH) peut choisir librement ses paramètres, pourvu que la CA puisse générer la pair de clé avec les paramètres appropriés.
l'EE peut également apposer un MAC sur la requête de certificat (en utilisant une clé secrète partagée calculée d'un calcul DH) comme une quatrième alternative à la PoP. Cela ne peut être utilisé que si la CA dispose d'un certificat DH connu de la EE et si cette dernière accepte d'utliser les paramètres DH de la CA.
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- The signature (using "algorithmIdentifier") is on the
-- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
-- certReq CertTemplate contains the subject and publicKey values,
-- then poposkInput MUST be omitted and the signature MUST be
-- computed on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- the algorithm value shall be PasswordBasedMac
-- {1 2 840 113533 7 66 13}
-- the parameter value is PBMParameter
value BIT STRING }
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which must include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions given
-- in Appendix A.
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA/RA engage in challenge-response exchange with
-- end entity in order to prove private key possession
Il est attendu que les protocoles intégrant cette spécification, intègrent également la confirmation et les messages de réponse au challenge nécessaires à un protocole complet.
L'algorithme suivant DEVRAIT être utilisé lorsque publicKeyMAC est utilisée dans la structure POPOSigningKeyInput afin de prouver l'authenticité d'une requête
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
L'utilisation de PBMParameter pour calculer publicKeyMAC afin de d'authentifier l'origine d'une demande de certification d'une clé publique, se compose de deux étapes. La première consiste en l'utilisation d'une information secrète partagée pour produire la clé MAC. La seconde applique le MAC à la clé publique afin de produire une valeure authentifiée.
L'initilisation des algorithmes de la première étape suppose l'existence d'un secret partagé distribué de façon sûre entre la CA/RA et l'EE. la "salt value" est ajoutée au secret partagé et la fonction de non-collision (owf) est appliquées iterationCount fois; la "salt value" est la valeur d'entrée pour la première itération, les entrées des itérations suivantes correspondent à la sortie de l'itération précédente générant une clé K.
Dans la seconde étape, K et la clé publique constituent l'entrée de HMAC telle que documentée dans [HMAC] afin de produire une valeur pour publicKeyMAC comme suit:
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
where ipad and opad are defined in [RFC2104].
La syntaxe pour CertRequest consiste en un identifiant de requête, un gabarit du contenu du certificat, et une séquence optionnelle d'informations de contrôle.
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, -- Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one must be present
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
L'émetteur d'une CertRequest peut inclure une ou plusieurs valeurs de contrôle déstinées au traitement de la requête.
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
Le contrôles suivants sont définis (il est convenu que cette liste pourrait s'enrichir): regToken; authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; protocolEncrKey.
Un regToken de controle contient une information à usage unique (soit établie à partir d'une valeur secrète ou à partir d'une connaissance) destinée à être utilisé par la CA pour vérifier l'identité du sujet de la requête avant d'émettre le certificat. Lors de la réception d'une requête de certification, la CA vérifies l'information afin de confirmer l'identité prétendue dans la requête de certification.
La valeur de regToken peut être générée par la CA et transmise hors ligne au demandeur de certificat, ou alors être disponible pour à la fois la CA et le demandeur. La sécurité des moyens d'échanges hors ligne doivent tenir compte du risque qu'une CA accepte une valeure interceptée et provenant d'une personne que le demandeur attendu.
Le reToken de controle, pour l'initilisation d'une EE, alors que le controle authenticator (section 7.2) pourrait typiquement s'appliquer aussi bien pour la demande de certificat initiale que pour les demandes ultérieures.
Dans certains cas d'usage, la valeur pour regToken pourrait être un chaîne de texte ou une quantité numérique comme un nombre aléatoire. La valeur dans le second cas pourrait être encodé comme une quantité binaire ou un chaîne texte représentative de la quantité binaire. Pour s'assure un encodage cohérent des valeur indépendemment de la nature de la quantité, l'encodage de regToken DEVRAIT être en UTF8.
Un contrôle authenticator contient de l'information non périmé utilisée pour établir une vérification non-crytpographique de l'identité lors de la communication avec la CA. Les cas suivants sont donnés à titre d'exemple: Le nom de jeune fille de la mère, les 4 derniers chiffres du numéro de sécurité social, une hash de ces informations ou tout autre information basée sur un savoir commun partagé avec le demandeur et la CA. La valeur de ce authenticator de contrôle peut être généré par la CA ou le demandeur.
Dans certaines cas d'utilisation la valeur regToken peut être une chaine de texte une quantité numéraire ou un nombre aléatoire. Pour garantir l'unifomité des encodages indépendemment de la nature de la quantité, l'encodage de l'authenticator DEVRA être UTF8.
Le contrôle pkiPublicationInfo permet au demandeur de contrôler le publication du certificat par la CA. Il est défini par la syntaxe suivante:
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
Si l'option dontPublish est choisie, le requêteur indique la PKI ne devrait pas publier le certificat (cela pourrait indiquer que le requêteur a l'intention de publier le certificat par ses propres moyens).
Si la l'option dontCare est choisie, ou si le contrôle PKIPublicationInfo de la requête est ignoré, le requêteur indique alors que la PKI PEUT publier le certificat en choisissant librement le moyen.
Si le demandeur souhaite que le certificat soit publié à certains points et souhaite également permettre à la CA de le rendre disponible dans d'autres points deux valeures de pubInfos de la structure SinglePubInfo doivent être utilisées: une avec x500, web ou ldap et une avec dontCare.
Le champ pubLocation, si valorisé, indique là ou le demandeur souhaite voir son certificat publié (Le CHOICE de GeneralName peut inclure par exemple une URL et une adresse IP).
Le contrôle pkiArchiveOptions permet au demandeur de fournir l'information demandée pour établir un archivage de la clé privée correspondant à la clé publique de la demande de certification. Il est défini par la syntaxe suivante:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair which the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
KeyGenParameters ::= OCTET STRING
Une alternative à l'envoi de la clé consiste en la fourniture des informations permettant de régénrer la clé en utlisisant KeyGenParameters (par exemple pour beaucoup d'implémentation de RSA il est possible de fournir les premier nombre aléatoires servant de test de primalité). La syntaxe réelle de ce paramètre pourra être définie dans une version ultérieure de ce document ou dans un autre standard.
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
Si présent, le controle protocolEncrKey spécifie une clé que la CA devra utiliser pour chiffrer la réponse à CertReqMessage.
Ce contrôle peut être utilisé lorsque la CA une information à envoyer au demandeur qui nécessite d'être chiffrée. Une telle information peut être une clé privée générée par la CA à l'usage du demandeur.
L'encodage de protocolEncrKey DEVRAIT être SubjectPublicKeyInfo.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax OCTET STRING
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax CertRequest
La sécurité des échanges CRMF est basée sur les mécanismes de sécurité du protocole et des moyens utilisés pour communiquer avec les CA. De tels protocoles ou mécanismes nécessitent de s'assurer de l'intégrité des données, l'authenticité de la provenance de celles-ci ainsi que la confidentialité du message. Le chiffrement des CRMF est fortement recommandée si ils contiennent des données du demandeur sensibles et si la CE dispose d'un certificat de chiffrement accessible à l'EE.
Cette annexe décrit la méthode de calcul de la chaîne de bit "dhMAC" de la structure POPOPrivKey de la PoP pour les requêtes de certificats Diffie-Hellman.
CApub = g^x mod p (g et p sont les paramètres convenus et x est la
partie privée de correspondant au certificat DH de la CA).
DH valeur privée = y
Epub = DH valeur publique = g^y mod p
secret partagé = Kec = g^xy mod p
K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)
SHA1(K XOR opad, SHA1(K XOR ipad, text))
where,
opad (outer pad) = the byte 0x36 repeated 64 times
and
ipad (inner pad) = the byte 0x5C repeated 64 times.
Le champ "value" de la chaîne d'octet id-regInfo-utf8Pairs (avec le champ 'tag" égal à 12 et la valeur appropriée dans le champ "length") contiendra des séries de paires de noms/valeures UTF8.
Cet annexe liste quelques exemples répandus de telles paires dans le but de promouvoir l'interopérabilité entre les différentes implémentations de cette spécification. Il est entendu que cette liste n'est pas exhaustive est grandira avec les expériences d'implémentations.
Lorsque regInfo est utilisé pour transporter des paires name-values (via id-regInfo-utf8Pairs), la première et les suivantes DEVRAIENT être structurées comme suit:
[name?value][%name?value]*%
La table suivante définie un ensemble recommandés d'éléments nommés. La valeur dans la colonne "Name Value" est la chaîne exacte qui apparaît dans regInfo.
Name Value
----------
version -- version of this variation of regInfo use
corp_company -- company affiliation of subscriber
org_unit -- organizational unit
mail_firstName -- personal name component
mail_middleName -- personal name component
mail_lastName -- personal name component
mail_email -- subscriber's email address
jobTitle -- job title of subscriber
employeeID -- employee identification number or string
mailStop -- mail stop
issuerName -- name of CA
subjectName -- name of Subject
validity -- validity interval
version?1%corp_company?Acme, Inc.%org_unit?Engineering%
mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
mail_email?john@acme.com%
Lorsqu'ils apparaissent dans id-regInfo-utf8Pairs en tant que qu'éléments nommés, les valeures encodées de issuerName, subjectName, et validity DEVRAIT utiliser la syntaxe suivante. Les caractères [] indiquent les champs optionnels, ::= et | ont le sens sens habituel BNF, et tous les autres symboles (à l'exception des espaces qui sont insignifiants) en dehors des non terminaux sont terminaux. Les caratères alphabétiques sont sensibles à la casse.
issuerName ::= < names >
subjectName ::= < names >
< names > ::= < name > | < names >:< name >
< validity > ::= validity ? [< notbefore >]-[< notafter >]
< notbefore > ::= < time >
< notafter > ::= < time >
validity?-19991231%
Chaque nom consiste en un unique champ identifiant de caractères suivit par une valeur de nom d'un ou plusieurs caractères UTF8. Dans une valeur de nom, lorsqu'il est nécessaire de clarifier un caractère dont le formatage peut prendre une autre signification, la séquence d'échappement %xx DEVRA être utilisée, xx représentant la valeur hexadécimale pour l'encodage concerné. le symbole pourcent étant représenté par %%
< name > ::= X< xname >|O< oname >|E< ename >|D< dname >|U< uname >|I< iname >
< xname > ::= < rdns >
< rdns > ::= < rdn > | < rdns > , < rdn >
< rdn > ::= < avas >
< avas > ::= < ava > | < avas > + < ava >
< ava > ::= < attyp > = < avalue >
< attyp > ::= OID.< oid > | < stdat >
C (country)
L (locality)
ST (state or province)
O (organization)
OU (organizational unit)
CN (common name)
STREET (street address)
E (E-mail address).
< avalue > est le nom d'un composant au format d'une chaîne de caractère UTF8 de 1 à 64 caractères avec pour restriction seuls les éléments de la structure ASN.1 PrintableString peuvent être utilisés dans le jeu IA5 UTF8.
Other name form (identifier "O"):
::= ,
E-mail address (rfc822name) name form (identifier "E"):
< ename > ::= < ia5string >
DNS name form (identifier "D"):
< dname > ::= < ia5string >
URI name form (identifier "U"):
< uname > ::= < ia5string >
IP address (identifier "I"):
< iname > ::= < oid >
issuerName?XOU=Our CA,O=Acme,C=US%
subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December 1994.
PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}
CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier
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)}
-- Certificate Extensions (X.509)
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)}
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms(1) };
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, -- Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one MUST be present
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- The signature (using "algorithmIdentifier") is on the
-- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
-- certReq CertTemplate contains the subject and publicKey values,
-- then poposkInput MUST be omitted and the signature MUST be
-- computed on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value BIT STRING }
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which MUST include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions given
-- in Appendix A.
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA engage in challenge-response exchange with
-- end entity in order to prove private key possession
-- Object identifier assignments --
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- The following definition may be uncommented for use with
-- ASN.1 compilers which do not understand UTF8String.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair which the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- the encrypted value itself
KeyGenParameters ::= OCTET STRING
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
END