in later retrieval of the correct passphrase (e.g., when the
revocation request is constructed by the entity and received by
the CA/RA).
o The revocation request message is protected by a PasswordBasedMAC,
with the revocation passphrase as the key. If appropriate, the
senderKID field in the PKIHeader MAY contain the value previously
transmitted in valueHint.
Using the technique specified above, the revocation passphrase may be
initially established and updated at any time without requiring extra
messages or out-of-band exchanges. For example, the revocation
request message itself (protected and authenticated through a MAC
that uses the revocation passphrase as a key) may contain, in the
PKIHeader, a new revocation passphrase to be used for authenticating
future revocation requests for any of the entity’s other
certificates. In some environments this may be preferable to
mechanisms that reveal the passphrase in the revocation request
message, since this can allow a denial-of-service attack in which the
revealed passphrase is used by an unauthorized third party to
authenticate revocation requests on the entity’s other certificates.
However, because the passphrase is not revealed in the request
message, there is no requirement that the passphrase must always be
updated when a revocation request is made (that is, the same
passphrase MAY be used by an entity to authenticate revocation
requests for different certificates at different times).
Furthermore, the above technique can provide strong cryptographic
protection over the entire revocation request message even when a
digital signature is not used. Techniques that do authentication of
the revocation request by simply revealing the revocation passphrase
typically do not provide cryptographic protection over the fields of
the request message (so that a request for revocation of one
certificate may be modified by an unauthorized third party to a
request for revocation of another certificate for that entity).
Appendix C. Request Message Behavioral Clarifications
In the case of updates to [CRMF], which cause interpretation or
interoperability issues, [CRMF] SHALL be the normative document.
The following definitions are from [CRMF]. They are included here in
order to codify behavioral clarifications to that request message;
otherwise, all syntax and semantics are identical to [CRMF].
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
-- If certTemplate is an empty SEQUENCE (i.e., all fields
-- omitted), then controls MAY contain the
-- id-regCtrl-altCertTemplate control, specifying a template
-- for a certificate other than an X.509v3 public-key
-- certificate. Conversely, if certTemplate is not empty
-- (i.e., at least one field is present), then controls MUST
-- NOT contain id-regCtrl- altCertTemplate. The new control is
-- defined as follows:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- **********
-- * For the purposes of this specification, the ASN.1 comment
-- * given in [CRMF] pertains not only to certTemplate, but
-- * also to the altCertTemplate control. That is,
-- **********
-- * The signature (using "algorithmIdentifier") is on the
-- * DER-encoded value of poposkInput (i.e., the "value" OCTETs
-- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg
-- * certReq certTemplate (or the altCertTemplate control)
-- * 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 (or the DER-
-- * encoded value of AltCertTemplate). If
-- * certTemplate/altCertTemplate does not contain both the
-- * subject and public key values (i.e., if it contains only
-- * one of these, or neither), then poposkInput MUST be present
-- * and MUST be signed.
-- **********
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- **********
-- * the type of "thisMessage" is given as BIT STRING in
-- * [CRMF]; it should be "EncryptedValue" (in accordance
-- * with Section 5.2.2, "Encrypted Values", of this specification).
-- * Therefore, this document makes the behavioral clarification
-- * of specifying that the contents of "thisMessage" MUST be encoded
-- * as an EncryptedValue and then wrapped in a BIT STRING. This
-- * allows the necessary conveyance and protection of the
-- * private key while maintaining bits-on-the-wire compatibility
-- * with [CRMF].
-- **********
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING }
Appendix D. PKI Management Message Profiles (REQUIRED).
This appendix contains detailed profiles for those PKIMessages that
MUST be supported by conforming implementations (see Section 6).
Profiles for the PKIMessages used in the following PKI management
operations are provided:
o initial registration/certification
o basic authenticated scheme
o certificate request
o key update
D.1. General Rules for Interpretation of These Profiles.
1. Where OPTIONAL or DEFAULT fields are not mentioned in individual
profiles, they SHOULD be absent from the relevant message (i.e.,
a receiver can validly reject a message containing such fields as
being syntactically incorrect). Mandatory fields are not
mentioned if they have an obvious value (e.g., in this version of
the specification, pvno is always 2).
2. Where structures occur in more than one message, they are
separately profiled as appropriate.
3. The algorithmIdentifiers from PKIMessage structures are profiled
separately.
4. A "special" X.500 DN is called the "NULL-DN"; this means a DN
containing a zero-length SEQUENCE OF RelativeDistinguishedNames
(its DER encoding is then ’3000’H).
5. Where a GeneralName is required for a field, but no suitable
value is available (e.g., an end entity produces a request before
knowing its name), then the GeneralName is to be an X.500 NULL-DN
(i.e., the Name field of the CHOICE is to contain a NULL-DN).
This special value can be called a "NULL-GeneralName".
6. Where a profile omits to specify the value for a GeneralName,
then the NULL-GeneralName value is to be present in the relevant
PKIMessage field. This occurs with the sender field of the
PKIHeader for some messages.
7. Where any ambiguity arises due to naming of fields, the profile
names these using a "dot" notation (e.g., "certTemplate.subject"
means the subject field within a field called certTemplate).
8. Where a "SEQUENCE OF types" is part of a message, a zero-based
array notation is used to describe fields within the SEQUENCE OF
(e.g., crm[0].certReq.certTemplate.subject refers to a subfield
of the first CertReqMsg contained in a request message).
9. All PKI message exchanges in Appendix D.4 to D.6 require a
certConf message to be sent by the initiating entity and a
PKIConfirm to be sent by the responding entity. The PKIConfirm
is not included in some of the profiles given since its body is
NULL and its header contents are clear from the context. Any
authenticated means can be used for the protectionAlg (e.g.,
password-based MAC, if shared secret information is known, or
signature).
D.2. Algorithm Use Profile
The following table contains definitions of algorithm uses within PKI
management protocols. The columns in the table are:
Name: an identifier used for message profiles
Use: description of where and for what the algorithm is used
Mandatory: an AlgorithmIdentifier which MUST be supported by
conforming implementations
Others: alternatives to the mandatory AlgorithmIdentifier
Name Use Mandatory Others
MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5,
messages using signature ECDSA, ...
MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC,
messages using MACing X9.9...
SYM_PENC_ALG symmetric encryption of 3-DES (3-key- AES,RC5,
an end entity’s private EDE, CBC mode) CAST-128...
key where symmetric
key is distributed
out-of-band
PROT_ENC_ALG asymmetric algorithm D-H RSA,
used for encryption of ECDH, ...
(symmetric keys for
encryption of) private
keys transported in
PKIMessages
PROT_SYM_ALG symmetric encryption 3-DES (3-key- AES,RC5,
algorithm used for EDE, CBC mode) CAST-128...
encryption of private
key bits (a key of this
type is encrypted using
PROT_ENC_ALG)
Mandatory AlgorithmIdentifiers and Specifications:
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}, with SHA-1 {1 3 14 3 2 26} as the
owf parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac
parameter;
(this specification), along with
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
}
D.3. Proof-of-Possession Profile
POP fields for use (in signature field of pop field of
ProofOfPossession structure) when proving possession of a private
signing key that corresponds to a public verification key for which a
certificate has been requested.
Field Value Comment
algorithmIdentifier MSG_SIG_ALG only signature protection is
allowed for this proof
signature present bits calculated using MSG_SIG_ALG
Proof-of-possession of a private decryption key that corresponds to a
public encryption key for which a certificate has been requested does
not use this profile; the CertHash field of the certConf message is
used instead.
Not every CA/RA will do Proof-of-Possession (of signing key,
decryption key, or key agreement key) in the PKIX-CMP in-band
certification request protocol (how POP is done MAY ultimately be a
policy issue that is made explicit for any given CA in its publicized
Policy OID and Certification Practice Statement). However, this
specification MANDATES that CA/RA entities MUST do POP (by some
means) as part of the certification process. All end entities MUST
be prepared to provide POP (i.e., these components of the PKIX-CMP
protocol MUST be supported).
D.4. Initial Registration/Certification (Basic Authenticated Scheme)
An (uninitialized) end entity requests a (first) certificate from a
CA. When the CA responds with a message containing a certificate,
the end entity replies with a certificate confirmation. The CA sends
a PKIConfirm back, closing the transaction. All messages are
authenticated.
This scheme allows the end entity to request certification of a
locally-generated public key (typically a signature key). The end
entity MAY also choose to request the centralized generation and
certification of another key pair (typically an encryption key pair).
Certification may only be requested for one locally generated public
key (for more, use separate PKIMessages).
The end entity MUST support proof-of-possession of the private key
associated with the locally-generated public key.
Preconditions:
1. The end entity can authenticate the CA’s signature based on out-
of-band means
2. The end entity and the CA share a symmetric MACing key
Message flow:
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
For this profile, we mandate that the end entity MUST include all
(i.e., one or two) CertReqMsg in a single PKIMessage, and that the
PKI (CA) MUST produce a single response PKIMessage that contains the
complete response (i.e., including the OPTIONAL second key pair, if
it was requested and if centralized key generation is supported).
For simplicity, we also mandate that this message MUST be the final
one (i.e., no use of "waiting" status value).
The end entity has an out-of-band interaction with the CA/RA. This
transaction established the shared secret, the referenceNumber and
OPTIONALLY the distinguished name used for both sender and subject
name in the certificate template. It is RECOMMENDED that the shared
secret be at least 12 characters long.
Initialization Request -- ir
Field Value
recipient CA name
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this request, based
-- on initial authentication key
senderKID referenceNum
-- the reference number which the CA has previously issued
-- to the end entity (together with the MACing key)
transactionID present
-- implementation-specific value, meaningful to end
-- entity.
-- [If already in use at the CA, then a rejection message MUST
-- be produced by the CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required, requests MUST be
-- packaged in separate PKIMessages
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first
-- (which MUST be present), crm[1] means the second (which
-- is OPTIONAL, and used to ask for a centrally-generated key)
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- proof-of-possession MAY be required in this exchange
-- (see Appendix D.3 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally-generated
-- private key be archived
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[1].certReq fixed value of one
certReqId
-- the index of the template within the message
crm[1].certReq present
certTemplate
-- MUST NOT include actual public key bits, otherwise
-- unconstrained (e.g., the names need not be the same as in
-- crm[0]). Note that subjectPublicKeyInfo MAY be present
-- and contain an AlgorithmIdentifier followed by a
-- zero-length BIT STRING for the subjectPublicKey if it is
-- desired to inform the CA/RA of algorithm and parameter
-- preferences regarding the to-be-generated key pair.
crm[1].certReq. present [object identifier MUST be PROT_ENC_ALG]
controls.protocolEncrKey
-- if centralized key generation is supported by this CA,
-- this short-term asymmetric encryption key (generated by
-- the end entity) will be used by the CA to encrypt (a
-- symmetric key used to encrypt) a private key generated by
-- the CA on behalf of the end entity
crm[1].certReq. optionally present
controls.archiveOptions
crm[1].certReq. optionally present
controls.publicationInfo
protection present
-- bits calculated using MSG_MAC_ALG
Initialization Response -- ip
Field Value
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MS_MAC_ALG
-- only MAC protection is allowed for this response
senderKID referenceNum
-- the reference number that the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
body ip (CertRepMessage)
contains exactly one response
for each request
-- The PKI (CA) responds to either one or two requests as
-- appropriate. crc[0] denotes the first (always present);
-- crc[1] denotes the second (only present if the ir message
-- contained two requests and if the CA supports centralized
-- key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the
-- corresponding ir message
crc[0].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"accepted" or "grantedWithMods"
certificate present unless end entity’s public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity’s
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present
-- at discretion of CA)
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "accepted"
or "grantedWithMods"
certificate present
privateKey present
-- see Appendix C, Request Message Behavioral Clarifications
publicationInfo optionally present
-- indicates where certificate has been published (present
-- at discretion of CA)
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present