Internet Draft Denis Pinkas, Bull draft-ietf-pkix-dpv-dpd-req-02.txt Russ Housley, RSA Laboratories Target Category: INFORMATIONAL February 2002 Expires in six months Delegated Path Validation and Delegated Path Discovery Protocol Requirements (DPV&DPD-REQ) Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). It also specifies the requirements for DPV and DPD policy management. 1. Introduction This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD), using two main request/response pairs. These delegated processing provides two primary services: DPV and DPD. Some clients require a server to perform path validation and have no need for data acquisition, while some other clients require only DPD in support of local path validation. The DPV request/response pair, can be used to fully delegate a path validation processing to an DPV server, according to a set of rules, called a validation policy. The DPD request/response pair can be used to obtain from a DPD server all the information needed (e.g., the end-entity certificate, the CA certificates, full CRLs, delta-CRLs, OCSP responses) to locally validate a certificate. The DPD server uses a set of rules, called a path discovery policy, to determine which information to return. Pinkas, Housley [Page 1] Internet Draft DPV&DPD-REQ January 2002 A third request/response pair can be used to allow clients to obtain the references for the policies supported by a DPV or DPD server. This document also defines the requirements for two optional request/ response pairs. The first one is used to establish a validation policy with a DPV server. The second one is used to establish a discovery policy with a DPD server. Either request/response pair provide a reference of an existing policy to obtain policy details. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. 2. Rationale and benefits for DPV (Delegated Path Validation) DPV allows a server to perform a real time certificate validation for a validation time T, where T may be the current time or a time in the recent past. In order to validate a certificate, a chain of multiple certificates, called a certification path, may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Offloading path validation to a server may be required by a client that lacks the processing, and/or communication capabilities to perform path construction first and then a local path validation. In constrained execution environments, such as telephones and PDAs, memory and processing limitations may preclude local implementation of complete, PKIX-compliant path validation. In applications where minimum latency is critical, delegating validation to a trusted server can offer significant advantages. The time required to send the target certificate to the validation server, receive the response, and authenticate the response, can be considerably less than the time required for the client to perform certification path discovery and validation. Even if a certification path were readily available to the client, the processing time associated with signature verification for each certificate in the path might (especially when validating very long paths or using very limited processor speed) be greater than the delay associated with use of a validation server. Another motivation for offloading path validation is that it allows validation against validation policies defined by the management in a consistent fashion across an enterprise. Clients that are able to do their own path validation may rely on a trusted server to do path validation if centralized management of validation policies is needed, or the clients rely on a trusted server to leave centralized traces of such activities. Pinkas, Housley [Page 2] Internet Draft DPV&DPD-REQ January 2002 When a client uses this service, it inherently trusts the server as much as it would its own path validation software (if it contained such software). Clients can direct the server to perform path validation in accordance with a particular validation policy. 3. Rationale and benefits for DPD (Delegated Path Discovery) DPD is valuable for clients that do much of the PKI processing themselves and simply want a server to collect information for them. The server is trusted to return the most current information that is available to it (which may not be the most current information that has been issued). The client will ultimately perform certification path validation. A client that performs path validation for itself may get benefit in several ways from using a server to acquire certificates, CRLs, and OCSP responses to aid in the validation process. In this context, the client is relying on the server to interact with repositories to acquire the data that the client would otherwise have to acquire using LDAP [LDAP], HTTP [HTTP], FTP [FTP] or another repository access protocol. Since these data items are digitally signed, the client need not trust the server any more than the client would trust the repositories. There are several benefits to this approach; for example, a single query to a server can replace multiple queries to one or more repositories, and caching by the server can reduce latency. Another benefit to the client system is that it need not incorporate a diverse set of software to interact with various forms of repositories, perhaps via different protocols, nor to perform the graph processing necessary to discover certification paths, separate from making the queries to acquire path validation data. 4. Delegated Path Validation Protocol Requirements The Delegated Path Validation (DPV) protocol allows a server to validate one or more certificates according to a validation policy. If the DPV server does not support the client requested validation policy, then the DPV server MUST return an error. The client can request that the server determine the certificate validity at a time other than the current time. Depending upon the validation policy being used, the validation time may either be the time for which the revocation status information has to be obtained, or the time for which the event for which the validity is tested took place. Since policy definitions can be quite long and complex, all the parameters SHOULD NOT be passed with each individual request; rather, they SHOULD be defined using a separate policy definition request/ response pair (see section 9). In this way clients only need to be aware of the reference of the validation policy to be used by a given application. Pinkas, Housley [Page 3] Internet Draft DPV&DPD-REQ January 2002 The certificate to be validated MUST either be directly provided in the request or an unambiguous reference MUST be provided, such as the CA distinguished name, certificate serial number, and the hash of the certificate, like ESSCertID as defined in [ESS] or OtherSigningCertificate as defined in [ES-F]. The client MUST be able to provide to the validation server, associated with each certificate to be validated, "useful certificates", as well as "useful revocation information". Revocation information includes OCSP responses, CRLs, and delta-CRLs. As an example, an S/MIME message might include such information, and the client can simply copy that information into the DPV request. The server MUST get the full certificate. If not provided in the request, the server MUST use the unambiguous reference provided by the client to obtain it. In order to obtain the revocation status information of any certificate from the certification path, the DPV server might use, in accordance with the validation policy, different sources of revocation information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs. If the DPV request does not specify a validation policy, the server response MUST indicate the one that was used. In such a case, the client MUST verify that the one selected by the server is appropriate. The DPV response MUST indicate one of four status alternatives: 1) the certificate is valid according to the validation policy. 2) the certificate is definitively invalid according to the validation policy. 3) the certificate is not yet valid at this time. If another request could made later on, the certificate could possibly be determined as valid. This condition will occur before a certificate validity period has begun, while a certificate is suspended, or when, at the time the server generated the response, all conditions of the validation policy could not be met. 4) the server cannot determine the validity of the certificate. This condition will occur when a certification path cannot be constructed or some revocation information is unavailable. The DPV request MUST allow the client to request the response to include the certification path and revocation status information used by the server to process the request. When requested, the server MUST include the certification path and revocation status information in the response when the certificate is valid according to the validation policy. However, the server MAY omit the certification path and revocation status information when the certificate is invalid, not yet valid or when it cannot determine the validity. Pinkas, Housley [Page 4] Internet Draft DPV&DPD-REQ January 2002 In order to be able to be confident that the validation of the certificate has correctly been done, the client only requires an authenticated response. In order for the client to prove to another party that trusts the same DPV server that the certificate validation was correct, the client requires a signed response. All the parameters needed to prove that the response conforms to the request SHALL be copied from the request into the response, so that a response is self-sufficient proof. The server may require client authentication. The authentication method to be used may be dependant upon the transport used, and thus the client authentication mechanism need not be an integral part of the DPV request. 5. Delegated Path Discovery Protocol Requirements The Delegated Path Discovery (DPD) protocol allows the client to use a single protocol towards a single server to collect at one time the data elements available at the current time that might be collected using different protocols (e.g. LDAP, DAP, OCSP) or by querying multiple servers, according to a single path discovery policy. Then returned information can be used to locally validate one or more certificates for the current time. Clients MUST be able to specify whether they want, in addition to the certification path, the revocation information associated with the path, for the end-entity certificate only, for the CA certificates only or for both. If the DPD server does not support the client requested path discovery policy, the DPD server MUST return an error. Some forms of path discovery policy can be simple. In that case it is acceptable to pass the parameters from the path discovery policy with each individual request, i.e. a set of trust anchors and separate revocation status conditions for the end-entity certificate and for the other certificates. More elaborated path discovery policies SHOULD be defined using a separate policy definition request/response pair (see section 9). Most of the time, clients only need to be aware of the reference of the path discovery policy to be used by a given application. The server response includes zero, one, or several certification paths. Each path consists of a sequence of certificates, starting with the certificate to be validated and ending with one issued by a trust anchor. The trust anchor self-signed certificate, if issued, is not included. In addition, if requested, the revocation information associated with each certificate in the path MUST also be returned. The client needs to be able to limit the number of paths returned. Therefore the client MUST be able to indicate the maximum number of certification paths that SHOULD be returned (provided that they can be found). If the number is not specified, that number defaults to one. Pinkas, Housley [Page 5] Internet Draft DPV&DPD-REQ January 2002 The paths that are returned may need to match some additional local controls done by the client, e.g. verifying some certificate extensions. The returned paths may not be appropriate to the client when it locally applies additional tests. Instead of asking one by one the paths (which would require state information at the server), the client specifies with every request the maximum number of paths to be returned. If that number cannot be reached by the server, an indication SHOULD be returned by the server showing that an additional query will not return more paths. If the paths that are returned do not match the local conditions, then the number of number of certification paths to be returned can be extended, by augmenting this value. Previously found paths will likely be returned, but the client can easily discard them. This avoids requirements for state information at the server, but does not prevent a server from maintaining a cache of previous responses. Avoiding the maintenance of state information for previous requests minimizes potential denial of service attacks or other problems associated with server crashes. Path discovery MUST be performed according to the path discovery policy. The DPD response MUST indicate one of four status alternatives: 1) one or more certification paths was found according to the path discovery policy, with all of the requested revocation information present. 2) one or more certification paths was found according to the path discovery policy, with a subset of the requested revocation information present. 3) one or more certification paths was found according to the path discovery policy, with none of the requested revocation information present. 4) no certification path was found according to the path discovery criteria. The information that is returned consists of one or more certification paths and optionally its associated revocation status information for each element from the path. To provide confidence that the response originates from the DPD server, the server MAY provide an authenticated response. For example, the server might sign the response. Pinkas, Housley [Page 6] Internet Draft DPV&DPD-REQ January 2002 6. Requirements common both to DPV and DPD The protocol SHALL allow clients to obtain the references for all of the policies supported by the server by using an additional request/response pair. The response can include references to previously defined policies or to a priori known policies. 7. Rationale and benefits for PDP (Policy Definition Protocol) Policies can be a priori known by the server, or policies can be specified by a client to the server. Because policies are controlled by many parameters which, if incorrectly set, can result in insecure behavior, it is useful to rely on pre-defined policies that are already known by the clients and the servers, Such policies are likely to be defined by system security administrators who carefully manage them. However, policy definitions may be quite complex and only some forms of policies can be defined using the request/response pair. 7.1. Validation Policy A validation policy is a set of rules against which the validation of the certificate is performed. A validation policy MAY include several trust anchors. A trust anchor is defined as one public key, a CA name, a validity time interval, and optionally additional constrains. The use of a self-signed certificate is one way to specify together: the public key to be used, the CA name, and the validity period of the public key. Additional constrains for each trust anchor MAY be defined. These constraints might include a set of Certification Policy constraints or a set of naming constraints. These constrains MAY also be included in self-signed certificates. Additional conditions that apply to the certificates in the path MAY also be specified in the validation policy. For example, specific values for user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, or initial-any-policy-inhibit could be provided. Additional conditions that apply to the end-entity certificate MAY also be specified in the validation policy. For example, a specific name form, like an e-mail address either in the rfc822 subject alternative name or in the emailAddress naming attribute in the subject name, might be required. In order to succeed, one valid certification path (i.e., none of the certificates in the path are expired or revoked) MUST be found between an end-entity certificate and a trust anchor and all constraints that apply to the certification path MUST be verified. Pinkas, Housley [Page 7] Internet Draft DPV&DPD-REQ January 2002 There is an inevitable delay between a compromise of key being noticed by the end-entity and the report of revocation being made by the CA (or on behalf of the CA) to the relying parties. This delay exists even when an OCSP service is used. So, querying the revocation status of a certificate at a time T does not prove that the private key corresponding to that certificate was not already compromised at an earlier time T' where the private key has been used. In case of a key compromise, the absolute difference between the time where a private key (corresponding to a given end-entity certificate) has been used and the time for which the revocation status information of that end-entity certificate is available for the time of use is composed of the sum of several time intervals: 1) the end-entity realizes that its private key has been or could possibly be compromised, 2) the end-entity reports the key compromise, 3) the revocation authority processes the revocation request from the end-entity, and 4) the revocation authority makes available the revocation status information, e.g. by providing an OCSP service, CRLs, or delta-CRLs in combination with full CRLs. The sum of all these time intervals is called a cautionary period. When the public key within the certificate is used to verify some usage from the recent past, it is possible to apply a cautionary period. This cautionary period may be applied either by the client or by the server. When it is applied by the client, the policy will consider the time at which the validity has to be determined as being directly the time for which the revocation status information has to obtained. When it is applied by the server, the policy will consider the time at which the validity has to be determined as being time when the private key (corresponding to the given end-entity certificate) was supposed to be used, i.e. the time for which the event for which the validity is to be tested took place. In such a case, the policy includes the definition of a cautionary period. 7.2. Path discovery policy A path discovery policy is a set of rules against which the discovery of a certification path is performed. A path discovery policy is a subset of a validation policy. A path discovery policy MAY either be a reference to a validation policy or contain only some major elements from a validation policy, such as the trust anchors. Since the DPD client is "PKI aware", it can locally apply additional constraints to the certification paths returned by the server. Thus, a simpler criteria can be defined and used for DPD. Pinkas, Housley [Page 8] Internet Draft DPV&DPD-REQ January 2002 8. Policy Definition Protocol (PDP) requirements These request/response pairs allow the client to define a policy, i.e. a validation policy and/or a path discovery policy, and to receive back a reference for that policy. The server may provide a reference to a previously defined policy, if it fulfills the request requirements. The support of these request/response pairs is OPTIONAL, or they might be implemented in a separate protocol from DPD or DPV. The policies locally defined at the server can be more precise than the policies defined using these request/response pairs, since such an exchange will not have all the flexibility necessary to describe any kind of policy. So, in practice, these request/response pairs will be restricted to the definition of relatively simple policies. Usually, these request/response pairs will be used by security managers to register the policies to be used by ordinary clients, such as those within an organization for use with various applications. Policy definition requests MUST be able to be authenticated so that only authorized clients can register policies. Policy definition response, if successful, MUST return a policy reference. The policy reference MAY be specific to the request, or it MAY be a reference to a policy that has already been established and fulfills the request requirements. It is up to server to decide how long a policy defined through this protocol will be maintained. When a obtaining a policy reference from the server, it would be interesting to consider providing natural language information about the purpose of the policy, rather than the technical description of the policy. When using DPV, there are two possibilities: a) The client is PKI-unaware, and thus fully delegates the validation to the server. It appears more difficult to remotely define such "complete policies" since the tests on the end-entity certificate are made by the server and may be quite complex. b) The client is a slightly PKI-aware, in the sense that it is only able to parse the end-entity certificate to check some properties of a certificate, and delegates the validation of the rest of the path to the server. It appears easier to remotely define such "partial policies" since some tests on the end- entity certificate are left to the client. Pinkas, Housley [Page 9] Internet Draft DPV&DPD-REQ January 2002 8.1 Components for a validation policy A validation policy is build from four components: 1. Certification path requirements, 2. Revocation requirements, 3. End-entity certificate specific requirements, 4. optionally, cautionary period requirements. Note: [ES-P] defines ASN.1 data elements that may be useful while defining the components of a validation policy. 8.1.1. Certificate chain requirements The PDP protocol MUST allow the client to specify certification path requirements. The path requirements identify a sequence of trust anchors used to start certification path processing and initial conditions for certification path validation as defined in [PKIX-1]. 8.1.2. Revocation Requirements The PDP protocol MUST allow the client to specify revocation checking requirements. Revocation information may be obtained through CRLs, delta-CRLs or OCSP responses. Certificate revocation requirements are specified both in terms of checks required on the end-entity certificate (i.e. the certificate for which a path is required) and on checks required on CA certificates. Revocation requirements for the end-entity certificate may not be the same as the requirements for the CA certificates. For example, an OCSP response may be needed for the end-entity certificate while CRLs may be sufficient for the CA certificates. Therefore, the PDP protocol MUST allow the client to specify separate requirements for the end-entity certificate and for the CA certificates. The PDP protocol MUST allow the client to specify the source of revocation information, in particular if : - full CRLs (or full Authority revocation lists) have to be collected, - OCSP responses, using [OCSP], have to be collected, - delta-CRLs and the relevant associated full CRLs (or full Authority revocation lists) are to be collected. - any available revocation information has to be collected. 8.1.3. End-entity certificate specific requirements The PDP protocol MUST allow the client to specify requirements that apply only to the end-entity certificate (i.e. the certificate that is the object of the query). Pinkas, Housley [Page 10] Internet Draft DPV&DPD-REQ January 2002 The client might require the end-entity certificate to contain specific extensions with specific types or values (it does not matter whether they are critical or non-critical). For example, the client might need an end-entity certificate that contains an electronic mail address (either in the rfc822 subject alt name or in the emailAddress naming attribute in the subject name). 8.1.4. Cautionary period requirements The PDP protocol SHALL allow the client to specify a cautionary period for a validation policy. The cautionary period specifies a minimum delay to be observed between a time T in the recent past, where the use of the private key or the public key is supposed to take place, and the time of production of revocation status information. 8.2. Components for a path discovery policy The PDP protocol SHALL be able to support certification path requirements and revocation requirements. It MAY support end-entity certificate specific requirements. These requirements are specified in sections 8.1.1, 8.1.2, and 8.1.3, respectively. 9. DPV versus DSV DPV performs the validation of a certificate against a policy, but does not necessarily provide all the information needed to prove to someone else that is not trusting the same DPV server that a digital signature from a signer was produced while the signer's certificate was valid. A Delegated Signature Validation (DSV) service could be specified to allow to prove later on to someone else, not trusting the same DSV server, that a digital signature was applied while the certificate was valid. Requirements for a Delegated Signature Validation (DSV) service that allows to fully delegate the validation of a digital signature to a DSV server might be addressed in a separate document at a future time. 10. Security considerations A client must trust a DPV server to provide the correct answer. However, this does not mean that all clients will trust the same servers. While a positive answer might be sufficient for one client, that positive answer will not necessarily convince another client. Other clients may trust their own servers, or they might perform certification path validation themselves. Clients operating under an organizational policy must ensure that each of the servers they trust is operating under that organizational policy. According to section 3.3 of [PKIX-1]: "An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked certificate's validity period". When the difference Pinkas, Housley [Page 11] Internet Draft DPV&DPD-REQ January 2002 between the end of the validity period of the end-entity certificate and the time of the event for which the validity is to be tested is smaller than the cautionary period, then the end-entity certificate must be considered as invalid, since it is not guaranteed to be able to get the revocation status information of that certificate. If certificates are not used close to the end of their validity period, then this situation will not happen. This means that new certificates should be issued and used before the end of the validity period of the current certificate and with a time interval greater than the cautionary period. 11. Acknowledgments These requirements have been refined after some valuable inputs from Ambarish Malpani and Paul Hoffman. 12. References [PKIX-1] Internet X.509 Public Key Infrastructure. Certificate and CRL Profile. RFC 2459 R. Housley, W. Ford, W. Polk, D. Solo. or its successor as soon as it can be referenced. [OCSP] X.509 Internet Public Key Infrastructure. Online Certificate Status Protocol - OCSP. RFC 2560 M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. [ES-F] Electronic Signature Formats for long term electronic signatures RFC 3126. D. Pinkas, J. Ross, N. Pope. September 2001. [ES-P] Electronic Signature Policies. RFC 3125. D. Pinkas, J. Ross, N. Pope. September 2001. [CMS] Cryptographic Message Syntax. RFC 2630. R. Housley June 1999. or its successor as soon as it can be referenced. [ESS] Enhanced Security Services for S/MIME. RFC 2634. P. Hoffman. RFC 2634, June 1999. Pinkas, Housley [Page 12] Internet Draft DPV&DPD-REQ January 2002 [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 1997 edition, use 1993 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1996.) [FTP] Internet X.509 Public Key Infrastructure. Operational Protocols: FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999. [HTTP] Internet X.509 Public Key Infrastructure. Operational Protocols: FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999. [LDAP] Internet X.509 Public Key Infrastructure Operational Protocols LDAPv2. RFC 2559. S. Boeyen, T. Howes, P. Richard. April 1999. 13. Authors' addresses Denis Pinkas Bull. 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE e-mail: Denis.Pinkas@bull.net Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA rhousley@rsasecurity.com Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Pinkas, Housley [Page 13] Internet Draft DPV&DPD-REQ January 2002 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. Pinkas, Housley [Page 14]