diff options
Diffstat (limited to 'doc/rfc/rfc2510.txt')
| -rw-r--r-- | doc/rfc/rfc2510.txt | 4035 |
1 files changed, 4035 insertions, 0 deletions
diff --git a/doc/rfc/rfc2510.txt b/doc/rfc/rfc2510.txt new file mode 100644 index 0000000..97f3953 --- /dev/null +++ b/doc/rfc/rfc2510.txt @@ -0,0 +1,4035 @@ + + + + + + +Network Working Group C. Adams +Request for Comments: 2510 Entrust Technologies +Category: Standards Track S. Farrell + SSE + March 1999 + + + Internet X.509 Public Key Infrastructure + Certificate Management Protocols + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document describes the Internet X.509 Public Key Infrastructure + (PKI) Certificate Management Protocols. Protocol messages are defined + for all relevant aspects of certificate creation and management. + Note that "certificate" in this document refers to an X.509v3 + Certificate as defined in [COR95, X509-AM]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, + as shown) are to be interpreted as described in [RFC2119]. + +Introduction + + The layout of this document is as follows: + + - Section 1 contains an overview of PKI management; + - Section 2 contains discussion of assumptions and restrictions; + - Section 3 contains data structures used for PKI management messages; + - Section 4 defines the functions that are to be carried out in PKI + management by conforming implementations; + - Section 5 describes a simple protocol for transporting PKI messages; + - the Appendices specify profiles for conforming implementations and + provide an ASN.1 module containing the syntax for all messages + defined in this specification. + + + + +Adams & Farrell Standards Track [Page 1] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +1 PKI Management Overview + + The PKI must be structured to be consistent with the types of + individuals who must administer it. Providing such administrators + with unbounded choices not only complicates the software required but + also increases the chances that a subtle mistake by an administrator + or software developer will result in broader compromise. Similarly, + restricting administrators with cumbersome mechanisms will cause them + not to use the PKI. + + Management protocols are REQUIRED to support on-line interactions + between Public Key Infrastructure (PKI) components. For example, a + management protocol might be used between a Certification Authority + (CA) and a client system with which a key pair is associated, or + between two CAs that issue cross-certificates for each other. + +1.1 PKI Management Model + + Before specifying particular message formats and procedures we first + define the entities involved in PKI management and their interactions + (in terms of the PKI management functions required). We then group + these functions in order to accommodate different identifiable types + of end entities. + +1.2 Definitions of PKI Entities + + The entities involved in PKI management include the end entity (i.e., + the entity to be named in the subject field of a certificate) and the + certification authority (i.e., the entity named in the issuer field + of a certificate). A registration authority MAY also be involved in + PKI management. + +1.2.1 Subjects and End Entities + + The term "subject" is used here to refer to the entity named in the + subject field of a certificate; when we wish to distinguish the tools + and/or software used by the subject (e.g., a local certificate + management module) we will use the term "subject equipment". In + general, the term "end entity" (EE) rather than subject is preferred + in order to avoid confusion with the field name. + + It is important to note that the end entities here will include not + only human users of applications, but also applications themselves + (e.g., for IP security). This factor influences the protocols which + the PKI management operations use; for example, application software + is far more likely to know exactly which certificate extensions are + required than are human users. PKI management entities are also end + entities in the sense that they are sometimes named in the subject + + + +Adams & Farrell Standards Track [Page 2] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + field of a certificate or cross-certificate. Where appropriate, the + term "end-entity" will be used to refer to end entities who are not + PKI management entities. + + All end entities require secure local access to some information -- + at a minimum, their own name and private key, the name of a CA which + is directly trusted by this entity and that CA's public key (or a + fingerprint of the public key where a self-certified version is + available elsewhere). Implementations MAY use secure local storage + for more than this minimum (e.g., the end entity's own certificate or + application-specific information). The form of storage will also vary + -- from files to tamper-resistant cryptographic tokens. Such local + trusted storage is referred to here as the end entity's Personal + Security Environment (PSE). + + Though PSE formats are beyond the scope of this document (they are + very dependent on equipment, et cetera), a generic interchange format + for PSEs is defined here - a certification response message MAY be + used. + +1.2.2 Certification Authority + + The certification authority (CA) may or may not actually be a real + "third party" from the end entity's point of view. Quite often, the + CA will actually belong to the same organization as the end entities + it supports. + + Again, we use the term CA to refer to the entity named in the issuer + field of a certificate; when it is necessary to distinguish the + software or hardware tools used by the CA we use the term "CA + equipment". + + The CA equipment will often include both an "off-line" component and + an "on-line" component, with the CA private key only available to the + "off-line" component. This is, however, a matter for implementers + (though it is also relevant as a policy issue). + + We use the term "root CA" to indicate a CA that is directly trusted + by an end entity; that is, securely acquiring the value of a root CA + public key requires some out-of-band step(s). This term is not meant + to imply that a root CA is necessarily at the top of any hierarchy, + simply that the CA in question is trusted directly. + + A "subordinate CA" is one that is not a root CA for the end entity in + question. Often, a subordinate CA will not be a root CA for any + entity but this is not mandatory. + + + + + +Adams & Farrell Standards Track [Page 3] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +1.2.3 Registration Authority + + In addition to end-entities and CAs, many environments call for the + existence of a Registration Authority (RA) separate from the + Certification Authority. The functions which the registration + authority may carry out will vary from case to case but MAY include + personal authentication, token distribution, revocation reporting, + name assignment, key generation, archival of key pairs, et cetera. + + This document views the RA as an OPTIONAL component - when it is not + present the CA is assumed to be able to carry out the RA's functions + so that the PKI management protocols are the same from the end- + entity's point of view. + + Again, we distinguish, where necessary, between the RA and the tools + used (the "RA equipment"). + + Note that an RA is itself an end entity. We further assume that all + RAs are in fact certified end entities and that RAs have private keys + that are usable for signing. How a particular CA equipment identifies + some end entities as RAs is an implementation issue (i.e., this + document specifies no special RA certification operation). We do not + mandate that the RA is certified by the CA with which it is + interacting at the moment (so one RA may work with more than one CA + whilst only being certified once). + + In some circumstances end entities will communicate directly with a + CA even where an RA is present. For example, for initial registration + and/or certification the subject may use its RA, but communicate + directly with the CA in order to refresh its certificate. + +1.3 PKI Management Requirements + + The protocols given here meet the following requirements on PKI + management. + + 1. PKI management must conform to the ISO 9594-8 standard and the + associated amendments (certificate extensions) + + 2. PKI management must conform to the other parts of this series. + + 3. It must be possible to regularly update any key pair without + affecting any other key pair. + + 4. The use of confidentiality in PKI management protocols must be + kept to a minimum in order to ease regulatory problems. + + + + + +Adams & Farrell Standards Track [Page 4] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 5. PKI management protocols must allow the use of different + industry-standard cryptographic algorithms, (specifically + including RSA, DSA, MD5, SHA-1) -- this means that any given + CA, RA, or end entity may, in principle, use whichever + algorithms suit it for its own key pair(s). + + 6. PKI management protocols must not preclude the generation of + key pairs by the end-entity concerned, by an RA, or by a CA -- + key generation may also occur elsewhere, but for the purposes + of PKI management we can regard key generation as occurring + wherever the key is first present at an end entity, RA, or CA. + + 7. PKI management protocols must support the publication of + certificates by the end-entity concerned, by an RA, or by a CA. + Different implementations and different environments may choose + any of the above approaches. + + 8. PKI management protocols must support the production of + Certificate Revocation Lists (CRLs) by allowing certified end + entities to make requests for the revocation of certificates - + this must be done in such a way that the denial-of-service + attacks which are possible are not made simpler. + + 9. PKI management protocols must be usable over a variety of + "transport" mechanisms, specifically including mail, http, + TCP/IP and ftp. + + 10. Final authority for certification creation rests with the CA; + no RA or end-entity equipment can assume that any certificate + issued by a CA will contain what was requested -- a CA may + alter certificate field values or may add, delete or alter + extensions according to its operating policy. In other words, + all PKI entities (end-entities, RAs, and CAs) must be capable + of handling responses to requests for certificates in which + the actual certificate issued is different from that requested + (for example, a CA may shorten the validity period requested). + Note that policy may dictate that the CA must not publish or + otherwise distribute the certificate until the requesting + entity has reviewed and accepted the newly-created certificate + (typically through use of the PKIConfirm message). + + 11. A graceful, scheduled change-over from one non-compromised CA + key pair to the next (CA key update) must be supported (note + that if the CA key is compromised, re-initialization must be + performed for all entities in the domain of that CA). An end + entity whose PSE contains the new CA public key (following a + CA key update) must also be able to verify certificates + verifiable using the old public key. End entities who directly + + + +Adams & Farrell Standards Track [Page 5] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + trust the old CA key pair must also be able to verify + certificates signed using the new CA private key. (Required + for situations where the old CA public key is "hardwired" into + the end entity's cryptographic equipment). + + 12. The Functions of an RA may, in some implementations or + environments, be carried out by the CA itself. The protocols + must be designed so that end entities will use the same + protocol (but, of course, not the same key!) regardless of + whether the communication is with an RA or CA. + + 13. Where an end entity requests a certificate containing a given + public key value, the end entity must be ready to demonstrate + possession of the corresponding private key value. This may be + accomplished in various ways, depending on the type of + certification request. See Section 2.3, "Proof of Possession + of Private Key", for details of the in-band methods defined + for the PKIX-CMP (i.e., Certificate Management Protocol) + messages. + +PKI Management Operations + + The following diagram shows the relationship between the entities + defined above in terms of the PKI management operations. The letters + in the diagram indicate "protocols" in the sense that a defined set + of PKI management messages can be sent along each of the lettered + lines. + + + + + + + + + + + + + + + + + + + + + + + + +Adams & Farrell Standards Track [Page 6] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + +---+ cert. publish +------------+ j + | | <--------------------- | End Entity | <------- + | C | g +------------+ "out-of-band" + | | | ^ loading + | e | | | initial + | r | a | | b registration/ + | t | | | certification + | | | | key pair recovery + | / | | | key pair update + | | | | certificate update + | C | PKI "USERS" V | revocation request + | R | -------------------+-+-----+-+------+-+------------------- + | L | PKI MANAGEMENT | ^ | ^ + | | ENTITIES a | | b a | | b + | | V | | | + | R | g +------+ d | | + | e | <------------ | RA | <-----+ | | + | p | cert. | | ----+ | | | + | o | publish +------+ c | | | | + | s | | | | | + | i | V | V | + | t | g +------------+ i + | o | <------------------------| CA |-------> + | r | h +------------+ "out-of-band" + | y | cert. publish | ^ publication + | | CRL publish | | + +---+ | | cross-certification + e | | f cross-certificate + | | update + | | + V | + +------+ + | CA-2 | + +------+ + + Figure 1 - PKI Entities + + At a high level the set of operations for which management messages + are defined can be grouped as follows. + + 1 CA establishment: When establishing a new CA, certain steps are + required (e.g., production of initial CRLs, export of CA public + key). + + 2 End entity initialization: this includes importing a root CA + public key and requesting information about the options + supported by a PKI management entity. + + + + +Adams & Farrell Standards Track [Page 7] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 3 Certification: various operations result in the creation of new + certificates: + + 3.1 initial registration/certification: This is the process + whereby an end entity first makes itself known to a CA or + RA, prior to the CA issuing a certificate or certificates + for that end entity. The end result of this process (when it + is successful) is that a CA issues a certificate for an end + entity's public key, and returns that certificate to the end + entity and/or posts that certificate in a public repository. + This process may, and typically will, involve multiple + "steps", possibly including an initialization of the end + entity's equipment. For example, the end entity's equipment + must be securely initialized with the public key of a CA, to + be used in validating certificate paths. Furthermore, an + end entity typically needs to be initialized with its own + key pair(s). + + 3.2 key pair update: Every key pair needs to be updated + regularly (i.e., replaced with a new key pair), and a new + certificate needs to be issued. + + 3.3 certificate update: As certificates expire they may be + "refreshed" if nothing relevant in the environment has + changed. + + 3.4 CA key pair update: As with end entities, CA key pairs need + to be updated regularly; however, different mechanisms are + required. + + 3.5 cross-certification request: One CA requests issuance of a + cross-certificate from another CA. For the purposes of this + standard, the following terms are defined. A "cross- + certificate" is a certificate in which the subject CA and + the issuer CA are distinct and SubjectPublicKeyInfo contains + a verification key (i.e., the certificate has been issued + for the subject CA's signing key pair). When it is + necessary to distinguish more finely, the following terms + may be used: a cross-certificate is called an "inter-domain + cross-certificate" if the subject and issuer CAs belong to + different administrative domains; it is called an "intra- + domain cross-certificate" otherwise. + + + + + + + + + +Adams & Farrell Standards Track [Page 8] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + Notes: + + Note 1. The above definition of "cross-certificate" aligns with the + defined term "CA-certificate" in X.509. Note that this term is not + to be confused with the X.500 "cACertificate" attribute type, which + is unrelated. + + Note 2. In many environments the term "cross-certificate", unless + further qualified, will be understood to be synonymous with "inter- + domain cross-certificate" as defined above. + + Note 3. Issuance of cross-certificates may be, but is not + necessarily, mutual; that is, two CAs may issue cross-certificates + for each other. + + 3.6 cross-certificate update: Similar to a normal certificate + update but involving a cross-certificate. + + 4 Certificate/CRL discovery operations: some PKI management + operations result in the publication of certificates or CRLs: + + 4.1 certificate publication: Having gone to the trouble of + producing a certificate, some means for publishing it is + needed. The "means" defined in PKIX MAY involve the + messages specified in Sections 3.3.13 - 3.3.16, or MAY + involve other methods (LDAP, for example) as described in + the "Operational Protocols" documents of the PKIX series of + specifications. + + 4.2 CRL publication: As for certificate publication. + + 5 Recovery operations: some PKI management operations are used + when an end entity has "lost" its PSE: + + 5.1 key pair recovery: As an option, user client key materials + (e.g., a user's private key used for decryption purposes) + MAY be backed up by a CA, an RA, or a key backup system + associated with a CA or RA. If an entity needs to recover + these backed up key materials (e.g., as a result of a + forgotten password or a lost key chain file), a protocol + exchange may be needed to support such recovery. + + 6 Revocation operations: some PKI operations result in the + creation of new CRL entries and/or new CRLs: + + 6.1 revocation request: An authorized person advises a CA of an + abnormal situation requiring certificate revocation. + + + + +Adams & Farrell Standards Track [Page 9] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 7 PSE operations: whilst the definition of PSE operations (e.g., + moving a PSE, changing a PIN, etc.) are beyond the scope of this + specification, we do define a PKIMessage (CertRepMessage) which + can form the basis of such operations. + + Note that on-line protocols are not the only way of implementing the + above operations. For all operations there are off-line methods of + achieving the same result, and this specification does not mandate + use of on-line protocols. For example, when hardware tokens are + used, many of the operations MAY be achieved as part of the physical + token delivery. + + Later sections define a set of standard messages supporting the above + operations. The protocols for conveying these exchanges in different + environments (file based, on-line, E-mail, and WWW) is also + specified. + +2. Assumptions and restrictions + +2.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). + +2.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 which a CA + may implement and the variation in the types of end entity which can + occur. + + We can however, 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 which will arise in real use, whilst the optional + schemes are available for special cases which arise less frequently. + In this way we achieve a balance between flexibility and ease of + implementation. + + + + +Adams & Farrell Standards Track [Page 10] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + We will now describe the classification of initial registration / + certification schemes. + +2.2.1 Criteria used + +2.2.1.1 Initiation of registration / certification + + In terms of the PKI messages which 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. + +2.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 + transaction) via some out-of-band means. The initial authentication + key can then be used to protect relevant PKI messages. + + We can thus 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). + +2.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 + + + +Adams & Farrell Standards Track [Page 11] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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). + + There are thus three possibilities for the location of "key + generation": the end entity, an RA, or a CA. + +2.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. + +2.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. Any entity MAY additionally support other + schemes, if desired. + +2.2.2.1 Centralized scheme + + In terms of the classification above, this scheme is, in some ways, + the simplest possible, where: + + - initiation occurs at the certifying CA; + - no on-line message authentication is required; + - "key generation" occurs at the certifying CA (see Section 2.2.1.3); + - 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 decrypt any encrypted values. + + + + + + + + + +Adams & Farrell Standards Track [Page 12] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +2.2.2.2 Basic authenticated scheme + + In terms of the classification above, this scheme is where: + + - initiation occurs at the end entity; + - message authentication is REQUIRED; + - "key generation" occurs at the end entity (see Section 2.2.1.3); + - 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 + -->>--confirmation message-->>-- + verify confirmation + + (Where verification of the confirmation message fails, the RA/CA MUST + revoke the newly issued certificate if it has been published or + otherwise made available.) + +2.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 + + + +Adams & Farrell Standards Track [Page 13] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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 which 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). + +2.3.1 Signature Keys + + For signature keys, the end entity can sign a value to prove + possession of the private key. + +2.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 3.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 which 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 which can only be used by the + intended end entity. + + This specification encourages use of the indirect method because this + requires no extra messages to be sent (i.e., the proof can be + demonstrated using the {request, response, confirmation} triple of + messages). + + + +Adams & Farrell Standards Track [Page 14] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +2.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. + +2.4 Root CA key update + + This discussion only applies to CAs that are a root CA for some end + entity. + + 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 period of a CA key pair must be greater than the + validity period of any certificate issued by that CA using that key + pair. + + + +Adams & Farrell Standards Track [Page 15] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + Note 3.This scheme forces end entities to acquire the new CA public + key on 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). + +2.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 directory 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. The old CA public + key will however remain in use for some time. The time when the old + CA public key is no longer required (other than for non-repudiation) + will be 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 the time by + which the CA will next update its key pair. + + + + + +Adams & Farrell Standards Track [Page 16] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +2.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 directory in directory the the directory + 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. + directory + + 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 directory the + key directory without will access verifier can + in order using the the verify the + to get the directory directory; certificate + value of however, the directly - + the OLD verification this is thus + public key will FAIL the same as + case 4. + + + + + + + +Adams & Farrell Standards Track [Page 17] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +2.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 + which 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 directory. 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). + +2.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 directory and pick + the OldWithNew certificate (determined based on validity + periods); + 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 key and then issued the verifier's + certificate, so it is quite a typical case. + +2.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 directory and pick + the NewWithOld certificate (determined based on validity + periods); + 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 key and then issued the signer's + certificate, so it is also quite a typical case. + + + + + +Adams & Farrell Standards Track [Page 18] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +2.4.2.4 Failure of verification in case 6. + + In this case the CA has issued the verifier's PSE containing the new + key without updating the directory 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. + +2.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 directory 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. + +2.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 that is within the user's PSE. + + The analysis of the alternatives is as for certificate verification. + +3. Data Structures + + This section contains descriptions of the data structures required + for PKI management messages. Section 4 describes constraints on their + values and the sequence of events for each of the various PKI + management operations. Section 5 describes how these may be + encapsulated in various transport mechanisms. + +3.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 Certificate OPTIONAL + } + + + + + +Adams & Farrell Standards Track [Page 19] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + The PKIHeader contains information which 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. + +3.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 { ietf-version2 (1) }, + sender GeneralName, + -- identifies the sender + recipient GeneralName, + -- identifies the intended recipient + messageTime [0] GeneralizedTime OPTIONAL, + -- time of production of this message (used when sender + -- believes that the transport will be "suitable"; i.e., + -- that the time will still be meaningful upon receipt) + protectionAlg [1] AlgorithmIdentifier OPTIONAL, + -- algorithm used for calculation of protection bits + senderKID [2] KeyIdentifier OPTIONAL, + recipKID [3] KeyIdentifier OPTIONAL, + -- to identify specific keys used for protection + transactionID [4] OCTET STRING OPTIONAL, + -- identifies the transaction; i.e., this will be the same in + -- corresponding request, response and confirmation messages + senderNonce [5] OCTET STRING OPTIONAL, + recipNonce [6] OCTET STRING OPTIONAL, + -- nonces used to provide replay protection, senderNonce + + + +Adams & Farrell Standards Track [Page 20] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- is inserted by the creator of this message; recipNonce + -- is a nonce previously inserted in a related message by + -- the intended recipient of this message + freeText [7] PKIFreeText OPTIONAL, + -- this may be used to indicate context-specific instructions + -- (this field is intended for human consumption) + generalInfo [8] SEQUENCE SIZE (1..MAX) OF + InfoTypeAndValue OPTIONAL + -- this may be used to convey context-specific information + -- (this field not primarily intended for human consumption) + } + + PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String + -- text encoded as UTF-8 String (note: each UTF8String SHOULD + -- include an RFC 1766 language tag to indicate the language + -- of the contained text) + + The pvno field is fixed (at one) 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 + usable 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) which + 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). + + + + + + + +Adams & Farrell Standards Track [Page 21] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + The transactionID field within the message header MAY be used to + allow the recipient of a response message to correlate this with a + previously issued request. For example, in the case of an RA there + may be many requests "outstanding" at a given moment. + + The senderNonce and recipNonce fields protect the PKIMessage against + replay attacks. + + The messageTime field contains the time at which the sender created + the message. This may be useful to allow end entities to correct + their local time to be consistent 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. + +3.1.2 PKI Message Body + + PKIBody ::= CHOICE { -- message-specific body elements + ir [0] CertReqMessages, --Initialization Request + ip [1] CertRepMessage, --Initialization Response + cr [2] CertReqMessages, --Certification Request + cp [3] CertRepMessage, --Certification Response + p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. + -- the PKCS #10 certification request (see [PKCS10]) + 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 Request + krp [10] KeyRecRepContent, --Key Recovery Response + rr [11] RevReqContent, --Revocation Request + rp [12] RevRepContent, --Revocation Response + ccr [13] CertReqMessages, --Cross-Cert. Request + ccp [14] CertRepMessage, --Cross-Cert. Response + ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. + cann [16] CertAnnContent, --Certificate Ann. + rann [17] RevAnnContent, --Revocation Ann. + crlann [18] CRLAnnContent, --CRL Announcement + conf [19] PKIConfirmContent, --Confirmation + nested [20] NestedMessageContent, --Nested Message + genm [21] GenMsgContent, --General Message + genp [22] GenRepContent, --General Response + error [23] ErrorMsgContent --Error Message + } + + + +Adams & Farrell Standards Track [Page 22] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + The specific types are described in Section 3.3 below. + +3.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 + 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 instead + be applied. 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); specification of external protection using PKCS #7 will + be provided in a separate document. 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: + + + + +Adams & Farrell Standards Track [Page 23] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + - 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: + + PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13} + PBMParameter ::= SEQUENCE { + salt OCTET STRING, + owf AlgorithmIdentifier, + -- AlgId for a One-Way Function (SHA-1 recommended) + iterationCount INTEGER, + -- number of times the OWF is applied + mac AlgorithmIdentifier + -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], + } -- or HMAC [RFC2104, RFC2202]) + + 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.] + + - DH key pairs + + Where the sender and receiver possess Diffie-Hellman certificates + with compatible DH parameters, then 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: + + + + + + + + + + +Adams & Farrell Standards Track [Page 24] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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.] + + - signature + + Where the sender possesses a signature key pair it may simply sign + 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). + + - 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 ::= PKIMessage + +3.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. + + + + + + + + +Adams & Farrell Standards Track [Page 25] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.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 Confirmation message may be + withheld, or an Error Message may be sent (with a PKIStatus of + "rejection"). + + See [CRMF] for CertTemplate syntax. + +3.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 respectively be able to encrypt and decrypt. 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. + +3.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 { + granted (0), + -- you got exactly what you asked for + grantedWithMods (1), + -- you got something like what you asked for; the + -- requester is responsible for ascertaining the differences + rejection (2), + -- you don't get it, more information elsewhere in the message + + + +Adams & Farrell Standards Track [Page 26] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + waiting (3), + -- the request body part has not yet been processed, + -- expect to hear more later + revocationWarning (4), + -- this message contains a warning that a revocation is + -- imminent + revocationNotification (5), + -- notification that a revocation has occurred + keyUpdateWarning (6) + -- update already done for the oldCertId specified in + -- the key update request message + } + + Responders may use the following syntax to provide more information + about failure cases. + + PKIFailureInfo ::= BIT STRING { + -- since we can fail in more than one way! + -- More codes may be added in the future if/when required. + badAlg (0), + -- unrecognized or unsupported Algorithm Identifier + badMessageCheck (1), + -- integrity check failed (e.g., signature did not verify) + badRequest (2), + -- transaction not permitted or supported + badTime (3), + -- messageTime was not sufficiently close to the system time, + -- as defined by local policy + badCertId (4), + -- no certificate could be found matching the provided criteria + badDataFormat (5), + -- the data submitted has the wrong format + wrongAuthority (6), + -- the authority indicated in the request is different from the + -- one creating the response token + incorrectData (7), + -- the requester's data is incorrect (used for notary services) + missingTimeStamp (8), + -- when the timestamp is missing but should be there (by policy) + badPOP (9) + -- the proof-of-possession failed + } + PKIStatusInfo ::= SEQUENCE { + status PKIStatus, + statusString PKIFreeText OPTIONAL, + failInfo PKIFailureInfo OPTIONAL + } + + + + +Adams & Farrell Standards Track [Page 27] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.2.4 Certificate Identification + + In order to identify particular certificates the CertId data + structure is used. + + See [CRMF] for CertId syntax. + +3.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 which 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: + + - The certificate MUST be self-signed (i.e., the signature must be + verifiable using the SubjectPublicKeyInfo field); + - The subject and issuer fields MUST be identical; + - If the subject field is NULL then both subjectAltNames and + issuerAltNames extensions MUST be present and have exactly the same + value; + - 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 + -- hashVal is calculated over the self-signed + -- certificate with the identifier certID. + } + + 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. + + + + + + + +Adams & Farrell Standards Track [Page 28] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.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. + +3.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. + +3.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 [CRMF] for POPOSigningKey syntax, but note that + POPOSigningKeyInput has the following semantic stipulations in this + specification. + + POPOSigningKeyInput ::= SEQUENCE { + authInfo CHOICE { + sender [0] GeneralName, + -- from PKIHeader (used only if an authenticated identity + -- has been established for the sender (e.g., a DN from a + -- previously-issued and currently-valid certificate)) + publicKeyMAC [1] PKMACValue + -- used if no authenticated GeneralName currently exists for + -- the sender; publicKeyMAC contains a password-based MAC + -- (using the protectionAlg AlgId from PKIHeader) on the + -- DER-encoded value of publicKey + }, + publicKey SubjectPublicKeyInfo -- from CertTemplate + } + + 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. + + 1) By the inclusion of the private key (encrypted) in the + CertRequest (in the PKIArchiveOptions control structure). + + + + +Adams & Farrell Standards Track [Page 29] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 2) 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 2.3.2. The end entity proves knowledge of the private + decryption key to the CA by MACing the PKIConfirm message using + a key derived from this symmetric key. [Note that if more than + one CertReqMsg is included in the PKIMessage, then the CA uses + a different symmetric key for each CertReqMsg and the MAC uses + a key derived from the concatenation of all these keys.] The + MACing procedure uses the PasswordBasedMac AlgId defined in + Section 3.1. + + 3) 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 2.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 ---> + <--- rep ----- + ---- conf ---> + + 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. + + 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 + + + +Adams & Farrell Standards Track [Page 30] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + parenthetical text of the challenge field of "Challenge" below is + replaced with "(using PreferredSymmAlg (see Appendix B6) 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 nonces used in the + PKIHeader and by the protection (MACing or signing) applied to the + PKIMessage. + + POPODecKeyChallContent ::= SEQUENCE OF Challenge + -- One Challenge per encryption key certification request (in the + -- same order as these requests appear in CertReqMessages). + + Challenge ::= SEQUENCE { + owf AlgorithmIdentifier OPTIONAL, + -- MUST be present in the first Challenge; MAY be omitted in any + -- subsequent Challenge in POPODecKeyChallContent (if omitted, + -- then the owf used in the immediately preceding Challenge is + -- to be used). + witness OCTET STRING, + -- the result of applying the one-way function (owf) to a + -- randomly-generated INTEGER, A. [Note that a different + -- INTEGER MUST be used for each Challenge.] + challenge OCTET STRING + -- the encryption (under the public key for which the cert. + -- request is being made) of Rand, where Rand is specified as + -- Rand ::= SEQUENCE { + -- int INTEGER, + -- - the randomly-generated INTEGER A (above) + -- sender GeneralName + -- - the sender's name (as included in PKIHeader) + -- } + } + + POPODecKeyRespContent ::= SEQUENCE OF INTEGER + -- One INTEGER per encryption key certification request (in the + -- same order as these requests appear in CertReqMessages). The + -- retrieved INTEGER A (above) is returned to the sender of the + -- corresponding Challenge. + + + + +Adams & Farrell Standards Track [Page 31] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.3 Operation-Specific Data Structures + +3.3.1 Initialization Request + + An Initialization request message contains as the PKIBody an + CertReqMessages data structure which specifies the requested + certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity + are the template fields which may be supplied for each certificate + requested (see Appendix B profiles for further information). This + message is intended to be used for entities first initializing into + the PKI. + + See [CRMF] for CertReqMessages syntax. + +3.3.2 Initialization Response + + An Initialization response message contains as the PKIBody an + CertRepMessage data structure which has for each certificate + requested a PKIStatusInfo field, a subject certificate, and possibly + a private key (normally encrypted with a session key, which is itself + encrypted with the protocolEncKey). + + See Section 3.3.4 for CertRepMessage syntax. Note that if the PKI + Message Protection is "shared secret information" (see Section + 3.1.3), then any certificate transported in the caPubs field may be + directly trusted as a root CA certificate by the initiator. + +3.3.3 Registration/Certification Request + + A Registration/Certification request message contains as the PKIBody + a CertReqMessages data structure which specifies the requested + certificates. This message is intended to be used for existing PKI + entities who wish to obtain additional certificates. + + See [CRMF] for CertReqMessages syntax. + + Alternatively, the PKIBody MAY be a CertificationRequest (this + structure is fully specified by the ASN.1 structure + CertificationRequest given in [PKCS10]). This structure may be + required for certificate requests for signing key pairs when + interoperation with legacy systems is desired, but its use is + strongly discouraged whenever not absolutely necessary. + + + + + + + + + +Adams & Farrell Standards Track [Page 32] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.3.4 Registration/Certification Response + + A registration response message contains as the PKIBody a + CertRepMessage data structure which has a status value for each + certificate requested, and optionally has a CA public key, failure + information, a subject certificate, and an encrypted private key. + + CertRepMessage ::= SEQUENCE { + caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, + response SEQUENCE OF CertResponse + } + + CertResponse ::= SEQUENCE { + certReqId INTEGER, + -- to match this response with corresponding request (a value + -- of -1 is to be used if certReqId is not specified in the + -- corresponding request) + status PKIStatusInfo, + certifiedKeyPair CertifiedKeyPair OPTIONAL, + rspInfo OCTET STRING OPTIONAL + -- analogous to the id-regInfo-asciiPairs OCTET STRING defined + -- for regInfo in CertReqMsg [CRMF] + } + + CertifiedKeyPair ::= SEQUENCE { + certOrEncCert CertOrEncCert, + privateKey [0] EncryptedValue OPTIONAL, + publicationInfo [1] PKIPublicationInfo OPTIONAL + } + + CertOrEncCert ::= CHOICE { + certificate [0] Certificate, + encryptedCert [1] EncryptedValue + } + + Only one of the failInfo (in PKIStatusInfo) and certificate (in + CertifiedKeyPair) fields can be present in each CertResponse + (depending on the status). For some status values (e.g., waiting) + neither of the optional fields will be present. + + Given an EncryptedCert and the relevant decryption key the + certificate may be obtained. The purpose of this is to allow a CA to + return the value of a certificate, but with the constraint that only + the intended recipient can obtain the actual certificate. The benefit + of this approach is that a CA may reply with a certificate even in + the absence of a proof that the requester is the end entity which can + use the relevant private key (note that the proof is not obtained + + + + +Adams & Farrell Standards Track [Page 33] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + until the PKIConfirm message is received by the CA). Thus the CA will + not have to revoke that certificate in the event that something goes + wrong with the proof of possession. + +3.3.5 Key update request content + + For key update requests the CertReqMessages syntax is used. + Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template + fields which may be supplied for each key to be updated. This + message is intended to be used to request updates to existing (non- + revoked and non-expired) certificates. + + See [CRMF] for CertReqMessages syntax. + +3.3.6 Key Update response content + + For key update responses the CertRepMessage syntax is used. The + response is identical to the initialization response. + + See Section 3.3.4 for CertRepMessage syntax. + +3.3.7 Key Recovery Request content + + For key recovery requests the syntax used is identical to the + initialization request CertReqMessages. Typically, + SubjectPublicKeyInfo and KeyId are the template fields which may be + used to supply a signature public key for which a certificate is + required (see Appendix B profiles for further information). + + See [CRMF] for CertReqMessages syntax. Note that if a key history is + required, the requester must supply a Protocol Encryption Key control + in the request message. + +3.3.8 Key recovery response content + + For key recovery responses the following syntax is used. For some + status values (e.g., waiting) none of the optional fields will be + present. + + KeyRecRepContent ::= SEQUENCE { + status PKIStatusInfo, + newSigCert [0] Certificate OPTIONAL, + caCerts [1] SEQUENCE SIZE (1..MAX) OF + Certificate OPTIONAL, + keyPairHist [2] SEQUENCE SIZE (1..MAX) OF + CertifiedKeyPair OPTIONAL + } + + + + +Adams & Farrell Standards Track [Page 34] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.3.9 Revocation Request Content + + When requesting revocation of a certificate (or several certificates) + the following data structure is used. The name of the requester is + present in the PKIHeader structure. + + RevReqContent ::= SEQUENCE OF RevDetails + + RevDetails ::= SEQUENCE { + certDetails CertTemplate, + -- allows requester to specify as much as they can about + -- the cert. for which revocation is requested + -- (e.g., for cases in which serialNumber is not available) + revocationReason ReasonFlags OPTIONAL, + -- the reason that revocation is requested + badSinceDate GeneralizedTime OPTIONAL, + -- indicates best knowledge of sender + crlEntryDetails Extensions OPTIONAL + -- requested crlEntryExtensions + } + +3.3.10 Revocation Response Content + + The response to the above message. If produced, this is sent to the + requester of the revocation. (A separate revocation announcement + message MAY be sent to the subject of the certificate for which + revocation was requested.) + + RevRepContent ::= SEQUENCE { + status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, + -- in same order as was sent in RevReqContent + revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, + -- IDs for which revocation was requested (same order as status) + crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL + -- the resulting CRLs (there may be more than one) + } + +3.3.11 Cross certification request content + + Cross certification requests use the same syntax (CertReqMessages) as + for normal certification requests with the restriction that the key + pair MUST have been generated by the requesting CA and the private + key MUST NOT be sent to the responding CA. + + See [CRMF] for CertReqMessages syntax. + + + + + + +Adams & Farrell Standards Track [Page 35] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +3.3.12 Cross certification response content + + Cross certification responses use the same syntax (CertRepMessage) as + for normal certification responses with the restriction that no + encrypted private key can be sent. + + See Section 3.3.4 for CertRepMessage syntax. + +3.3.13 CA Key Update Announcement content + + When a CA updates its own key pair the following data structure MAY + be used to announce this event. + + CAKeyUpdAnnContent ::= SEQUENCE { + oldWithNew Certificate, -- old pub signed with new priv + newWithOld Certificate, -- new pub signed with old priv + newWithNew Certificate -- new pub signed with new priv + } + +3.3.14 Certificate Announcement + + This structure MAY be used to announce the existence of certificates. + + Note that this message is intended to be used for those cases (if + any) where there is no pre-existing method for publication of + certificates; it is not intended to be used where, for example, X.500 + is the method for publication of certificates. + + CertAnnContent ::= Certificate + +3.3.15 Revocation Announcement + + When a CA has revoked, or is about to revoke, a particular + certificate it MAY issue an announcement of this (possibly upcoming) + event. + + RevAnnContent ::= SEQUENCE { + status PKIStatus, + certId CertId, + willBeRevokedAt GeneralizedTime, + badSinceDate GeneralizedTime, + crlDetails Extensions OPTIONAL + -- extra CRL details(e.g., crl number, reason, location, etc.) + } + + + + + + + +Adams & Farrell Standards Track [Page 36] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + A CA MAY use such an announcement to warn (or notify) a subject that + its certificate is about to be (or has been) revoked. This would + typically be used where the request for revocation did not come from + the subject concerned. + + The willBeRevokedAt field contains the time at which a new entry will + be added to the relevant CRLs. + +3.3.16 CRL Announcement + + When a CA issues a new CRL (or set of CRLs) the following data + structure MAY be used to announce this event. + + CRLAnnContent ::= SEQUENCE OF CertificateList + +3.3.17 PKI Confirmation content + + This data structure is used in three-way protocols as the final + PKIMessage. Its content is the same in all cases - actually there is + no content since the PKIHeader carries all the required information. + + PKIConfirmContent ::= NULL + +3.3.18 PKI General Message content + + InfoTypeAndValue ::= SEQUENCE { + infoType OBJECT IDENTIFIER, + infoValue ANY DEFINED BY infoType OPTIONAL + } + -- Example InfoTypeAndValue contents include, but are not limited to: + -- { CAProtEncCert = {id-it 1}, Certificate } + -- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier } + -- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier } + -- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier } + -- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent } + -- { CurrentCRL = {id-it 6}, CertificateList } + -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} + -- This construct MAY also be used to define new PKIX Certificate + -- Management Protocol request and response messages, or general- + -- purpose (e.g., announcement) messages for future needs or for + -- specific environments. + + GenMsgContent ::= SEQUENCE OF InfoTypeAndValue + -- May be sent by EE, RA, or CA (depending on message content). + -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically + -- be omitted for some of the examples given above. The receiver is + + + + + +Adams & Farrell Standards Track [Page 37] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- free to ignore any contained OBJ. IDs that it does not recognize. + -- If sent from EE to CA, the empty set indicates that the CA may send + -- any/all information that it wishes. + +3.3.19 PKI General Response content + + GenRepContent ::= SEQUENCE OF InfoTypeAndValue + -- The receiver is free to ignore any contained OBJ. IDs that it does + -- not recognize. + +3.3.20 Error Message content + + ErrorMsgContent ::= SEQUENCE { + pKIStatusInfo PKIStatusInfo, + errorCode INTEGER OPTIONAL, + -- implementation-specific error codes + errorDetails PKIFreeText OPTIONAL + -- implementation-specific error details + } + +4. Mandatory PKI Management functions + + The PKI management functions outlined in Section 1 above are + described in this section. + + This section deals with functions that are "mandatory" in the sense + that all end entity and CA/RA implementations MUST be able to provide + the functionality described (perhaps via one of the transport + mechanisms defined in Section 5). This part is effectively the + profile of the PKI management functionality that MUST be supported. + + Note that not all PKI management functions result in the creation of + a PKI message. + +4.1 Root CA initialization + + [See Section 1.2.2 for this document's definition of "root CA".] + + 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 public key. 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. + + + +Adams & Farrell Standards Track [Page 38] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + The data structure used to carry the fingerprint is the OOBCertHash. + +4.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 2.4.1) are 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. + +4.3 Subordinate CA initialization + + [See Section 1.2.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. + +4.4 CRL production + + Before issuing any certificates a newly established CA (which issues + CRLs) must produce "empty" versions of each CRL which is to be + periodically produced. + +4.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 any other authenticated means (if the end + entity has an existing certificate). + + + + + + +Adams & Farrell Standards Track [Page 39] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +4.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. + +4.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. + + The requester CA initiates the exchange by generating a random number + (requester random number). The requester CA then sends to the + responder CA the cross certification request (ccr) message. 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 checks the protocol + version, saves the requester random number, generates its own random + number (responder random number) and validates the MAC. It then + + + +Adams & Farrell Standards Track [Page 40] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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 checks that its own + system time is close to the responder CA system time, checks the + received random numbers and validates the MAC. The requester CA + responds with the PKIConfirm message. The fields in this message are + protected from modification with a MAC based on the authorization + code. The requester CA writes the requester certificate to the + Repository. + + Upon receipt of the PKIConfirm message, the responder CA checks the + random numbers and validates the MAC. + + Notes: + + 1. The ccr message must contain a "complete" certification request, + that is, all fields (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). + +4.7 End entity initialization + + As with CAs, end entities must be initialized. Initialization of end + entities requires at least two steps: + + - acquisition of PKI information + - 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). + +4.7.1 Acquisition of PKI information + + The information REQUIRED is: + + - the current root-CA public key + - (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 + - the algorithms and algorithm parameters which the certifying CA + supports for each relevant usage + + + +Adams & Farrell Standards Track [Page 41] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + Additional information could be required (e.g., supported extensions + or CA policy information) in order to produce a certification request + which 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 4.5. + +4.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 4.1 for further details. + +4.8 Certificate Request + + An initialized end entity MAY request a certificate at any time (as + part of an update procedure, or for any other 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. + +4.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. The request is made using a key + update request (kur) message. 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. + +5. Transports + + The transport protocols specified below allow end entities, RAs and + CAs to pass PKI messages between them. There is no requirement for + specific security mechanisms to be applied at this level if the PKI + messages are suitably protected (that is, if the OPTIONAL + PKIProtection parameter is used as specified for each message). + + + +Adams & Farrell Standards Track [Page 42] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +5.1 File based protocol + + A file containing a PKI message MUST contain only the DER encoding of + one PKI message, i.e., there MUST be no extraneous header or trailer + information in the file. + + Such files can be used to transport PKI messages using, e.g., FTP. + +5.2 Direct TCP-Based Management Protocol + + The following simple TCP-based protocol is to be used for transport + of PKI messages. This protocol is suitable for cases where an end + entity (or an RA) initiates a transaction and can poll to pick up the + results. + + If a transaction is initiated by a PKI entity (RA or CA) then an end + entity must either supply a listener process or be supplied with a + polling reference (see below) in order to allow it to pick up the PKI + message from the PKI management component. + + The protocol basically assumes a listener process on an RA or CA + which can accept PKI messages on a well-defined port (port number + 829). Typically an initiator binds to this port and submits the + initial PKI message for a given transaction ID. The responder replies + with a PKI message and/or with a reference number to be used later + when polling for the actual PKI message response. + + If a number of PKI response messages are to be produced for a given + request (say if some part of the request is handled more quickly than + another) then a new polling reference is also returned. + + When the final PKI response message has been picked up by the + initiator then no new polling reference is supplied. + + The initiator of a transaction sends a "direct TCP-based PKI message" + to the recipient. The recipient responds with a similar message. + + A "direct TCP-based PKI message" consists of: + + length (32-bits), flag (8-bits), value (defined below) + + The length field contains the number of octets of the remainder of + the message (i.e., number of octets of "value" plus one). All 32-bit + values in this protocol are specified to be in network byte order. + + Message name flag value + + pkiMsg '00'H DER-encoded PKI message + + + +Adams & Farrell Standards Track [Page 43] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- PKI message + pollRep '01'H polling reference (32 bits), + time-to-check-back (32 bits) + -- poll response where no PKI message response ready; use polling + -- reference value (and estimated time value) for later polling + pollReq '02'H polling reference (32 bits) + -- request for a PKI message response to initial message + negPollRep '03'H '00'H + -- no further polling responses (i.e., transaction complete) + partialMsgRep '04'H next polling reference (32 bits), + time-to-check-back (32 bits), + DER-encoded PKI message + -- partial response to initial message plus new polling reference + -- (and estimated time value) to use to get next part of response + finalMsgRep '05'H DER-encoded PKI message + -- final (and possibly sole) response to initial message + errorMsgRep '06'H human readable error message + -- produced when an error is detected (e.g., a polling reference is + -- received which doesn't exist or is finished with) + + Where a PKIConfirm message is to be transported (always from the + initiator to the responder) then a pkiMsg message is sent and a + negPollRep is returned. + + The sequence of messages which can occur is then: + + a) end entity sends pkiMsg and receives one of pollRep, negPollRep, + partialMsgRep or finalMsgRep in response. b) end entity sends + pollReq message and receives one of negPollRep, partialMsgRep, + finalMsgRep or errorMsgRep in response. + + The "time-to-check-back" parameter is a 32-bit integer, defined to be + the number of seconds which have elapsed since midnight, January 1, + 1970, coordinated universal time. It provides an estimate of the + time that the end entity should send its next pollReq. + +5.3 Management Protocol via E-mail + + This subsection specifies a means for conveying ASN.1-encoded + messages for the protocol exchanges described in Section 4 via + Internet mail. + + A simple MIME object is specified as follows. + + Content-Type: application/pkixcmp + Content-Transfer-Encoding: base64 + + <<the ASN.1 DER-encoded PKIX-CMP message, base64-encoded>> + + + +Adams & Farrell Standards Track [Page 44] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + This MIME object can be sent and received using common MIME + processing engines and provides a simple Internet mail transport for + PKIX-CMP messages. Implementations MAY wish to also recognize and + use the "application/x-pkixcmp" MIME type (specified in earlier + versions of this document) in order to support backward compatibility + wherever applicable. + +5.4 Management Protocol via HTTP + + This subsection specifies a means for conveying ASN.1-encoded + messages for the protocol exchanges described in Section 4 via the + HyperText Transfer Protocol. + + A simple MIME object is specified as follows. + + Content-Type: application/pkixcmp + + <<the ASN.1 DER-encoded PKIX-CMP message>> + + This MIME object can be sent and received using common HTTP + processing engines over WWW links and provides a simple browser- + server transport for PKIX-CMP messages. Implementations MAY wish to + also recognize and use the "application/x-pkixcmp" MIME type + (specified in earlier versions of this document) in order to support + backward compatibility wherever applicable. + +SECURITY CONSIDERATIONS + + This entire memo is about security mechanisms. + + One cryptographic consideration is 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. + + + + + + +Adams & Farrell Standards Track [Page 45] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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. + +References + + [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC + 9594-8: 1990 & 1993 (1995:E), July 1995. + + [CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Certificate + Request Message Format", RFC 2511, March 1999. + + [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of + Applied Cryptography", CRC Press, 1997. + + [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards + (PKCS)", RSA Data Security Inc., Redwood City, California, + November 1993 Release. + + [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards + (PKCS)", RSA Data Security Inc., Redwood City, California, + November 1993 Release. + + [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - + PKCS #11: Cryptographic token interface standard", RSA + Data Security Inc., Redwood City, California, April 28, + 1995. + + [RFC1847] Galvin, J., Murphy, S. Crocker, S. and N. Freed, "Security + Multiparts for MIME: Multipart/Signed and Multipart/ + Encrypted", RFC 1847, October 1995. + + [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. + + [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC + 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, + and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 + December, 1996. + + + +Adams & Farrell Standards Track [Page 46] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +Acknowledgements + + The authors gratefully acknowledge the contributions of various + members of the PKIX Working Group. Many of these contributions + significantly clarified and improved the utility of this + specification. + +Authors' Addresses + + Carlisle Adams + Entrust Technologies + 750 Heron Road, Suite E08, + Ottawa, Ontario + Canada K1V 1A7 + + EMail: cadams@entrust.com + + + Stephen Farrell + Software and Systems Engineering Ltd. + Fitzwilliam Court + Leeson Close + Dublin 2 + IRELAND + + EMail: stephen.farrell@sse.ie + + + + + + + + + + + + + + + + + + + + + + + + + +Adams & Farrell Standards Track [Page 47] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +APPENDIX A: Reasons for the presence of RAs + + The reasons which justify the presence of an RA can be split into + those which are due to technical factors and those which are + organizational in nature. Technical reasons include the following. + + -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). + + -Some end entities may not have the capability to publish + certificates; again, the RA may be suitably placed for this. + + -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 which argue for the presence of an + RA are the following. + + -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). + + -Establishing RAs within an organization can reduce the number of + CAs required, which is sometimes desirable. + + -RAs may be better placed to identify people with their + "electronic" names, especially if the CA is physically remote from + the end entity. + + -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). + + + + + + + + + + + + + + + +Adams & Farrell Standards Track [Page 48] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +Appendix B. PKI Management Message Profiles. + + This appendix contains detailed profiles for those PKIMessages which + MUST be supported by conforming implementations (see Section 4). + + Profiles for the PKIMessages used in the following PKI management + operations are provided: + + - root CA key update + - information request/response + - cross-certification request/response (1-way) + - initial registration/certification + - basic authenticated scheme + - certificate request + - key update + + <<Later versions of this document may extend the above to include + profiles for the operations listed below (along with other + operations, if desired).>> + + - revocation request + - certificate publication + - CRL publication + +B1. 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., pvno). + 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. + + + +Adams & Farrell Standards Track [Page 49] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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 Sections B7-B10 require a PKIConfirm + message to be sent by the initiating entity. This message 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). + +B2. 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 + MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC, + messages using MACing X9.9... + SYM_PENC_ALG symmetric encryption of 3-DES (3-key- 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 + (symmetric keys for + encryption of) private + keys transported in + PKIMessages + PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5, + algorithm used for EDE, CBC mode) CAST-128... + encryption of private + key bits (a key of this + + + +Adams & Farrell Standards Track [Page 50] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + type is encrypted using + PROT_ENC_ALG) + +Mandatory AlgorithmIdentifiers and Specifications: + +DSA/SHA-1: + AlgId: {1 2 840 10040 4 3}; + NIST, FIPS PUB 186: Digital Signature Standard, 1994; + Public Modulus size: 1024 bits. + +PasswordBasedMac: + {1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf + parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter; + (this specification), along with + NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995; + H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message + Authentication", Internet Request for Comments 2104, February 1997. + +3-DES: + {1 2 840 113549 3 7}; + (used in RSA's BSAFE and in S/MIME). + +D-H: + AlgId: {1 2 840 10046 2 1}; + ANSI X9.42; + Public Modulus Size: 1024 bits. + DHParameter ::= SEQUENCE { + prime INTEGER, -- p + base INTEGER -- g + } + +B3. "Self-signed" certificates + + Profile of how a Certificate structure may be "self-signed". These + structures are used for distribution of "root" CA public keys. This + can occur in one of three ways (see Section 2.4 above for a + description of the use of these structures): + + Type Function + + newWithNew a true "self-signed" certificate; the contained public + key MUST be usable to verify the signature (though this + provides only integrity and no authentication whatsoever) + oldWithNew previous root CA public key signed with new private key + newWithOld new root CA public key signed with previous private key + + + + + + +Adams & Farrell Standards Track [Page 51] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + <<Such certificates (including relevant extensions) must contain + "sensible" values for all fields. For example, when present + subjectAltName MUST be identical to issuerAltName, and when present + keyIdentifiers must contain appropriate values, et cetera.>> + +B4. 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 which 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 which corresponds + to a public encryption key for which a certificate has been requested + does not use this profile; instead the method given in protectionAlg + for PKIConfirm in Section B8 is used.>> + + 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 which 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). + +B5. Root CA Key Update + + A root CA updates its key pair. It then produces a CA key update + announcement message which can be made available (via one of the + transport mechanisms) to the relevant end entities. A PKIConfirm + message is NOT REQUIRED from the end entities. + + ckuann message: + + Field Value Comment + + sender CA name responding CA name + body ckuann(CAKeyUpdAnnContent) + oldWithNew present see Section B3 above + + + +Adams & Farrell Standards Track [Page 52] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + newWithOld present see Section B3 above + newWithNew present see Section B3 above + extraCerts optionally present can be used to "publish" + certificates (e.g., + certificates signed using + the new private key) + +B6. PKI Information request/response + + The end entity sends general message to the PKI requesting details + which will be required for later PKI management operations. RA/CA + responds with general response. If an RA generates the response then + it will simply forward the equivalent message which it previously + received from the CA, with the possible addition of the certificates + to the extraCerts fields of the PKIMessage. A PKIConfirm message is + NOT REQUIRED from the end entity. + +Message Flows: + +Step# End entity PKI + + 1 format genm + 2 -> genm -> + 3 handle genm + 4 produce genp + 5 <- genp <- + 6 handle genp + + +genm: + +Field Value + +recipient CA name + -- the name of the CA as contained in issuerAltName extensions or + -- issuer fields within certificates +protectionAlg MSG_MAC_ALG or MSG_SIG_ALG + -- any authenticated protection alg. +SenderKID present if required + -- must be present if required for verification of message protection +freeText any valid value +body genr (GenReqContent) +GenMsgContent empty SEQUENCE + -- all relevant information requested +protection present + -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG + + + + + +Adams & Farrell Standards Track [Page 53] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +genp: + +Field Value + +sender CA name + -- name of the CA which produced the message +protectionAlg MSG_MAC_ALG or MSG_SIG_ALG + -- any authenticated protection alg. +senderKID present if required + -- must be present if required for verification of message protection +body genp (GenRepContent) +CAProtEncCert present (object identifier one + of PROT_ENC_ALG), with relevant + value + -- to be used if end entity needs to encrypt information for the CA + -- (e.g., private key for recovery purposes) +SignKeyPairTypes present, with relevant value + -- the set of signature algorithm identifiers which this CA will + -- certify for subject public keys +EncKeyPairTypes present, with relevant value + -- the set of encryption/key agreement algorithm identifiers which + -- this CA will certify for subject public keys +PreferredSymmAlg present (object identifier one + of PROT_SYM_ALG) , with relevant + value + -- the symmetric algorithm which this CA expects to be used in later + -- PKI messages (for encryption) +CAKeyUpdateInfo optionally present, with + relevant value + -- the CA MAY provide information about a relevant root CA key pair + -- using this field (note that this does not imply that the responding + -- CA is the root CA in question) +CurrentCRL optionally present, with relevant value + -- the CA MAY provide a copy of a complete CRL (i.e., fullest possible + -- one) +protection present + -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG +extraCerts optionally present + -- can be used to send some certificates to the end entity. An RA MAY + -- add its certificate here. + +B7. Cross certification request/response (1-way) + + Creation of a single cross-certificate (i.e., not two at once). The + requesting CA MAY choose who is responsible for publication of the + cross-certificate created by the responding CA through use of the + PKIPublicationInfo control. + + + + +Adams & Farrell Standards Track [Page 54] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + Preconditions: + + 1. Responding CA can verify the origin of the request (possibly + requiring out-of-band means) before processing the request. + 2. Requesting CA can authenticate the authenticity of the origin of + the response (possibly requiring out-of-band means) before + processing the response + +Message Flows: + +Step# Requesting CA Responding CA + 1 format ccr + 2 -> ccr -> + 3 handle ccr + 4 produce ccp + 5 <- ccp <- + 6 handle ccp + 7 format conf + 8 -> conf -> + 9 handle conf + + +ccr: +Field Value + +sender Requesting CA name + -- the name of the CA who produced the message +recipient Responding CA name + -- the name of the CA who is being asked to produce a certificate +messageTime time of production of message + -- current time at requesting CA +protectionAlg MSG_SIG_ALG + -- only signature protection is allowed for this request +senderKID present if required + -- must be present if required for verification of message protection +transactionID present + -- implementation-specific value, meaningful to requesting CA. + -- [If already in use at responding CA then a rejection message + -- MUST be produced by responding CA] +senderNonce present + -- 128 (pseudo-)random bits +freeText any valid value +body ccr (CertReqMessages) + only one CertReqMsg + allowed + -- if multiple cross certificates are required they MUST be packaged + -- in separate PKIMessages +certTemplate present + + + +Adams & Farrell Standards Track [Page 55] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- details follow +version v1 or v3 + -- <<v3 STRONGLY RECOMMENDED>> +signingAlg present + -- the requesting CA must know in advance with which algorithm it + -- wishes the certificate to be signed +subject present + -- may be NULL-DN only if subjectAltNames extension value proposed +validity present + -- MUST be completely specified (i.e., both fields present) +issuer present + -- may be NULL-DN only if issuerAltNames extension value proposed +publicKey present + -- the key to be certified (which must be for a signing algorithm) +extensions optionally present + -- a requesting CA must propose values for all extensions which it + -- requires to be in the cross-certificate + +POPOSigningKey present + -- see "Proof of possession profile" (Section B4) + +protection present + -- bits calculated using MSG_SIG_ALG +extraCerts optionally present + -- MAY contain any additional certificates that requester wishes + -- to include + + +ccp: +Field Value + +sender Responding CA name + -- the name of the CA who produced the message +recipient Requesting CA name + -- the name of the CA who asked for production of a certificate +messageTime time of production of message + -- current time at responding CA +protectionAlg MSG_SIG_ALG + -- only signature protection is allowed for this message +senderKID present if required + -- must be present if required for verification of message + -- protection +recipKID present if required +transactionID present + -- value from corresponding ccr message +senderNonce present + -- 128 (pseudo-)random bits +recipNonce present + + + +Adams & Farrell Standards Track [Page 56] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- senderNonce from corresponding ccr message +freeText any valid value +body ccp (CertRepMessage) + only one CertResponse allowed + -- if multiple cross certificates are required they MUST be packaged + -- in separate PKIMessages +response present +status present +PKIStatusInfo.status present + -- if PKIStatusInfo.status is one of: + -- granted, or + -- grantedWithMods, + -- then certifiedKeyPair MUST be present and failInfo MUST be absent +failInfo present depending on + PKIStatusInfo.status + -- if PKIStatusInfo.status is: + -- rejection + -- then certifiedKeyPair MUST be absent and failInfo MUST be present + -- and contain appropriate bit settings + + +certifiedKeyPair present depending on + PKIStatusInfo.status +certificate present depending on + certifiedKeyPair + -- content of actual certificate must be examined by requesting CA + -- before publication + +protection present + -- bits calculated using MSG_SIG_ALG +extraCerts optionally present + -- MAY contain any additional certificates that responder wishes + -- to include + +B8. 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 confirmation. 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). + + + +Adams & Farrell Standards Track [Page 57] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + 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 conf + 8 -> conf -> + 9 handle conf + + 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 which 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). + +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 + + + +Adams & Farrell Standards Track [Page 58] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +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 Section + -- B4 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]) +crm[0].certReq. present [object identifier MUST be PROT_ENC_ALG] + controls.protocolEncKey + -- 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 + + + +Adams & Farrell Standards Track [Page 59] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +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 +recipKID referenceNum + -- the reference number which 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 ir (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 "granted", "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 + "granted" 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) + + + +Adams & Farrell Standards Track [Page 60] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +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 "granted", "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 "granted" + or "grantedWithMods" +certificate present +privateKey present +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 + +conf: +Field Value + +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 + -- value from recipNonce in corresponding ip message +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 if only a signing key + -- pair has been sent in ir for certification, or if POP is not + -- done in this in-band exchange. Otherwise, the MAC is based on + -- a key derived from the symmetric key used to decrypt the + -- returned encryptedCert. +senderKID referenceNum + -- the reference number which the CA has previously issued to the + -- end entity (together with the MACing key) +body conf (PKIConfirmContent) + -- this is an ASN.1 NULL +protection present + -- bits calculated using MSG_MAC_ALG + + + +Adams & Farrell Standards Track [Page 61] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +B9. 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 confirmation. All messages + are authenticated. + + The profile for this exchange is identical to that given in Section + B8 with the following exceptions: + + - protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, + response, and confirm messages (the determination in the confirm + message being dependent upon POP considerations for key- + encipherment and key- agreement certificate requests); + - senderKID and recipKID are only present if required for message + verification; + - body is cr or cp; + - protocolEncKey is not present; + - protection bits are calculated according to the protectionAlg + field. + +B10. Key Update Request + + An (initialized) end entity requests a certificate from a CA (to + update the key pair and corresponding certificate that it already + possesses). When the CA responds with a message containing a + certificate, the end entity replies with a confirmation. All messages + are authenticated. + + The profile for this exchange is identical to that given in Section + B8 with the following exceptions: + + - protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, + response, and confirm messages (the determination in the confirm + message being dependent upon POP considerations for key- + encipherment and key- agreement certificate requests); + - senderKID and recipKID are only present if required for message + verification; + - body is kur or kup; + - protection bits are calculated according to the protectionAlg + field. + + + + + + + + + + +Adams & Farrell Standards Track [Page 62] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +Appendix C: "Compilable" ASN.1 Module using 1988 Syntax + + PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} + + DEFINITIONS EXPLICIT TAGS ::= + + BEGIN + + -- EXPORTS ALL -- + + IMPORTS + + Certificate, CertificateList, Extensions, AlgorithmIdentifier + FROM PKIX1Explicit88 {iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-pkix1-explicit-88(1)}} + + GeneralName, KeyIdentifier, ReasonFlags + FROM PKIX1Implicit88 {iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-pkix1-implicit-88(2)} + + CertTemplate, PKIPublicationInfo, EncryptedValue, CertId, + CertReqMessages + FROM PKIXCRMF {iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-mod-crmf(5)}} + + -- CertificationRequest + -- FROM PKCS10 {no standard ASN.1 module defined; + -- implementers need to create their own module to import + -- from, or directly include the PKCS10 syntax in this module} + + -- Locally defined OIDs -- + + PKIMessage ::= SEQUENCE { + header PKIHeader, + body PKIBody, + protection [0] PKIProtection OPTIONAL, + extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL + } + + PKIHeader ::= SEQUENCE { + pvno INTEGER { ietf-version2 (1) }, + sender GeneralName, + -- identifies the sender + recipient GeneralName, + + + +Adams & Farrell Standards Track [Page 63] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- identifies the intended recipient + messageTime [0] GeneralizedTime OPTIONAL, + -- time of production of this message (used when sender + -- believes that the transport will be "suitable"; i.e., + -- that the time will still be meaningful upon receipt) + protectionAlg [1] AlgorithmIdentifier OPTIONAL, + -- algorithm used for calculation of protection bits + senderKID [2] KeyIdentifier OPTIONAL, + recipKID [3] KeyIdentifier OPTIONAL, + -- to identify specific keys used for protection + transactionID [4] OCTET STRING OPTIONAL, + -- identifies the transaction; i.e., this will be the same in + -- corresponding request, response and confirmation messages + senderNonce [5] OCTET STRING OPTIONAL, + recipNonce [6] OCTET STRING OPTIONAL, + -- nonces used to provide replay protection, senderNonce + -- is inserted by the creator of this message; recipNonce + -- is a nonce previously inserted in a related message by + -- the intended recipient of this message + freeText [7] PKIFreeText OPTIONAL, + -- this may be used to indicate context-specific instructions + -- (this field is intended for human consumption) + generalInfo [8] SEQUENCE SIZE (1..MAX) OF + InfoTypeAndValue OPTIONAL + -- this may be used to convey context-specific information + -- (this field not primarily intended for human consumption) + } + + PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String + -- text encoded as UTF-8 String (note: each UTF8String SHOULD + -- include an RFC 1766 language tag to indicate the language + -- of the contained text) + + + PKIBody ::= CHOICE { -- message-specific body elements + ir [0] CertReqMessages, --Initialization Request + ip [1] CertRepMessage, --Initialization Response + cr [2] CertReqMessages, --Certification Request + cp [3] CertRepMessage, --Certification Response + p10cr [4] CertificationRequest, --imported from [PKCS10] + 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 Request + krp [10] KeyRecRepContent, --Key Recovery Response + rr [11] RevReqContent, --Revocation Request + rp [12] RevRepContent, --Revocation Response + + + +Adams & Farrell Standards Track [Page 64] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + ccr [13] CertReqMessages, --Cross-Cert. Request + ccp [14] CertRepMessage, --Cross-Cert. Response + ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. + cann [16] CertAnnContent, --Certificate Ann. + rann [17] RevAnnContent, --Revocation Ann. + crlann [18] CRLAnnContent, --CRL Announcement + conf [19] PKIConfirmContent, --Confirmation + nested [20] NestedMessageContent, --Nested Message + genm [21] GenMsgContent, --General Message + genp [22] GenRepContent, --General Response + error [23] ErrorMsgContent --Error Message + } + + PKIProtection ::= BIT STRING + + ProtectedPart ::= SEQUENCE { + header PKIHeader, + body PKIBody + } + + PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13} + + PBMParameter ::= SEQUENCE { + salt OCTET STRING, + owf AlgorithmIdentifier, + -- AlgId for a One-Way Function (SHA-1 recommended) + iterationCount INTEGER, + -- number of times the OWF is applied + mac AlgorithmIdentifier + -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], + } -- or HMAC [RFC2104, RFC2202]) + + 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]) + + + NestedMessageContent ::= PKIMessage + + PKIStatus ::= INTEGER { + granted (0), + -- you got exactly what you asked for + grantedWithMods (1), + + + +Adams & Farrell Standards Track [Page 65] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- you got something like what you asked for; the + -- requester is responsible for ascertaining the differences + rejection (2), + -- you don't get it, more information elsewhere in the message + waiting (3), + -- the request body part has not yet been processed, + -- expect to hear more later + revocationWarning (4), + -- this message contains a warning that a revocation is + -- imminent + revocationNotification (5), + -- notification that a revocation has occurred + keyUpdateWarning (6) + -- update already done for the oldCertId specified in + -- CertReqMsg + } + + PKIFailureInfo ::= BIT STRING { + -- since we can fail in more than one way! + -- More codes may be added in the future if/when required. + badAlg (0), + -- unrecognized or unsupported Algorithm Identifier + badMessageCheck (1), + -- integrity check failed (e.g., signature did not verify) + badRequest (2), + -- transaction not permitted or supported + badTime (3), + -- messageTime was not sufficiently close to the system time, + -- as defined by local policy + badCertId (4), + -- no certificate could be found matching the provided criteria + badDataFormat (5), + -- the data submitted has the wrong format + wrongAuthority (6), + -- the authority indicated in the request is different from the + -- one creating the response token + incorrectData (7), + -- the requester's data is incorrect (for notary services) + missingTimeStamp (8), + -- when the timestamp is missing but should be there (by policy) + badPOP (9) + -- the proof-of-possession failed + } + + PKIStatusInfo ::= SEQUENCE { + status PKIStatus, + statusString PKIFreeText OPTIONAL, + failInfo PKIFailureInfo OPTIONAL + + + +Adams & Farrell Standards Track [Page 66] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + } + + OOBCert ::= Certificate + + OOBCertHash ::= SEQUENCE { + hashAlg [0] AlgorithmIdentifier OPTIONAL, + certId [1] CertId OPTIONAL, + hashVal BIT STRING + -- hashVal is calculated over DER encoding of the + -- subjectPublicKey field of the corresponding cert. + } + + POPODecKeyChallContent ::= SEQUENCE OF Challenge + -- One Challenge per encryption key certification request (in the + -- same order as these requests appear in CertReqMessages). + + Challenge ::= SEQUENCE { + owf AlgorithmIdentifier OPTIONAL, + -- MUST be present in the first Challenge; MAY be omitted in any + -- subsequent Challenge in POPODecKeyChallContent (if omitted, + -- then the owf used in the immediately preceding Challenge is + -- to be used). + witness OCTET STRING, + -- the result of applying the one-way function (owf) to a + -- randomly-generated INTEGER, A. [Note that a different + -- INTEGER MUST be used for each Challenge.] + challenge OCTET STRING + -- the encryption (under the public key for which the cert. + -- request is being made) of Rand, where Rand is specified as + -- Rand ::= SEQUENCE { + -- int INTEGER, + -- - the randomly-generated INTEGER A (above) + -- sender GeneralName + -- - the sender's name (as included in PKIHeader) + -- } + } + + POPODecKeyRespContent ::= SEQUENCE OF INTEGER + -- One INTEGER per encryption key certification request (in the + -- same order as these requests appear in CertReqMessages). The + -- retrieved INTEGER A (above) is returned to the sender of the + -- corresponding Challenge. + + + CertRepMessage ::= SEQUENCE { + caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, + response SEQUENCE OF CertResponse + } + + + +Adams & Farrell Standards Track [Page 67] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + CertResponse ::= SEQUENCE { + certReqId INTEGER, + -- to match this response with corresponding request (a value + -- of -1 is to be used if certReqId is not specified in the + -- corresponding request) + status PKIStatusInfo, + certifiedKeyPair CertifiedKeyPair OPTIONAL, + rspInfo OCTET STRING OPTIONAL + -- analogous to the id-regInfo-asciiPairs OCTET STRING defined + -- for regInfo in CertReqMsg [CRMF] + } + + CertifiedKeyPair ::= SEQUENCE { + certOrEncCert CertOrEncCert, + privateKey [0] EncryptedValue OPTIONAL, + publicationInfo [1] PKIPublicationInfo OPTIONAL + } + + CertOrEncCert ::= CHOICE { + certificate [0] Certificate, + encryptedCert [1] EncryptedValue + } + + KeyRecRepContent ::= SEQUENCE { + status PKIStatusInfo, + newSigCert [0] Certificate OPTIONAL, + caCerts [1] SEQUENCE SIZE (1..MAX) OF + Certificate OPTIONAL, + keyPairHist [2] SEQUENCE SIZE (1..MAX) OF + CertifiedKeyPair OPTIONAL + } + + RevReqContent ::= SEQUENCE OF RevDetails + + RevDetails ::= SEQUENCE { + certDetails CertTemplate, + -- allows requester to specify as much as they can about + -- the cert. for which revocation is requested + -- (e.g., for cases in which serialNumber is not available) + revocationReason ReasonFlags OPTIONAL, + -- the reason that revocation is requested + badSinceDate GeneralizedTime OPTIONAL, + -- indicates best knowledge of sender + crlEntryDetails Extensions OPTIONAL + -- requested crlEntryExtensions + } + + RevRepContent ::= SEQUENCE { + + + +Adams & Farrell Standards Track [Page 68] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, + -- in same order as was sent in RevReqContent + revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, + -- IDs for which revocation was requested (same order as status) + crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL + -- the resulting CRLs (there may be more than one) + } + + + CAKeyUpdAnnContent ::= SEQUENCE { + oldWithNew Certificate, -- old pub signed with new priv + newWithOld Certificate, -- new pub signed with old priv + newWithNew Certificate -- new pub signed with new priv + } + + CertAnnContent ::= Certificate + + RevAnnContent ::= SEQUENCE { + status PKIStatus, + certId CertId, + willBeRevokedAt GeneralizedTime, + badSinceDate GeneralizedTime, + crlDetails Extensions OPTIONAL + -- extra CRL details(e.g., crl number, reason, location, etc.) +} + + CRLAnnContent ::= SEQUENCE OF CertificateList + + PKIConfirmContent ::= NULL + + InfoTypeAndValue ::= SEQUENCE { + infoType OBJECT IDENTIFIER, + infoValue ANY DEFINED BY infoType OPTIONAL + } + -- Example InfoTypeAndValue contents include, but are not limited to: + -- { CAProtEncCert = {id-it 1}, Certificate } + -- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier } + -- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier } + -- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier } + -- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent } + -- { CurrentCRL = {id-it 6}, CertificateList } + -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} + -- This construct MAY also be used to define new PKIX Certificate + -- Management Protocol request and response messages, or general- + -- purpose (e.g., announcement) messages for future needs or for + -- specific environments. + + GenMsgContent ::= SEQUENCE OF InfoTypeAndValue + + + +Adams & Farrell Standards Track [Page 69] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + + -- May be sent by EE, RA, or CA (depending on message content). + -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically + -- be omitted for some of the examples given above. The receiver is + -- free to ignore any contained OBJ. IDs that it does not recognize. + -- If sent from EE to CA, the empty set indicates that the CA may send + -- any/all information that it wishes. + + GenRepContent ::= SEQUENCE OF InfoTypeAndValue + -- The receiver is free to ignore any contained OBJ. IDs that it does + -- not recognize. + + ErrorMsgContent ::= SEQUENCE { + pKIStatusInfo PKIStatusInfo, + errorCode INTEGER OPTIONAL, + -- implementation-specific error codes + errorDetails PKIFreeText OPTIONAL + -- implementation-specific error details + } + + + +-- The following definition is provided for compatibility reasons with +-- 1988 and 1993 ASN.1 compilers which allow the use of UNIVERSAL class +-- tags (not a part of formal ASN.1); 1997 and subsequent compilers +-- SHOULD comment out this line. + +UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING + +END + + + + + + + + + + + + + + + + + + + + + + +Adams & Farrell Standards Track [Page 70] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +Appendix D: Registration of MIME Type for Section 5 + + To: ietf-types@iana.org + Subject: Registration of MIME media type application/pkixcmp + + MIME media type name: application + + MIME subtype name: pkixcmp + + Required parameters: - + + Optional parameters: - + + Encoding considerations: + Content may contain arbitrary octet values (the ASN.1 DER encoding of + a PKI message, as defined in the IETF PKIX Working Group + specifications). base64 encoding is required for MIME e-mail; no + encoding is necessary for HTTP. + + Security considerations: + This MIME type may be used to transport Public-Key Infrastructure + (PKI) messages between PKI entities. These messages are defined by + the IETF PKIX Working Group and are used to establish and maintain an + Internet X.509 PKI. There is no requirement for specific security + mechanisms to be applied at this level if the PKI messages themselves + are protected as defined in the PKIX specifications. + + Interoperability considerations: - + + Published specification: this document + + Applications which use this media type: + Applications using certificate management, operational, or ancillary + protocols (as defined by the IETF PKIX Working Group) to send PKI + messages via E-Mail or HTTP. + + Additional information: + + Magic number (s): - + File extension (s): ".PKI" + Macintosh File Type Code (s): - + + Person and email address to contact for further information: + Carlisle Adams, cadams@entrust.com + + Intended usage: COMMON + + Author/Change controller: Carlisle Adams + + + +Adams & Farrell Standards Track [Page 71] + +RFC 2510 PKI Certificate Management Protocols March 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Adams & Farrell Standards Track [Page 72] + |