a) A CertRequest value is constructed. This value may include
public key, all or a portion of the end-entity's (EE's) name
other requestedcertificate fields, and additional information related to the registration process
b) A proof of possession (of the private key corresponding to
public key for which a certificate is being requested) value
be calculated across the CertRequest value
CertReqMsg ::= SEQUENCE {
certReq CertRequest
pop ProofOfPossession OPTIONAL
-- content depends upon key
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
The proof of possession field is used to demonstrate that the
to be associated with the certificate is actually in possession
the corresponding private key. This field may be calculated
the contents of the certReq field and varies in structure and
by public key algorithm type and operational mode
Information directly related to certificate content SHOULD included in the certReq content. However, inclusion of
certReq content by RAs may invalidate the pop field. Data
intended for certificate content MAY be provided in regInfo
In order to prevent certain attacks and to allow a CA/RA to
check the validity of the binding between an end entity and a
pair, the PKI managementoperationsspecified here make it
for an end entity to prove that it has possession of (i.e., is
to use) the private key corresponding to the public key for which certificate is requested. A given CA/RA is free to choose how
enforce POP (e.g., out-of-band procedural means versus the CRMF in
band message) in its certification exchanges (i.e., this may be
policy issue). However, it is MANDATED that CAs/RAs MUST enforce
by some means because there are currently many non-PKIX
protocols in use (various electronic mail protocols are one example
that do not explicitly check the binding between the end entity
the private key. Until operational protocols that do verify
binding (for signature, encryption, and key agreement key pairs
exist, and are ubiquitous, this binding can only be assumed to
been verified by the CA/RA. Therefore, if the binding is not
by the CA/RA, certificates in the Internet Public-Key
end up being somewhat less meaningful
POP is accomplished in different ways depending on the type of
for which a certificate is requested. If a key can be used multiplepurposes (e.g., an RSA key) then any of the methods MAY
used
This specification allows for cases where POP is validated by the CA
the RA, or both. Some policies may require the CA to verify
during certification, in which case the RA MUST forward the
entity's CertRequest and ProofOfPossession fields unaltered to
CA, and as an option MAY also verify POP. If the CA is not
by policy to verify POP, then the RA SHOULD forward the end entity'
request and proof unaltered to the CA as above. If this is possible (for example because the RA verifies POP by an out-of-
method), then the RA MAY attest to the CA that the required proof
been validated. If the CA uses an out-of-band method to verify
(such as physicaldelivery of CA-generated private keys), then
ProofOfPossession field is not used
For key encipherment keys, the end entity can provide the private
to the CA/RA, or can be required to decrypt a value in order to
possession of the private key. Decrypting a value can be
either directly or indirectly
The indirect method is to issue a certificate which is encrypted
the end entity (and have the end entity demonstrate its ability
decrypt this certificate in a confirmation message). This allows a
to issue a certificate in a form which can only be used by
intended end entity
For key agreement keys, the end entity can use any of the
methods given in Section 5.2 for encryption keys. For the direct indirect methods, the end entity and the PKI management entity (i.e.,
CA or RA) must establish a shared secret key in order to prove
the end entity has possession of the private key (i.e., in order
decrypt the encryptedcertificate or to construct the response to
issued challenge). Note that this need not impose any
on the keys that can be certified by a given CA -- in particular,
Diffie-Hellman keys the end entity may freely choose its parameters -- provided that the CA can generate a short-term (
one-time) key pair with the appropriateparameters when necessary
The end entity may also MAC the certificate request (using a
secret key derived from a Diffie-Hellman computation) as a alternative for demonstrating POP. This option may be used only
the CA already has a DH certificate that is known to the end
and if the EE is willing to use the CA's DH parameters
4.4 Proof of Possession
ProofOfPossession ::= CHOICE {
raVerified [0] NULL
-- used if the RA has already verified that the requester is
-- possession of the private signature [1] POPOSigningKey
keyEncipherment [2] POPOPrivKey
keyAgreement [3] POPOPrivKey }
algorithmIdentifier AlgorithmIdentifier signature BIT STRING }
-- The signature (using "algorithmIdentifier") is on
-- DER-encoded value of poposkInput. NOTE: If the
-- certReq CertTemplate contains the subject and publicKey values
-- then poposkInput MUST be omitted and the signature MUST
-- computed on the DER-encoded value of CertReqMsg certReq.
-- the CertReqMsg certReq CertTemplate does not contain the
-- key and subject values, then poposkInput MUST be present
-- MUST be signed. This strategy ensures that the public key
-- not present in both the poposkInput and CertReqMsg
-- CertTemplate fields
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName
-- used only if an authenticatedidentity has
-- established for the sender (e.g., a DN from
-- previously-issued and currently-valid certificate
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists
-- the sender; publicKeyMAC contains a password-based
-- on the DER-encoded value of
publicKey SubjectPublicKeyInfo } -- from
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier
-- the algorithm value shall be
-- {1 2 840 113533 7 66 13}
-- the parameter value is
value BIT STRING }
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING
-- posession is proven in this message (which contains the
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage
-- possession will be proven in a subsequent
dhMAC [2] BIT STRING }
-- for keyAgreement (only), possession is proven in this
-- (which contains a MAC (over the DER-encoded value of
-- certReq parameter in CertReqMsg, which must include both
-- and publicKey) based on a key derived from the end entity'
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions
-- in Appendix A
The followingalgorithm SHALL be used when publicKeyMAC is used
POPOSigningKeyInput to prove the authenticity of a request
PBMParameter ::= SEQUENCE {
salt OCTET STRING
owf AlgorithmIdentifier
-- AlgId for a One-Way Function (SHA-1 recommended
iterationCount INTEGER
-- number of times the OWF is
mac
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
The process of using PBMParameter to compute publicKeyMAC and authenticate the origin of a public key certification consists of two stages. The first stage uses shared information to produce a MAC key. The second stage MACs the
key in question using this MAC key to produce an authenticated value
Initialization of the first stage of algorithm assumes the
of a shared secret distributed in a trusted fashion between CA/RA
end-entity. The salt value is appended to the shared secret and
one way function (owf) is applied iterationCount times, where
salted secret is the input to the first iteration and, for successive iteration, the input is set to be the output of previous iteration, yielding a key K
In the second stage, K and the public key are inputs to HMAC
documented in [HMAC] to produce a value for publicKeyMAC as follows
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and
certTemplate CertTemplate, -- Selected fields of cert to be
controls Controls OPTIONAL } -- Attributes affecting
The following controls are defined (it is recognized that this
may expand over time): regToken; authenticator; pkiPublicationInfo
pkiArchiveOptions; oldCertID; protocolEncrKey
The value for regToken may be generated by the CA and provided out
band to the subscriber, or may otherwise be available to both the
and the subscriber. The security of any out-of-band exchange
be commensurate with the risk of the CA accepting an
value from someone other than the intended subscriber
The regToken control would typically be used only for
of an end entity into the PKI, whereas the authenticator control (
Section 7.2) would typically be used for initial as well
subsequent certificationrequests
In some instances of use the value for regToken could be a
string or a numeric quantity such as a random number. The value
the latter case could be encoded either as a binary quantity or as
text string representation of the binary quantity. To ensure
uniform encoding of values regardless of the nature of the quantity
the encoding of regToken SHALL be UTF8.
In some instances of use the value for regToken could be a
string or a numeric quantity such as a random number. The value
the latter case could be encoded either as a binary quantity or as
text string representation of the binary quantity. To ensure
uniform encoding of values regardless of the nature of the quantity
the encoding of authenticator SHALL be UTF8.
If the dontCare method is chosen, or if the
control is omitted from the request, the requesterindicates that
PKI MAY publish the certificate using whatever means it chooses
If the requester wishes the certificate to appear in at least
locations but wishes to enable the CA to make the available in other repositories, set two values of SinglePubInfo
pubInfos: one with x500, web or ldap value and one with dontCare
The pubLocation field, if supplied, indicates where the
would like the certificate to be found (note that the CHOICE
GeneralName includes a URL and an IP address, for example).
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey
-- the actual value of the private
keyGenParameters [1] KeyGenParameters
-- parameters which allow the private key to be re-
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the
-- key of a key pair which the receiver generates in response
-- 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
-- encryptedContentInfo encryptedContent OCTET STRING
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL
-- the intended algorithm for which the value will be
symmAlg [1] AlgorithmIdentifier OPTIONAL
-- the symmetricalgorithm used to encrypt the
encSymmKey [2] BIT STRING OPTIONAL
-- the (encrypted) symmetric key used to encrypt the
keyAlg [3] AlgorithmIdentifier OPTIONAL
-- algorithm used to encrypt the symmetric
valueHint [4] OCTET STRING OPTIONAL
-- a brief description or identifier of the encValue
-- (may be meaningful only to the sending entity, and used
-- if EncryptedValue might be re-examined by the sending
-- in the future
encValue BIT STRING }
KeyGenParameters ::= OCTET
An alternative to sending the key is to send the information
how to re-generate the key using the KeyGenParameters choice (e.g.,
for many RSA implementations one could send the first random
tested for primality). The actual syntax for this parameter may
defined in a subsequent version of this document or in standard
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104, February 1997.
10.
The authors gratefully acknowledge the contributions of Barbara Fox
Warwick Ford, Russ Housley and John Pawling, whose review comments significantly clarified and improved the utility of specification
From CA's DH certificate
CApub = g^x mod p (where g and p are the established parameters and x is the CA's
DH component
For entity E
DH private value =
Epub = DH public value = g^y mod
2. The MACing process will then consist of the following steps
a) The value of the certReq field is DER encoded, yielding a
string. This will be the 'text' referred to in [HMAC], the data
which HMAC-SHA1 is applied
b) A shared DH secret is computed, as follows
shared secret = Kec = g^xy mod
[This is done by the entity E as CApub^y and by the CA as Epub^x
where CApub is retrieved from the CA's DH certificate and Epub
retrieved from the actual certification request.]
c) A key K is derived from the shared secret Kec and the subject
issuer names in the CA's certificate as follows
K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName
where "|" means concatenation. If subjectName in the certificate is an empty SEQUENCE then DER-encoded-
should be used instead; similarly, if issuerName is an SEQUENCE then DER-encoded-issuerAltName should be used instead
d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as
SHA1(K XOR opad, SHA1(K XOR ipad, text))
where
opad (outer pad) = the byte 0x36 repeated 64
ipad (inner pad) = the byte 0x5C repeated 64 times
Namely
(1) Append zeros to the end of K to create a 64 byte
(e.g., if K is of length 16 bytes it will be appended
48 zero bytes 0x00).
(2) XOR (bitwise exclusive-OR) the 64 byte string computed
step (1) with ipad
(3) Append the data stream 'text' to the 64 byte
resulting from step (2).
(4) Apply SHA1 to the stream generated in step (3).
(5) XOR (bitwise exclusive-OR) the 64 byte string computed
step (1) with opad
(6) Append the SHA1 result from step (4) to the 64 byte
resulting from step (5).
(7) Apply SHA1 to the stream generated in step (6) and
the result
Sample code is also provided in [RFC2104, RFC2202].
e) The output of (d) is encoded as a BIT STRING (the value "dhMAC").
3. The proof-of-possession process requires the CA to carry
steps (a) through (d) and then simply compare the result of
(d) with what it received as the "dhMAC" value. If they match
the following can be concluded
1) The Entity possesses the private key corresponding to
public key in the certification request (because it needed
private key to calculate the shared secret).
2) Only the intended CA can actually verify the request (
the CA requires its own private key to compute the same
secret). This helps to protect from rogue CAs
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Hashing for Message Authentication", RFC 2104,
1997.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC
SHA-1", RFC 2202, September 1997.
The "value" field of the id-regInfo-utf8Pairs OCTET STRING (
"tag" field equal to 12 and appropriate "length" field) will
a series of UTF8 name/value pairs
The following table defines a recommended set of named elements
The value in the column "Name Value" is the exact text string
will appear in the regInfo
Name
----------
version -- version of this variation of regInfo
corp_company -- company affiliation of
org_unit -- organizational
mail_firstName -- personal name
mail_middleName -- personal name
mail_lastName -- personal name
mail_email -- subscriber's email
jobTitle -- job title of
employeeID -- employee identification number or
When they appear in id-regInfo-utf8Pairs syntax as named elements
the encoding of values for issuerName, subjectName and validity
use the following syntax. The characters [] indicate an
field, ::= and | have their usual BNF meanings, and all other
(except spaces which are insignificant) outside non-terminal
are terminals. Alphabetics are case-sensitive
