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 ::= GeneralizedTime
5.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,