RFC 4210

7. Version Negotiation
This section defines the version negotiation used to support older
protocols between client and servers.
If a client knows the protocol version(s) supported by the server
(e.g., from a previous PKIMessage exchange or via some out-of-band
means), then it MUST send a PKIMessage with the highest version
supported by both it and the server. If a client does not know what
version(s) the server supports, then it MUST send a PKIMessage using
the highest version it supports.
If a server receives a message with a version that it supports, then
the version of the response message MUST be the same as the received
version. If a server receives a message with a version higher or
lower than it supports, then it MUST send back an ErrorMsg with the
unsupportedVersion bit set (in the failureInfo field of the
pKIStatusInfo). If the received version is higher than the highest
supported version, then the version in the error message MUST be the
highest version the server supports; if the received version is lower
than the lowest supported version then the version in the error
message MUST be the lowest version the server supports.
If a client gets back an ErrorMsgContent with the unsupportedVersion
bit set and a version it supports, then it MAY retry the request with
that version.
7.1. Supporting RFC 2510 Implementations
RFC 2510 did not specify the behaviour of implementations receiving
versions they did not understand since there was only one version in
existence. With the introduction of the present revision of the
specification, the following versioning behaviour is recommended.
7.1.1. Clients Talking to RFC 2510 Servers
If, after sending a cmp2000 message, a client receives an
ErrorMsgContent with a version of cmp1999, then it MUST abort the
current transaction. It MAY subsequently retry the transaction using
version cmp1999 messages.
If a client receives a non-error PKIMessage with a version of
cmp1999, then it MAY decide to continue the transaction (if the
transaction hasn't finished) using RFC 2510 semantics. If it does
not choose to do so and the transaction is not finished, then it MUST
abort the transaction and send an ErrorMsgContent with a version of
cmp1999.

7.1.2. Servers Receiving Version cmp1999 PKIMessages
If a server receives a version cmp1999 message it MAY revert to RFC
2510 behaviour and respond with version cmp1999 messages. If it does
not choose to do so, then it MUST send back an ErrorMsgContent as
described above in Section 7.
8. Security Considerations
8.1. Proof-Of-Possession with a Decryption Key
Some cryptographic considerations are worth explicitly spelling out.
In the protocols specified above, when an end entity is required to
prove possession of a decryption key, it is effectively challenged to
decrypt something (its own certificate). This scheme (and many
others!) could be vulnerable to an attack if the possessor of the
decryption key in question could be fooled into decrypting an
arbitrary challenge and returning the cleartext to an attacker.
Although in this specification a number of other failures in security
are required in order for this attack to succeed, it is conceivable
that some future services (e.g., notary, trusted time) could
potentially be vulnerable to such attacks. For this reason, we re-
iterate the general rule that implementations should be very careful
about decrypting arbitrary "ciphertext" and revealing recovered
"plaintext" since such a practice can lead to serious security
vulnerabilities.
8.2. Proof-Of-Possession by Exposing the Private Key
Note also that exposing a private key to the CA/RA as a proof-of-
possession technique can carry some security risks (depending upon
whether or not the CA/RA can be trusted to handle such material
appropriately). Implementers are advised to:
Exercise caution in selecting and using this particular POP
mechanism
When appropriate, have the user of the application explicitly
state that they are willing to trust the CA/RA to have a copy of
their private key before proceeding to reveal the private key.
8.3. Attack Against Diffie-Hellman Key Exchange
A small subgroup attack during a Diffie-Hellman key exchange may be
carried out as follows. A malicious end entity may deliberately
choose D-H parameters that enable him/her to derive (a significant
number of bits of) the D-H private key of the CA during a key
archival or key recovery operation. Armed with this knowledge, the

EE would then be able to retrieve the decryption private key of
another unsuspecting end entity, EE2, during EE2's legitimate key
archival or key recovery operation with that CA. In order to avoid
the possibility of such an attack, two courses of action are
available. (1) The CA may generate a fresh D-H key pair to be used
as a protocol encryption key pair for each EE with which it
interacts. (2) The CA may enter into a key validation protocol (not
specified in this document) with each requesting end entity to ensure
that the EE's protocol encryption key pair will not facilitate this
attack. Option (1) is clearly simpler (requiring no extra protocol
exchanges from either party) and is therefore RECOMMENDED.
9. IANA Considerations
The PKI General Message types are identified by object identifiers
(OIDs). The OIDs for the PKI General Message types defined in this
document were assigned from an arc delegated by the IANA to the PKIX
Working Group.
The cryptographic algorithms referred to in this document are
identified by object identifiers (OIDs). The OIDs for cryptographic
algorithms were assigned from several arcs owned by various
organizations, including RSA Security, Entrust Technologies, IANA and
IETF.
Should additional encryption algorithms be introduced, the advocates
for such algorithms are expected to assign the necessary OIDs from
their own arcs.
No further action by the IANA is necessary for this document or any
anticipated updates.
Normative References
[X509] International Organization for Standardization and
International Telecommunications Union, "Information
technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate
frameworks", ISO Standard 9594-8:2001, ITU-T
Recommendation X.509, March 2000.
[MvOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press ISBN 0-8493-8523-7,
1996.

Appendix A. Reasons for the Presence of RAs
The reasons that justify the presence of an RA can be split into
those that are due to technical factors and those which are
organizational in nature. Technical reasons include the following.
o If hardware tokens are in use, then not all end entities will have
the equipment needed to initialize these; the RA equipment can
include the necessary functionality (this may also be a matter of
policy).
o Some end entities may not have the capability to publish
certificates; again, the RA may be suitably placed for this.
o The RA will be able to issue signed revocation requests on behalf
of end entities associated with it, whereas the end entity may not
be able to do this (if the key pair is completely lost).
Some of the organizational reasons that argue for the presence of an
RA are the following.
o It may be more cost effective to concentrate functionality in the
RA equipment than to supply functionality to all end entities
(especially if special token initialization equipment is to be
used).
o Establishing RAs within an organization can reduce the number of
CAs required, which is sometimes desirable.
o RAs may be better placed to identify people with their
"electronic" names, especially if the CA is physically remote from
the end entity.
o For many applications, there will already be in place some
administrative structure so that candidates for the role of RA are
easy to find (which may not be true of the CA).
Appendix B. The Use of Revocation Passphrase
A revocation request must incorporate suitable security mechanisms,
including proper authentication, in order to reduce the probability
of successful denial-of-service attacks. A digital signature on the
request -- MANDATORY to support within this specification if
revocation requests are supported -- can provide the authentication
required, but there are circumstances under which an alternative
mechanism may be desirable (e.g., when the private key is no longer
accessible and the entity wishes to request a revocation prior to
re-certification of another key pair). In order to accommodate such

circumstances, a PasswordBasedMAC on the request is also MANDATORY to
support within this specification (subject to local security policy
for a given environment) if revocation requests are supported and if
shared secret information can be established between the requester
and the responder prior to the need for revocation.
A mechanism that has seen use in some environments is "revocation
passphrase", in which a value of sufficient entropy (i.e., a
relatively long passphrase rather than a short password) is shared
between (only) the entity and the CA/RA at some point prior to
revocation; this value is later used to authenticate the revocation
request.
In this specification, the following technique to establish shared
secret information (i.e., a revocation passphrase) is OPTIONAL to
support. Its precise use in CMP messages is as follows.
o The OID and value specified in Section 5.3.19.9 MAY be sent in a
GenMsg message at any time, or MAY be sent in the generalInfo
field of the PKIHeader of any PKIMessage at any time. (In
particular, the EncryptedValue may be sent in the header of the
certConf message that confirms acceptance of certificates
requested in an initialization request or certificate request
message.) This conveys a revocation passphrase chosen by the
entity (i.e., the decrypted bytes of the encValue field) to the
relevant CA/RA; furthermore, the transfer is accomplished with
appropriate confidentiality characteristics (because the
passphrase is encrypted under the CA/RA's protocolEncryptionKey).
o If a CA/RA receives the revocation passphrase (OID and value
specified in Section 5.3.19.9) in a GenMsg, it MUST construct and
send a GenRep message that includes the OID (with absent value)
specified in Section 5.3.19.9. If the CA/RA receives the
revocation passphrase in the generalInfo field of a PKIHeader of
any PKIMessage, it MUST include the OID (with absent value) in the
generalInfo field of the PKIHeader of the corresponding response
PKIMessage. If the CA/RA is unable to return the appropriate
response message for any reason, it MUST send an error message
with a status of "rejection" and, optionally, a failInfo reason
set.
o The valueHint field of EncryptedValue MAY contain a key identifier
(chosen by the entity, along with the passphrase itself) to assist
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

}
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
-- 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).