-- the CA MAY provide additional certificates to the end
-- entity
Certificate confirm; certConf
Field Value
sender present
-- same as in ir
recipient CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
senderNonce present
-- 128 (pseudo-) random bits
recipNonce present
-- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The
-- MAC is based on the initial authentication key shared
-- between the EE and the CA.
senderKID referenceNum
-- the reference number which the CA has previously issued
-- to the end entity (together with the MACing key)
body certConf
-- see Section 5.3.18, "PKI Confirmation Content", for the
-- contents of the certConf fields.
-- Note: two CertStatus structures are required if both an
-- encryption and a signing certificate were sent.
protection present
-- bits calculated using MSG_MAC_ALG
Confirmation; PKIConf
Field Value
sender present
-- same as in ip
recipient present
-- sender name from certConf
transactionID present
-- value from certConf message
senderNonce present
-- 128 (pseudo-) random bits
recipNonce present
-- value from senderNonce from certConf message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message.
senderKID referenceNum
body PKIConf
protection present
-- bits calculated using MSG_MAC_ALG
D.5. Certificate Request
An (initialized) end entity requests a certificate from a CA (for any
reason). When the CA responds with a message containing a
certificate, the end entity replies with a certificate confirmation.
The CA replies with a PKIConfirm, to close the transaction. All
messages are authenticated.
The profile for this exchange is identical to that given in Appendix
D.4, with the following exceptions:
o sender name SHOULD be present
o protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
also be supported) in request, response, certConfirm, and
PKIConfirm messages;
o senderKID and recipKID are only present if required for message
verification;
o body is cr or cp;
o body may contain one or two CertReqMsg structures, but either
CertReqMsg may be used to request certification of a locally-
generated public key or a centrally-generated public key (i.e.,
the position-dependence requirement of Appendix D.4 is removed);
o protection bits are calculated according to the protectionAlg
field.
D.6. Key Update Request
An (initialized) end entity requests a certificate from a CA (to
update the key pair and/or corresponding certificate that it already
possesses). When the CA responds with a message containing a
certificate, the end entity replies with a certificate confirmation.
The CA replies with a PKIConfirm, to close the transaction. All
messages are authenticated.
The profile for this exchange is identical to that given in Appendix
D.4, with the following exceptions:
1. sender name SHOULD be present
2. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
also be supported) in request, response, certConfirm, and
PKIConfirm messages;
3. senderKID and recipKID are only present if required for message
verification;
4. body is kur or kup;
5. body may contain one or two CertReqMsg structures, but either
CertReqMsg may be used to request certification of a locally-
generated public key or a centrally-generated public key (i.e.,
the position-dependence requirement of Appendix D.4 is removed);
6. protection bits are calculated according to the protectionAlg
field;
7. regCtrl OldCertId SHOULD be used (unless it is clear to both
sender and receiver -- by means not specified in this document --
that it is not needed).
Appendix E. PKI Management Message Profiles (OPTIONAL).
This appendix contains detailed profiles for those PKIMessages that
MAY be supported by implementations (in addition to the messages
which MUST be supported; see Section 6 and Appendix D).
Profiles for the PKIMessages used in the following PKI management
operations are provided:
o root CA key update
o information request/response
o cross-certification request/response (1-way)
o in-band initialization using external identity certificate
Later versions of this document may extend the above to include
profiles for the operations listed below (along with other
operations, if desired).
o revocation request
o certificate publication
o CRL publication
E.1. General Rules for Interpretation of These Profiles.
Identical to Appendix D.1.
E.2. Algorithm Use Profile
Identical to Appendix D.2.
E.3. Self-Signed Certificates
Profile of how a Certificate structure may be "self-signed". These
structures are used for distribution of CA public keys. This can
occur in one of three ways (see Section 4.4 above for a description
of the use of these structures):
Type Function
-----------------------------------------------------------------
newWithNew a true "self-signed" certificate; the contained
public key MUST be usable to verify the signature
(though this provides only integrity and no
authentication whatsoever)
oldWithNew previous root CA public key signed with new private key
newWithOld new root CA public key signed with previous private key
Such certificates (including relevant extensions) must contain
"sensible" values for all fields. For example, when present,
subjectAltName MUST be identical to issuerAltName, and, when present,
keyIdentifiers must contain appropriate values, et cetera.
E.4. Root CA Key Update
A root CA updates its key pair. It then produces a CA key update
announcement message that can be made available (via some transport
mechanism) to the relevant end entities. A confirmation message is
NOT REQUIRED from the end entities.
ckuann message:
Field Value Comment
--------------------------------------------------------------
sender CA name CA name
body ckuann(CAKeyUpdAnnContent)
oldWithNew present see Appendix E.3 above
newWithOld present see Appendix E.3 above
newWithNew present see Appendix E.3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
the new private key)
E.5. PKI Information Request/Response
The end entity sends a general message to the PKI requesting details
that will be required for later PKI management operations. RA/CA
responds with a general response. If an RA generates the response,
then it will simply forward the equivalent message that it previously
received from the CA, with the possible addition of certificates to
the extraCerts fields of the PKIMessage. A confirmation message is
NOT REQUIRED from the end entity.
Message Flows:
Step# End entity PKI
1 format genm
2 -> genm ->
3 handle genm
4 produce genp
5 <- genp <-
6 handle genp
genM:
Field Value
recipient CA name
-- the name of the CA as contained in issuerAltName
-- extensions or issuer fields within certificates
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
SenderKID present if required
-- must be present if required for verification of message
-- protection
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- all relevant information requested
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
genP:
Field Value
sender CA name
-- name of the CA which produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message
-- protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for
-- the CA (e.g., private key for recovery purposes)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers that this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers that
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm that this CA expects to be used
-- in later PKI messages (for encryption)
CAKeyUpdateInfo optionally present, with
relevant value
-- the CA MAY provide information about a relevant root CA
-- key pair using this field (note that this does not imply
-- that the responding CA is the root CA in question)
CurrentCRL optionally present, with relevant value
-- the CA MAY provide a copy of a complete CRL (i.e.,
-- fullest possible one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end
-- entity. An RA MAY add its certificate here.
E.6. Cross Certification Request/Response (1-way)
Creation of a single cross-certificate (i.e., not two at once). The
requesting CA MAY choose who is responsible for publication of the
cross-certificate created by the responding CA through use of the
PKIPublicationInfo control.
Preconditions:
1. Responding CA can verify the origin of the request (possibly
requiring out-of-band means) before processing the request.
2. Requesting CA can authenticate the authenticity of the origin of
the response (possibly requiring out-of-band means) before
processing the response
The use of certificate confirmation and the corresponding server
confirmation is determined by the generalInfo field in the PKIHeader
(see Section 5.1.1). The following profile does not mandate support
for either confirmation.
Message Flows:
Step# Requesting CA Responding CA
1 format ccr
2 -> ccr ->
3 handle ccr
4 produce ccp
5 <- ccp <-
6 handle ccp
ccr:
Field Value
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
-- must be present if required for verification of message
-- protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross certificates are required, they MUST be
-- packaged in separate PKIMessages
certTemplate present
-- details follow
version v1 or v3
-- v3 STRONGLY RECOMMENDED
signingAlg present
-- the requesting CA must know in advance with which algorithm it
-- wishes the certificate to be signed
subject present
-- may be NULL-DN only if subjectAltNames extension value proposed
validity present
-- MUST be completely specified (i.e., both fields present)
issuer present
-- may be NULL-DN only if issuerAltNames extension value proposed
publicKey present
-- the key to be certified (which must be for a signing algorithm)
extensions optionally present
-- a requesting CA must propose values for all extensions
-- that it requires to be in the cross-certificate
POPOSigningKey present
-- see Section D3: Proof-of-possession profile
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
ccp:
Field Value
sender Responding CA name
-- the name of the CA who produced the message
recipient Requesting CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this message
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
transactionID present
-- value from corresponding ccr message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be
-- packaged in separate PKIMessages
response present
status present
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- accepted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST
-- be absent
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection
-- then certifiedKeyPair MUST be absent and failInfo MUST be
-- present and contain appropriate bit settings
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
E.7. In-Band Initialization Using External Identity Certificate
An (uninitialized) end entity wishes to initialize into the PKI with
a CA, CA-1. It uses, for authentication purposes, a pre-existing
identity certificate issued by another (external) CA, CA-X. A trust
relationship must already have been established between CA-1 and CA-X
so that CA-1 can validate the EE identity certificate signed by CA-X.
Furthermore, some mechanism must already have been established within
the Personal Security Environment (PSE) of the EE that would allow it
to authenticate and verify PKIMessages signed by CA-1 (as one
example, the PSE may contain a certificate issued for the public key
of CA-1, signed by another CA that the EE trusts on the basis of
out-of-band authentication techniques).
The EE sends an initialization request to start the transaction.
When CA-1 responds with a message containing the new certificate, the
end entity replies with a certificate confirmation. CA-1 replies
with a PKIConfirm to close the transaction. All messages are signed
(the EE messages are signed using the private key that corresponds to
the public key in its external identity certificate; the CA-1
messages are signed using the private key that corresponds to the
public key in a
certificate that can be chained to a trust anchor in the EE’s PSE).
The profile for this exchange is identical to that given in Appendix
D.4, with the following exceptions:
o the EE and CA-1 do not share a symmetric MACing key (i.e., there
is no out-of-band shared secret information between these
entities);
o sender name in ir MUST be present (and identical to the subject
name present in the external identity certificate);
o protectionAlg of MSG_SIG_ALG MUST be used in all messages;
o external identity cert. MUST be carried in ir extraCerts field
o senderKID and recipKID are not used;
o body is ir or ip;
o protection bits are calculated according to the protectionAlg
field.
Appendix F. Compilable ASN.1 Definitions
PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-cmp2000(16)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Certificate, CertificateList, Extensions, AlgorithmIdentifier,
UTF8String -- if required; otherwise, comment out
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, KeyIdentifier
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)}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF-2005 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf2005(36)}
-- see also the behavioral clarifications to CRMF codified in
-- Appendix C of this specification
CertificationRequest
FROM PKCS-10 {iso(1) member-body(2)
us(840) rsadsi(113549)
pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}
-- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT
-- tags). Alternatively, implementers may directly include
-- the [PKCS10] syntax in this module
;
-- the rest of the module contains locally-defined OIDs and
-- constructs
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, WAP WTLS certificates, or other kinds
-- of certificates) within this certificate management protocol,
-- should a need ever arise to support such generality. Those
-- implementations that do not foresee a need to ever support
-- other certificate types MAY, if they wish, comment out the