Page 1 of 68
`
`>
`
`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]
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 1
`
`

`

`Page 2 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 2
`
`

`

`Page 3 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 3
`
`

`

`Page 4 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 4
`
`

`

`Page 5 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 5
`
`

`

`Page 6 of 68
`
`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 | <-----+ | |
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 6
`
`

`

`Page 7 of 68
`
`| 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.
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 7
`
`

`

`Page 8 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 8
`
`

`

`Page 9 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 9
`
`

`

`Page 10 of 68
`
`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.
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 10
`
`

`

`Page 11 of 68
`
`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.
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 11
`
`

`

`Page 12 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 12
`
`

`

`Page 13 of 68
`
`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
`
`file:///C:/Users/jgordo07/AppData/Local/Temp/Low/FCDGCK0N.htm
`
`5/28/2013
`
`Petitioner RPX Corporation - Ex. 1040, p. 13
`
`

`

`Page 14 of 68
`
`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