RFC 4210
Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
Pages: 95
Proposed Standard
→ Errata
Obsoletes: 2510
Updated by: 6712 9480 9481
Proposed Standard
→ Errata
Obsoletes: 2510
Updated by: 6712 9480 9481
Part 2 of 5 – Pages 14 to 38
4. Assumptions and Restrictions
4.1. End Entity Initialization
The first step for an end entity in dealing with PKI management entities is to request information about the PKI functions supported and to securely acquire a copy of the relevant root CA public key(s).4.2. Initial Registration/Certification
There are many schemes that can be used to achieve initial registration and certification of end entities. No one method is suitable for all situations due to the range of policies that a CA may implement and the variation in the types of end entity which can occur. However, we can classify the initial registration/certification schemes that are supported by this specification. Note that the word "initial", above, is crucial: we are dealing with the situation where the end entity in question has had no previous contact with the PKI. Where the end entity already possesses certified keys, then some simplifications/alternatives are possible. Having classified the schemes that are supported by this specification we can then specify some as mandatory and some as optional. The goal is that the mandatory schemes cover a sufficient number of the cases that will arise in real use, whilst the optional schemes are available for special cases that arise less frequently. In this way, we achieve a balance between flexibility and ease of implementation. We will now describe the classification of initial registration/certification schemes.
4.2.1. Criteria Used
4.2.1.1. Initiation of Registration/Certification
In terms of the PKI messages that are produced, we can regard the initiation of the initial registration/certification exchanges as occurring wherever the first PKI message relating to the end entity is produced. Note that the real-world initiation of the registration/certification procedure may occur elsewhere (e.g., a personnel department may telephone an RA operator). The possible locations are at the end entity, an RA, or a CA.4.2.1.2. End Entity Message Origin Authentication
The on-line messages produced by the end entity that requires a certificate may be authenticated or not. The requirement here is to authenticate the origin of any messages from the end entity to the PKI (CA/RA). In this specification, such authentication is achieved by the PKI (CA/RA) issuing the end entity with a secret value (initial authentication key) and reference value (used to identify the secret value) via some out-of-band means. The initial authentication key can then be used to protect relevant PKI messages. Thus, we can classify the initial registration/certification scheme according to whether or not the on-line end entity -> PKI messages are authenticated or not. Note 1: We do not discuss the authentication of the PKI -> end entity messages here, as this is always REQUIRED. In any case, it can be achieved simply once the root-CA public key has been installed at the end entity's equipment or it can be based on the initial authentication key. Note 2: An initial registration/certification procedure can be secure where the messages from the end entity are authenticated via some out-of-band means (e.g., a subsequent visit).4.2.1.3. Location of Key Generation
In this specification, "key generation" is regarded as occurring wherever either the public or private component of a key pair first occurs in a PKIMessage. Note that this does not preclude a centralized key generation service; the actual key pair MAY have been
generated elsewhere and transported to the end entity, RA, or CA using a (proprietary or standardized) key generation request/response protocol (outside the scope of this specification). Thus, there are three possibilities for the location of "key generation": the end entity, an RA, or a CA.4.2.1.4. Confirmation of Successful Certification
Following the creation of an initial certificate for an end entity, additional assurance can be gained by having the end entity explicitly confirm successful receipt of the message containing (or indicating the creation of) the certificate. Naturally, this confirmation message must be protected (based on the initial authentication key or other means). This gives two further possibilities: confirmed or not.4.2.2. Mandatory Schemes
The criteria above allow for a large number of initial registration/certification schemes. This specification mandates that conforming CA equipment, RA equipment, and EE equipment MUST support the second scheme listed below (Section 4.2.2.2). Any entity MAY additionally support other schemes, if desired.4.2.2.1. Centralized Scheme
In terms of the classification above, this scheme is, in some ways, the simplest possible, where: o initiation occurs at the certifying CA; o no on-line message authentication is required; o "key generation" occurs at the certifying CA (see Section 4.2.1.3); o no confirmation message is required. In terms of message flow, this scheme means that the only message required is sent from the CA to the end entity. The message must contain the entire PSE for the end entity. Some out-of-band means must be provided to allow the end entity to authenticate the message received and to decrypt any encrypted values.
4.2.2.2. Basic Authenticated Scheme
In terms of the classification above, this scheme is where: o initiation occurs at the end entity; o message authentication is REQUIRED; o "key generation" occurs at the end entity (see Section 4.2.1.3); o a confirmation message is REQUIRED. In terms of message flow, the basic authenticated scheme is as follows: End entity RA/CA ========== ============= out-of-band distribution of Initial Authentication Key (IAK) and reference value (RA/CA -> EE) Key generation Creation of certification request Protect request with IAK -->>-- certification request -->>-- verify request process request create response --<<-- certification response --<<-- handle response create confirmation -->>-- cert conf message -->>-- verify confirmation create response --<<-- conf ack (optional) --<<-- handle response (Where verification of the cert confirmation message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.)4.3. Proof-of-Possession (POP) of Private Key
In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA is free to choose how to enforce POP (e.g., out-of-band procedural means versus PKIX-CMP
in-band messages) in its certification exchanges (i.e., this may be a policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful. POP is accomplished in different ways depending upon the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., an RSA key) then any appropriate method MAY be used (e.g., a key that may be used for signing, as well as other purposes, SHOULD NOT be sent to the CA/RA in order to prove possession). This specification explicitly allows for cases where an end entity supplies the relevant proof to an RA and the RA subsequently attests to the CA that the required proof has been received (and validated!). For example, an end entity wishing to have a signing key certified could send the appropriate signature to the RA, which then simply notifies the relevant CA that the end entity has supplied the required proof. Of course, such a situation may be disallowed by some policies (e.g., CAs may be the only entities permitted to verify POP during certification).4.3.1. Signature Keys
For signature keys, the end entity can sign a value to prove possession of the private key.4.3.2. Encryption Keys
For encryption keys, the end entity can provide the private key to the CA/RA, or can be required to decrypt a value in order to prove possession of the private key (see Section 5.2.8). Decrypting a value can be achieved either directly or indirectly. The direct method is for the RA/CA to issue a random challenge to which an immediate response by the EE is required.
The indirect method is to issue a certificate that is encrypted for
the end entity (and have the end entity demonstrate its ability to
decrypt this certificate in the confirmation message). This allows a
CA to issue a certificate in a form that can only be used by the
intended end entity.
This specification encourages use of the indirect method because it
requires no extra messages to be sent (i.e., the proof can be
demonstrated using the {request, response, confirmation} triple of
messages).
4.3.3. Key Agreement Keys
For key agreement keys, the end entity and the PKI management entity
(i.e., CA or RA) must establish a shared secret key in order to prove
that the end entity has possession of the private key.
Note that this need not impose any restrictions on the keys that can
be certified by a given CA. In particular, for Diffie-Hellman keys
the end entity may freely choose its algorithm parameters provided
that the CA can generate a short-term (or one-time) key pair with the
appropriate parameters when necessary.
4.4. Root CA Key Update
This discussion only applies to CAs that are directly trusted by some
end entities. Self-signed CAs SHALL be considered as directly
trusted CAs. Recognizing whether a non-self-signed CA is supposed to
be directly trusted for some end entities is a matter of CA policy
and is thus beyond the scope of this document.
The basis of the procedure described here is that the CA protects its
new public key using its previous private key and vice versa. Thus,
when a CA updates its key pair it must generate two extra
cACertificate attribute values if certificates are made available
using an X.500 directory (for a total of four: OldWithOld,
OldWithNew, NewWithOld, and NewWithNew).
When a CA changes its key pair, those entities who have acquired the
old CA public key via "out-of-band" means are most affected. It is
these end entities who will need access to the new CA public key
protected with the old CA private key. However, they will only
require this for a limited period (until they have acquired the new
CA public key via the "out-of-band" mechanism). This will typically
be easily achieved when these end entities' certificates expire.
The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required. Note 1. This scheme does not make use of any of the X.509 v3 extensions as it must be able to work even for version 1 certificates. The presence of the KeyIdentifier extension would make for efficiency improvements. Note 2. While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entities' certificates, this generalization seems of dubious value. Not having this generalization simply means that the validity periods of certificates issued with the old CA key pair cannot exceed the end of the OldWithNew validity period. Note 3. This scheme ensures that end entities will acquire the new CA public key, at the latest by the expiry of the last certificate they owned that was signed with the old CA private key (via the "out-of-band" means). Certificate and/or key update operations occurring at other times do not necessarily require this (depending on the end entity's equipment).4.4.1. CA Operator Actions
To change the key of the CA, the CA operator does the following: 1. Generate a new key pair; 2. Create a certificate containing the old CA public key signed with the new private key (the "old with new" certificate); 3. Create a certificate containing the new CA public key signed with the old private key (the "new with old" certificate); 4. Create a certificate containing the new CA public key signed with the new private key (the "new with new" certificate); 5. Publish these new certificates via the repository and/or other means (perhaps using a CAKeyUpdAnn message); 6. Export the new CA public key so that end entities may acquire it using the "out-of-band" mechanism (if required). The old CA private key is then no longer required. However, the old CA public key will remain in use for some time. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired the new CA public key.
The "old with new" certificate must have a validity period starting at the generation time of the old key pair and ending at the expiry date of the old public key. The "new with old" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which all end entities of this CA will securely possess the new CA public key (at the latest, the expiry date of the old public key). The "new with new" certificate must have a validity period starting at the generation time of the new key pair and ending at or before the time by which the CA will next update its key pair.4.4.2. Verifying Certificates
Normally when verifying a signature, the verifier verifies (among other things) the certificate containing the public key of the signer. However, once a CA is allowed to update its key there are a range of new possibilities. These are shown in the table below. Repository contains NEW Repository contains only OLD and OLD public keys public key (due to, e.g., delay in publication) PSE PSE Contains PSE Contains PSE Contains Contains OLD public NEW public OLD public NEW public key key key key Signer's Case 1: Case 3: Case 5: Case 7: certifi- This is In this case Although the In this case cate is the the verifier CA operator the CA protected standard must access has not operator has using NEW case where the updated the not updated public the repository in repository the the repository key verifier order to get verifier can and so the can the value of verify the verification directly the NEW certificate will FAIL verify the public key directly - certificate this is thus without the same as using the case 1. repository
Signer's Case 2: Case 4: Case 6: Case 8:
certifi- In this In this case The verifier Although the
cate is case the the verifier thinks this CA operator
protected verifier can directly is the has not
using OLD must verify the situation of updated the
public access the certificate case 2 and repository the
key repository without will access verifier can
in order using the the verify the
to get the repository repository; certificate
value of however, the directly -
the OLD verification this is thus
public key will FAIL the same as
case 4.
4.4.2.1. Verification in Cases 1, 4, 5, and 8
In these cases, the verifier has a local copy of the CA public key
that can be used to verify the certificate directly. This is the
same as the situation where no key change has occurred.
Note that case 8 may arise between the time when the CA operator has
generated the new key pair and the time when the CA operator stores
the updated attributes in the repository. Case 5 can only arise if
the CA operator has issued both the signer's and verifier's
certificates during this "gap" (the CA operator SHOULD avoid this as
it leads to the failure cases described below)
4.4.2.2. Verification in Case 2
In case 2, the verifier must get access to the old public key of the
CA. The verifier does the following:
1. Look up the caCertificate attribute in the repository and pick
the OldWithNew certificate (determined based on validity periods;
note that the subject and issuer fields must match);
2. Verify that this is correct using the new CA key (which the
verifier has locally);
3. If correct, check the signer's certificate using the old CA key.
Case 2 will arise when the CA operator has issued the signer's
certificate, then changed the key, and then issued the verifier's
certificate; so it is quite a typical case.
4.4.2.3. Verification in Case 3
In case 3, the verifier must get access to the new public key of the CA. The verifier does the following: 1. Look up the CACertificate attribute in the repository and pick the NewWithOld certificate (determined based on validity periods; note that the subject and issuer fields must match); 2. Verify that this is correct using the old CA key (which the verifier has stored locally); 3. If correct, check the signer's certificate using the new CA key. Case 3 will arise when the CA operator has issued the verifier's certificate, then changed the key, and then issued the signer's certificate; so it is also quite a typical case.4.4.2.4. Failure of Verification in Case 6
In this case, the CA has issued the verifier's PSE, which contains the new key, without updating the repository attributes. This means that the verifier has no means to get a trustworthy version of the CA's old key and so verification fails. Note that the failure is the CA operator's fault.4.4.2.5. Failure of Verification in Case 7
In this case, the CA has issued the signer's certificate protected with the new key without updating the repository attributes. This means that the verifier has no means to get a trustworthy version of the CA's new key and so verification fails. Note that the failure is again the CA operator's fault.4.4.3. Revocation - Change of CA Key
As we saw above, the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks as the CA may have signed the CRL using a newer private key than the one within the user's PSE. The analysis of the alternatives is the same as for certificate verification.
5. Data Structures
This section contains descriptions of the data structures required for PKI management messages. Section 6 describes constraints on their values and the sequence of events for each of the various PKI management operations.5.1. Overall PKI Message
All of the messages used in this specification for the purposes of PKI management use the following structure: PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL } PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage The PKIHeader contains information that is common to many PKI messages. The PKIBody contains message-specific information. The PKIProtection, when used, contains bits that protect the PKI message. The extraCerts field can contain certificates that may be useful to the recipient. For example, this can be used by a CA or RA to present an end entity with certificates that it needs to verify its own new certificate (if, for example, the CA that issued the end entity's certificate is not a root CA for the end entity). Note that this field does not necessarily contain a certification path; the recipient may have to sort, select from, or otherwise process the extra certificates in order to use them.5.1.1. PKI Message Header
All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope. However, if the PKI message is protected, then this information is also protected (i.e., we make no assumption about secure transport).
The following data structure is used to contain this information:
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
recipient GeneralName,
messageTime [0] GeneralizedTime OPTIONAL,
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
transactionID [4] OCTET STRING OPTIONAL,
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
The pvno field is fixed (at 2) for this version of this
specification.
The sender field contains the name of the sender of the PKIMessage.
This name (in conjunction with senderKID, if supplied) should be
sufficient to indicate the key to use to verify the protection on the
message. If nothing about the sender is known to the sending entity
(e.g., in the init. req. message, where the end entity may not know
its own Distinguished Name (DN), e-mail name, IP address, etc.), then
the "sender" field MUST contain a "NULL" value; that is, the SEQUENCE
OF relative distinguished names is of zero length. In such a case,
the senderKID field MUST hold an identifier (i.e., a reference
number) that indicates to the receiver the appropriate shared secret
information to use to verify the message.
The recipient field contains the name of the recipient of the
PKIMessage. This name (in conjunction with recipKID, if supplied)
should be usable to verify the protection on the message.
The protectionAlg field specifies the algorithm used to protect the
message. If no protection bits are supplied (note that PKIProtection
is OPTIONAL) then this field MUST be omitted; if protection bits are
supplied, then this field MUST be supplied.
senderKID and recipKID are usable to indicate which keys have been
used to protect the message (recipKID will normally only be required
where protection of the message uses Diffie-Hellman (DH) keys).
These fields MUST be used if required to uniquely identify a key
(e.g., if more than one key is associated with a given sender name)
and SHOULD be omitted otherwise.
The transactionID field within the message header is to be used to
allow the recipient of a message to correlate this with an ongoing
transaction. This is needed for all transactions that consist of
more than just a single request/response pair. For transactions that
consist of a single request/response pair, the rules are as follows.
A client MAY populate the transactionID field of the request. If a
server receives such a request that has the transactionID field set,
then it MUST set the transactionID field of the response to the same
value. If a server receives such request with a missing
transactionID field, then it MAY set transactionID field of the
response.
For transactions that consist of more than just a single
request/response pair, the rules are as follows. Clients SHOULD
generate a transactionID for the first request. If a server receives
such a request that has the transactionID field set, then it MUST set
the transactionID field of the response to the same value. If a
server receives such request with a missing transactionID field, then
it MUST populate the transactionID field of the response with a
server-generated ID. Subsequent requests and responses MUST all set
the transactionID field to the thus established value. In all cases
where a transactionID is being used, a given client MUST NOT have
more than one transaction with the same transactionID in progress at
any time (to a given server). Servers are free to require uniqueness
of the transactionID or not, as long as they are able to correctly
associate messages with the corresponding transaction. Typically,
this means that a server will require the {client, transactionID}
tuple to be unique, or even the transactionID alone to be unique, if
it cannot distinguish clients based on transport-level information.
A server receiving the first message of a transaction (which requires
more than a single request/response pair) that contains a
transactionID that does not allow it to meet the above constraints
(typically because the transactionID is already in use) MUST send
back an ErrorMsgContent with a PKIFailureInfo of transactionIdInUse.
It is RECOMMENDED that the clients fill the transactionID field with
128 bits of (pseudo-) random data for the start of a transaction to
reduce the probability of having the transactionID in use at the
server.
The senderNonce and recipNonce fields protect the PKIMessage against
replay attacks. The senderNonce will typically be 128 bits of
(pseudo-) random data generated by the sender, whereas the recipNonce
is copied from the senderNonce of the previous message in the
transaction.
The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct/check their local time for consistency with the time on a central system. The freeText field may be used to send a human-readable message to the recipient (in any number of languages). The first language used in this sequence indicates the desired language for replies. The generalInfo field may be used to send machine-processable additional data to the recipient. The following generalInfo extensions are defined and MAY be supported.5.1.1.1. ImplicitConfirm
This is used by the EE to inform the CA that it does not wish to send a certificate confirmation for issued certificates. implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} ImplicitConfirmValue ::= NULL If the CA grants the request to the EE, it MUST put the same extension in the PKIHeader of the response. If the EE does not find the extension in the response, it MUST send the certificate confirmation.5.1.1.2. ConfirmWaitTime
This is used by the CA to inform the EE how long it intends to wait for the certificate confirmation before revoking the certificate and deleting the transaction. confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} ConfirmWaitTimeValue ::= GeneralizedTime5.1.2. PKI Message Body
PKIBody ::= CHOICE { ir [0] CertReqMessages, --Initialization Req ip [1] CertRepMessage, --Initialization Resp cr [2] CertReqMessages, --Certification Req cp [3] CertRepMessage, --Certification Resp p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. popdecc [5] POPODecKeyChallContent --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response kur [7] CertReqMessages, --Key Update Request kup [8] CertRepMessage, --Key Update Response krr [9] CertReqMessages, --Key Recovery Req
krp [10] KeyRecRepContent, --Key Recovery Resp
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Resp
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent, --Error Message
certConf [24] CertConfirmContent, --Certificate confirm
pollReq [25] PollReqContent, --Polling request
pollRep [26] PollRepContent --Polling response
}
The specific types are described in Section 5.3 below.
5.1.3. PKI Message Protection
Some PKI messages will be protected for integrity. (Note that if an
asymmetric algorithm is used to protect a message and the relevant
public component has been certified already, then the origin of the
message can also be authenticated. On the other hand, if the public
component is uncertified, then the message origin cannot be
automatically authenticated, but may be authenticated via out-of-band
means.)
When protection is applied, the following structure is used:
PKIProtection ::= BIT STRING
The input to the calculation of PKIProtection is the DER encoding of
the following data structure:
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
There MAY be cases in which the PKIProtection BIT STRING is
deliberately not used to protect a message (i.e., this OPTIONAL field
is omitted) because other protection, external to PKIX, will be
applied instead. Such a choice is explicitly allowed in this
specification. Examples of such external protection include PKCS #7
[PKCS7] and Security Multiparts [RFC1847] encapsulation of the PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the relevant PKIHeader information is securely carried in the external mechanism). It is noted, however, that many such external mechanisms require that the end entity already possesses a public-key certificate, and/or a unique Distinguished Name, and/or other such infrastructure-related information. Thus, they may not be appropriate for initial registration, key-recovery, or any other process with "boot-strapping" characteristics. For those cases it may be necessary that the PKIProtection parameter be used. In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent. Depending on the circumstances, the PKIProtection bits may contain a Message Authentication Code (MAC) or signature. Only the following cases can occur:5.1.3.1. Shared Secret Information
In this case, the sender and recipient share secret information (established via out-of-band means or from a previous PKI management operation). PKIProtection will contain a MAC value and the protectionAlg will be the following (see also Appendix D.2): id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, iterationCount INTEGER, mac AlgorithmIdentifier } In the above protectionAlg, the salt value is appended to the shared secret input. The OWF is then applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration. The output of the final iteration (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]
Note: it is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) in order to reduce the overhead associated with PasswordBasedMac computation).5.1.3.2. DH Key Pairs
Where the sender and receiver possess Diffie-Hellman certificates with compatible DH parameters, in order to protect the message the end entity must generate a symmetric key based on its private DH key value and the DH public key of the recipient of the PKI message. PKIProtection will contain a MAC value keyed with this derived symmetric key and the protectionAlg will be the following: id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} DHBMParameter ::= SEQUENCE { owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended) mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [RFC2104, RFC2202]) In the above protectionAlg, OWF is applied to the result of the Diffie-Hellman computation. The OWF output (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]5.1.3.3. Signature
In this case, the sender possesses a signature key pair and simply signs the PKI message. PKIProtection will contain the signature value and the protectionAlg will be an AlgorithmIdentifier for a digital signature (e.g., md5WithRSAEncryption or dsaWithSha-1).5.1.3.4. Multiple Protection
In cases where an end entity sends a protected PKI message to an RA, the RA MAY forward that message to a CA, attaching its own protection (which MAY be a MAC or a signature, depending on the information and certificates shared between the RA and the CA). This is accomplished
by nesting the entire message sent by the end entity within a new PKI
message. The structure used is as follows.
NestedMessageContent ::= PKIMessages
(The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch
the requests of several EEs in a single new message. For simplicity,
all messages in the batch MUST be of the same type (e.g., ir).) If
the RA wishes to modify the message(s) in some way (e.g., add
particular field values or new extensions), then it MAY create its
own desired PKIBody. The original PKIMessage from the EE MAY be
included in the generalInfo field of PKIHeader (to accommodate, for
example, cases in which the CA wishes to check POP or other
information on the original EE message). The infoType to be used in
this situation is {id-it 15} (see Section 5.3.19 for the value of
id-it) and the infoValue is PKIMessages (contents MUST be in the same
order as the requests in PKIBody).
5.2. Common Data Structures
Before specifying the specific types that may be placed in a PKIBody,
we define some data structures that are used in more than one case.
5.2.1. Requested Certificate Contents
Various PKI management messages require that the originator of the
message indicate some of the fields that are required to be present
in a certificate. The CertTemplate structure allows an end entity or
RA to specify as much as it wishes about the certificate it requires.
CertTemplate is identical to a Certificate, but with all fields
optional.
Note that even if the originator completely specifies the contents of
a certificate it requires, a CA is free to modify fields within the
certificate actually issued. If the modified certificate is
unacceptable to the requester, the requester MUST send back a
certConf message that either does not include this certificate (via a
CertHash), or does include this certificate (via a CertHash) along
with a status of "rejected". See Section 5.3.18 for the definition
and use of CertHash and the certConf message.
See Appendix C and [CRMF] for CertTemplate syntax.
5.2.2. Encrypted Values
Where encrypted values (restricted, in this specification, to be
either private keys or certificates) are sent in PKI messages, the
EncryptedValue data structure is used.
See [CRMF] for EncryptedValue syntax. Use of this data structure requires that the creator and intended recipient be able to encrypt and decrypt, respectively. Typically, this will mean that the sender and recipient have, or are able to generate, a shared secret key. If the recipient of the PKIMessage already possesses a private key usable for decryption, then the encSymmKey field MAY contain a session key encrypted using the recipient's public key.5.2.3. Status codes and Failure Information for PKI Messages
All response messages will include some status information. The following values are defined. PKIStatus ::= INTEGER { accepted (0), grantedWithMods (1), rejection (2), waiting (3), revocationWarning (4), revocationNotification (5), keyUpdateWarning (6) } Responders may use the following syntax to provide more information about failure cases. PKIFailureInfo ::= BIT STRING { badAlg (0), badMessageCheck (1), badRequest (2), badTime (3), badCertId (4), badDataFormat (5), wrongAuthority (6), incorrectData (7), missingTimeStamp (8), badPOP (9), certRevoked (10), certConfirmed (11), wrongIntegrity (12), badRecipientNonce (13), timeNotAvailable (14), unacceptedPolicy (15), unacceptedExtension (16), addInfoNotAvailable (17),
badSenderNonce (18),
badCertTemplate (19),
signerNotTrusted (20),
transactionIdInUse (21),
unsupportedVersion (22),
notAuthorized (23),
systemUnavail (24),
systemFailure (25),
duplicateCertReq (26)
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
5.2.4. Certificate Identification
In order to identify particular certificates, the CertId data
structure is used.
See [CRMF] for CertId syntax.
5.2.5. Out-of-band root CA Public Key
Each root CA must be able to publish its current public key via some
"out-of-band" means. While such mechanisms are beyond the scope of
this document, we define data structures that can support such
mechanisms.
There are generally two methods available: either the CA directly
publishes its self-signed certificate, or this information is
available via the Directory (or equivalent) and the CA publishes a
hash of this value to allow verification of its integrity before use.
OOBCert ::= Certificate
The fields within this certificate are restricted as follows:
o The certificate MUST be self-signed (i.e., the signature must be
verifiable using the SubjectPublicKeyInfo field);
o The subject and issuer fields MUST be identical;
o If the subject field is NULL, then both subjectAltNames and
issuerAltNames extensions MUST be present and have exactly the
same value;
o The values of all other extensions must be suitable for a self-
signed certificate (e.g., key identifiers for subject and issuer
must be the same).
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
The intention of the hash value is that anyone who has securely
received the hash value (via the out-of-band means) can verify a
self-signed certificate for that CA.
5.2.6. Archive Options
Requesters may indicate that they wish the PKI to archive a private
key value using the PKIArchiveOptions structure.
See [CRMF] for PKIArchiveOptions syntax.
5.2.7. Publication Information
Requesters may indicate that they wish the PKI to publish a
certificate using the PKIPublicationInfo structure.
See [CRMF] for PKIPublicationInfo syntax.
5.2.8. Proof-of-Possession Structures
If the certification request is for a signing key pair (i.e., a
request for a verification certificate), then the proof-of-possession
of the private signing key is demonstrated through use of the
POPOSigningKey structure.
See Appendix C and [CRMF] for POPOSigningKey syntax, but note that
POPOSigningKeyInput has the following semantic stipulations in this
specification.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
publicKeyMAC PKMACValue
},
publicKey SubjectPublicKeyInfo
}
On the other hand, if the certification request is for an encryption key pair (i.e., a request for an encryption certificate), then the proof-of-possession of the private decryption key may be demonstrated in one of three ways.5.2.8.1. Inclusion of the Private Key
By the inclusion of the private key (encrypted) in the CertRequest (in the thisMessage field of POPOPrivKey (see Appendix C) or in the PKIArchiveOptions control structure, depending upon whether or not archival of the private key is also desired).5.2.8.2. Indirect Method
By having the CA return not the certificate, but an encrypted certificate (i.e., the certificate encrypted under a randomly- generated symmetric key, and the symmetric key encrypted under the public key for which the certification request is being made) -- this is the "indirect" method mentioned previously in Section 4.3.2. The end entity proves knowledge of the private decryption key to the CA by providing the correct CertHash for this certificate in the certConf message. This demonstrates POP because the EE can only compute the correct CertHash if it is able to recover the certificate, and it can only recover the certificate if it is able to decrypt the symmetric key using the required private key. Clearly, for this to work, the CA MUST NOT publish the certificate until the certConf message arrives (when certHash is to be used to demonstrate POP). See Section 5.3.18 for further details.5.2.8.3. Challenge-Response Protocol
By having the end entity engage in a challenge-response protocol (using the messages POPODecKeyChall and POPODecKeyResp; see below) between CertReqMessages and CertRepMessage -- this is the "direct" method mentioned previously in Section 4.3.2. (This method would typically be used in an environment in which an RA verifies POP and then makes a certification request to the CA on behalf of the end entity. In such a scenario, the CA trusts the RA to have done POP correctly before the RA requests a certificate for the end entity.) The complete protocol then looks as follows (note that req' does not necessarily encapsulate req as a nested message):
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
This protocol is obviously much longer than the 3-way exchange given
in choice (2) above, but allows a local Registration Authority to be
involved and has the property that the certificate itself is not
actually created until the proof-of-possession is complete. In some
environments, a different order of the above messages may be
required, such as the following (this may be determined by policy):
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
If the cert. request is for a key agreement key (KAK) pair, then the
POP can use any of the 3 ways described above for enc. key pairs,
with the following changes: (1) the parenthetical text of bullet 2)
is replaced with "(i.e., the certificate encrypted under the
symmetric key derived from the CA's private KAK and the public key
for which the certification request is being made)"; (2) the first
parenthetical text of the challenge field of "Challenge" below is
replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and
Appendix E.5) and a symmetric key derived from the CA's private KAK
and the public key for which the certification request is being
made)". Alternatively, the POP can use the POPOSigningKey structure
given in [CRMF] (where the alg field is DHBasedMAC and the signature
field is the MAC) as a fourth alternative for demonstrating POP if
the CA already has a D-H certificate that is known to the EE.
The challenge-response messages for proof-of-possession of a private decryption key are specified as follows (see [MvOV97], p.404 for details). Note that this challenge-response exchange is associated with the preceding cert. request message (and subsequent cert. response and confirmation messages) by the transactionID used in the PKIHeader and by the protection (MACing or signing) applied to the PKIMessage. POPODecKeyChallContent ::= SEQUENCE OF Challenge Challenge ::= SEQUENCE { owf AlgorithmIdentifier OPTIONAL, witness OCTET STRING, challenge OCTET STRING } Note that the size of Rand needs to be appropriate for encryption under the public key of the requester. Given that "int" will typically not be longer than 64 bits, this leaves well over 100 bytes of room for the "sender" field when the modulus is 1024 bits. If, in some environment, names are so long that they cannot fit (e.g., very long DNs), then whatever portion will fit should be used (as long as it includes at least the common name, and as long as the receiver is able to deal meaningfully with the abbreviation). POPODecKeyRespContent ::= SEQUENCE OF INTEGER5.2.8.4. Summary of PoP Options
The text in this section provides several options with respect to POP techniques. Using "SK" for "signing key", "EK" for "encryption key", and "KAK" for "key agreement key", the techniques may be summarized as follows: RAVerified; SKPOP; EKPOPThisMessage; KAKPOPThisMessage; KAKPOPThisMessageDHMAC; EKPOPEncryptedCert; KAKPOPEncryptedCert; EKPOPChallengeResp; and KAKPOPChallengeResp. Given this array of options, it is natural to ask how an end entity can know what is supported by the CA/RA (i.e., which options it may use when requesting certificates). The following guidelines should clarify this situation for EE implementers.
RAVerified. This is not an EE decision; the RA uses this if and only if it has verified POP before forwarding the request on to the CA, so it is not possible for the EE to choose this technique. SKPOP. If the EE has a signing key pair, this is the only POP method specified for use in the request for a corresponding certificate. EKPOPThisMessage and KAKPOPThisMessage. Whether or not to give up its private key to the CA/RA is an EE decision. If the EE decides to reveal its key, then these are the only POP methods available in this specification to achieve this (and the key pair type will determine which of these two methods to use). KAKPOPThisMessageDHMAC. The EE can only use this method if (1) the CA has a DH certificate available for this purpose, and (2) the EE already has a copy of this certificate. If both these conditions hold, then this technique is clearly supported and may be used by the EE, if desired. EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp. The EE picks one of these (in the subsequentMessage field) in the request message, depending upon preference and key pair type. The EE is not doing POP at this point; it is simply indicating which method it wants to use. Therefore, if the CA/RA replies with a "badPOP" error, the EE can re-request using the other POP method chosen in subsequentMessage. Note, however, that this specification encourages the use of the EncryptedCert choice and, furthermore, says that the challenge-response would typically be used when an RA is involved and doing POP verification. Thus, the EE should be able to make an intelligent decision regarding which of these POP methods to choose in the request message.
(page 38 continued on part 3)