`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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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]
`
`Petitioner Apple Inc. - Exhibit 1060, p. 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 ve