A newly created root CA must produce a "self-certificate", which is a
Certificate structure with the profile defined for the "newWithNew"
certificate issued following a root CA key update.
In order to make the CA’s self certificate useful to end entities
that do not acquire the self certificate via "out-of-band" means, the
CA must also produce a fingerprint for its certificate. End entities
that acquire this fingerprint securely via some "out-of-band" means
can then verify the CA’s self-certificate and, hence, the other
attributes contained therein.
The data structure used to carry the fingerprint is the OOBCertHash.
6.2. Root CA Key Update
CA keys (as all other keys) have a finite lifetime and will have to
be updated on a periodic basis. The certificates NewWithNew,
NewWithOld, and OldWithNew (see Section 4.4.1) MAY be issued by the
CA to aid existing end entities who hold the current self-signed CA
certificate (OldWithOld) to transition securely to the new self-
signed CA certificate (NewWithNew), and to aid new end entities who
will hold NewWithNew to acquire OldWithOld securely for verification
of existing data.
6.3. Subordinate CA Initialization
[See Section 3.1.1.2 for this document’s definition of "subordinate
CA".]
From the perspective of PKI management protocols, the initialization
of a subordinate CA is the same as the initialization of an end
entity. The only difference is that the subordinate CA must also
produce an initial revocation list.
6.4. CRL production
Before issuing any certificates, a newly established CA (which issues
CRLs) must produce "empty" versions of each CRL which are to be
periodically produced.
6.5. PKI Information Request
When a PKI entity (CA, RA, or EE) wishes to acquire information about
the current status of a CA, it MAY send that CA a request for such
information.
The CA MUST respond to the request by providing (at least) all of the
information requested by the requester. If some of the information
cannot be provided, then an error must be conveyed to the requester.
If PKIMessages are used to request and supply this PKI information,
then the request MUST be the GenMsg message, the response MUST be the
GenRep message, and the error MUST be the Error message. These
messages are protected using a MAC based on shared secret information
(i.e., PasswordBasedMAC) or using any other authenticated means (if
the end entity has an existing certificate).
6.6. Cross Certification
The requester CA is the CA that will become the subject of the
cross-certificate; the responder CA will become the issuer of the
cross-certificate.
The requester CA must be "up and running" before initiating the
cross-certification operation.
6.6.1. One-Way Request-Response Scheme:
The cross-certification scheme is essentially a one way operation;
that is, when successful, this operation results in the creation of
one new cross-certificate. If the requirement is that cross-
certificates be created in "both directions", then each CA, in turn,
must initiate a cross-certification operation (or use another
scheme).
This scheme is suitable where the two CAs in question can already
verify each other’s signatures (they have some common points of
trust) or where there is an out-of-band verification of the origin of
the certification request.
Detailed Description:
Cross certification is initiated at one CA known as the responder.
The CA administrator for the responder identifies the CA it wants to
cross certify and the responder CA equipment generates an
authorization code. The responder CA administrator passes this
authorization code by out-of-band means to the requester CA
administrator. The requester CA administrator enters the
authorization code at the requester CA in order to initiate the on-
line exchange.
The authorization code is used for authentication and integrity
purposes. This is done by generating a symmetric key based on the
authorization code and using the symmetric key for generating Message
Authentication Codes (MACs) on all messages exchanged.
(Authentication may alternatively be done using signatures instead of
MACs, if the CAs are able to retrieve and validate the required
public keys by some means, such as an out-of-band hash comparison.)
The requester CA initiates the exchange by generating a cross-
certification request (ccr) with a fresh random number (requester
random number). The requester CA then sends the ccr message to the
responder CA. The fields in this message are protected from
modification with a MAC based on the authorization code.
Upon receipt of the ccr message, the responder CA validates the
message and the MAC, saves the requester random number, and generates
its own random number (responder random number). It then generates
(and archives, if desired) a new requester certificate that contains
the requester CA public key and is signed with the responder CA
signature private key. The responder CA responds with the cross
certification response (ccp) message. The fields in this message are
protected from modification with a MAC based on the authorization
code.
Upon receipt of the ccp message, the requester CA validates the
message (including the received random numbers) and the MAC. The
requester CA responds with the certConf message. The fields in this
message are protected from modification with a MAC based on the
authorization code. The requester CA MAY write the requester
certificate to the Repository as an aid to later certificate path
construction.
Upon receipt of the certConf message, the responder CA validates the
message and the MAC, and sends back an acknowledgement using the
PKIConfirm message. It MAY also publish the requester certificate as
an aid to later path construction.
Notes:
1. The ccr message must contain a "complete" certification request;
that is, all fields except the serial number (including, e.g., a
BasicConstraints extension) must be specified by the requester
CA.
2. The ccp message SHOULD contain the verification certificate of
the responder CA; if present, the requester CA must then verify
this certificate (for example, via the "out-of-band" mechanism).
(A simpler, non-interactive model of cross-certification may also be
envisioned, in which the issuing CA acquires the subject CA’s public
key from some repository, verifies it via some out-of-band mechanism,
and creates and publishes the cross-certificate without the subject
CA’s explicit involvement. This model may be perfectly legitimate
for many environments, but since it does not require any protocol
message exchanges, its detailed description is outside the scope of
this specification.)
6.7. End Entity Initialization
As with CAs, end entities must be initialized. Initialization of end
entities requires at least two steps:
o acquisition of PKI information
o out-of-band verification of one root-CA public key
(other possible steps include the retrieval of trust condition
information and/or out-of-band verification of other CA public keys).
6.7.1. Acquisition of PKI Information
The information REQUIRED is:
o the current root-CA public key
o (if the certifying CA is not a root-CA) the certification path
from the root CA to the certifying CA together with appropriate
revocation lists
o the algorithms and algorithm parameters that the certifying CA
supports for each relevant usage
Additional information could be required (e.g., supported extensions
or CA policy information) in order to produce a certification request
that will be successful. However, for simplicity we do not mandate
that the end entity acquires this information via the PKI messages.
The end result is simply that some certification requests may fail
(e.g., if the end entity wants to generate its own encryption key,
but the CA doesn’t allow that).
The required information MAY be acquired as described in Section 6.5.
6.7.2. Out-of-Band Verification of Root-CA Key
An end entity must securely possess the public key of its root CA.
One method to achieve this is to provide the end entity with the CA’s
self-certificate fingerprint via some secure "out-of-band" means.
The end entity can then securely use the CA’s self-certificate.
See Section 6.1 for further details.
6.8. Certificate Request
An initialized end entity MAY request an additional certificate at
any time (for any purpose). This request will be made using the
certification request (cr) message. If the end entity already
possesses a signing key pair (with a corresponding verification
certificate), then this cr message will typically be protected by the
entity’s digital signature. The CA returns the new certificate (if
the request is successful) in a CertRepMessage.
6.9. Key Update
When a key pair is due to expire, the relevant end entity MAY request
a key update; that is, it MAY request that the CA issue a new
certificate for a new key pair (or, in certain circumstances, a new
certificate for the same key pair). The request is made using a key
update request (kur) message (referred to, in some environments, as a
"Certificate Update" operation). If the end entity already possesses
a signing key pair (with a corresponding verification certificate),
then this message will typically be protected by the entity’s digital
signature. The CA returns the new certificate (if the request is
successful) in a key update response (kup) message, which is
syntactically identical to a CertRepMessage.
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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode
Plain Text", RFC 2482, January 1999.
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
Informative References
[CMPtrans] Kapoor, A., Tschalar, R. and T. Kause, "Internet X.509
Public Key Infrastructure -- Transport Protocols for
CMP", Work in Progress. 2004.
[PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards
- Cryptographic Message Syntax Standard. Version 1.5",
PKCS 7, November 1993.
[PKCS10] Nystrom, M., and B. Kaliski, "The Public-Key
Cryptography Standards - Certification Request Syntax
Standard, Version 1.7", RFC 2986, May 2000.
[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards
- Cryptographic Token Interface Standard. Version
2.10", PKCS 11, December 1999.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC2559] Boeyen, S., Howes, T. and P. Richard, "Internet X.509
Public Key Infrastructure Operational Protocols -
LDAPv2", RFC 2559, April 1999.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC
2585, May 1999.
[FIPS-180] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, May 1994.
[FIPS-186] National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186, May 1994.
[ANSI-X9.42] American National Standards Institute, "Public Key
Cryptography for The Financial Services Industry:
Agreement of Symmetric Keys Using Discrete Logarithm
Cryptography", ANSI X9.42, February 2000.
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