Internet Draft Denis Pinkas, Integris draft-ietf-pkix-dpv&dpd-req-01.txt November 2001 Target Category: INFORMATIONAL Expires in six months Delegated Path Validation and Delegated Path Discovery Protocol Requirements (DPV&DPD-REQ) <draft-ietf-pkix-dpv-dpd-req-00.txt> 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. 1. Abstract This document specifies requirements for two main request/response pairs. The first one, called Delegated Path Validation (DPV), 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 second one, called Delegated Path Discovery (DPD), can be used to obtain from a DPD server all the information needed (e.g. leaf certificates, CA certificates, full CRLs, delta-CRLs, OCSP responses) to locally validate a certificate according to a set of rules, called a path discovery policy. It also defines the requirements for two optional request/response pairs, either for allowing to indicate to a validation server a validation policy, or to a path discovery server a path discovery policy; or giving the reference of a policy to get obtain details of an already defined policy. Pinkas [Page 1]
Internet Draft DPV&DPD-REQ November 2001 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. Rational and benefits These delegated processing provides two primary services: delegated signature validation, delegated path validation and delegated path discovery. Not all clients require both services in all scenarios. Some clients have requirements for offloaded path validation and have no need for data acquisition, while some other clients require only delegated path discovery to help them perform their own path validation. 3. Rational and benefits for DPV (Delegated Path Validation) DPV allows to perform a real time validation for a time T for any kind of certificate and any kind of security service. 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 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 verify the signature on the response, can be considerably less than the time required by the client to perform path discovery and validation. Even if a certification path were readily available to the client, the delay associated with processing the signatures for each certificate in the path might (under some circumstances such as very long paths or 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. Even clients that are able to do their own path validation may rely on a trusted server to do path validation if clients are in an environment where centralized management of validation policies is needed for some applications. Pinkas [Page 2]
Internet Draft DPV&DPD-REQ November 2001 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). Servers can also take directions from the client about how path validation SHALL be done (such as which validation policy SHALL be used). In all these cases, the client will delegate path validation to a fully-trusted server. 4. Rational 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 need not even be trusted, because the client will ultimately perform 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, HTTP, and so on. Since these data items are digitally signed, the client need not trust the server to return the "right" data any more than the client would have to 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 directories 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 paths, separate from making the queries to acquire path validation data. In these cases, the client will delegate path discovery to an untrusted server. 5. Validation policy and path discovery policy Policies MAY be a priori known by the server or MAY be specified by the client to the server. Because validation software is controlled by many parameters which, if incorrectly set, may result in insecure behavior, it is often important to be able rely on pre-defined policies that are already known by the servers, where system security administrators can carefully manage them. Both services (delegated path validation and delegated path discovery) can be potentially used by the enterprise for enforcing various aspects of centralized policy. Pinkas [Page 3]
Internet Draft DPV&DPD-REQ November 2001 Alternatively, clients MAY also define policies. However, such policy definition may be quite complex and only simple forms of policies SHOULD be defined in this way, otherwise testing all the possible variations would lead to non-interoperable implementations or would delay the time to make sure that two implementations are really interoperable. Since policy definitions can be quite long and complex, all the parameters SHOULD not be passed with each individual request but a reference to either an a priori known policy (e.g. an OID) or an already pre-defined policy (e.g. a reference returned by the server) SHOULD be used. Some forms of path discovery policy can be simple enough, e.g. a set of self-signed certificates. In that case it MAY be acceptable to pass all the parameters from the path discovery policy with each individual request. Policies allows to support security services, such as an entity authentication service, a data origin authentication service, an integrity service or a confidentiality service or some combination of these services. This can be for immediate use, e.g. to use a certificate in order to support a confidentiality service by using a certificate that contains the key exchange bit set or the key agreement bit set or the digital signature bit set when an ephemeral-ephemeral Diffie-Hellman key exchange is being used. This can be for a time T in the past, e.g. to use a certificate in order to verify data protected by a data origin authentication service in combination with an integrity service, using a certificate that contains the digital signature bit set. 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 in any case, even when an OCSP service is being used. So querying the revocation status of a certificate for a time T never proves that the private key corresponding to that certificate was not revoked at that time T. Ideally, a cautionary period SHOULD be defined in the policy, in order to allow some time for 1) the end-entity to realize that a private key has been or could possibly be compromised, and for 2) the revocation Authority to make available the revocation status information, e.g. by providing an OCSP service, CRLs or delta-CRLs in combination with full CRLs. Pinkas [Page 4]
Internet Draft DPV&DPD-REQ November 2001 When the key included in the certificate is for immediate use, it is not possible to apply a cautionary period and thus it should be realized that some risk is taken, since the corresponding private key might indeed be compromised at the time of use. When the key included in the certificate is for the verification of some usage in the past, then it is possible to apply a cautionary period. In such a case, the policy SHOULD indicate a minimum delay to be observed between the time T in the past, i.e. when the use of the private key took was supposed to take place, and the time of the current verification. 5.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 value (root key) for a given CA name, valid during some time interval. The use of a self-signed certificate allows to specify at the same time: the public key to be used, the CA name and the validity period of the root key. Additional constrains for each trust anchor MAY be defined, such as a set of Certification Policy constraints and a set of naming constraints. In some cases, these constrains MAY also be included in self-signed certificates. Additional conditions that apply to the certificates from the chain, (e.g. user-initial-policy-set, initial-policy-mapping-inhibit, initial- explicit-policy, or initial-any-policy-inhibit) or to the end- certificate (e.g. a name form that must be present in the end- certificate, like an e-mail address either in the rfc822 subject alt name or in the emailAddress attribute in the subject name) MAY also be specified in the validation policy. In order to succeed, one valid path (i.e. none of the certificates from the path must be revoked) must be found between a leaf certificate and a trust anchor and all constraints that apply to the certificate chain must be verified. 5.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 MAY either be a reference to a validation policy or contain only some major elements from a validation policy, e.g. the root keys to be used to construct the path. Pinkas [Page 5]
Internet Draft DPV&DPD-REQ November 2001 Since the client MUST be "PKI aware", it SHALL be able to locally apply additional constraints on the certification paths that MAY be returned. Thus "crude" (i.e. simpler) criteria can be defined and used in that case. The client needs to be able to limit the number of paths to be returned so that the server does not loose time to find out more paths than requested. While making that limitation, the returned paths MAY not be appropriate to the client when it then locally applies additional tests. Instead of asking one by one the paths (which would mandate to manage state information at the server), the client will specify with every request the maximum number of paths that MAY 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. When that number is reached, and when more paths are needed, that number can be increased. Previously found paths will likely be returned, but the client can easily discard them. This avoids to mandate the management of state information at the server, but does not prevent a server to maintain a cache of previous responses. 6. Delegated Path Validation Protocol Requirements The Delegated Path Validation (DPV) protocol allows to validate one or more certificate for the current time and according to a single set of rules, called a validation policy. The validation policy SHALL be known by the DPV server. When it isn't, it MAY defined using an additional protocol (see section 10). In this way clients only need to be aware of the reference of the validation policy to be used by a given application. The certificate to be validated MAY either be directly provided in the request or alternatively an unambiguous reference MAY be provided, e.g. the CA name and certificate serial number together with the hash of the certificate like ESSCertID as defined in RFC 2634. In order to help the server, the client MAY provide to the validation server "useful certificates", as well as "useful revocation information" that MAY be used by the validation server (e.g. of OCSP requests, CRLs or delta-CRLs). As an example, an S/MIME message may include such information and the client can simply provide that information. In order to obtain the revocation status information of any certificate from the certification path, the DPV server MAY use, in accordance with the validation policy, different sources of revocation information, e.g. a combination of OCSP requests, CRLs or delta-CRLs. If the client does not specify in its request the validation policy to be used, the server MUST indicate in the response the one that has been used. In such a case, the client MUST verify that the one that has been selected is appropriate for its use. Pinkas [Page 6]
Internet Draft DPV&DPD-REQ November 2001 The status of the response MAY be one out of three types: 1) the certificate is valid according to the validation policy, 2) the certificate is invalid according to the validation policy, 3) the server cannot determine the validity of the certificate (e.g. a path cannot be constructed). In order to be able to be confident that the validation of the certificate has correctly be done, the client will only require an authenticated response. 7. Delegated Path Discovery Protocol Requirements The Delegated Path Discovery (DPD) protocol allows to use a single protocol towards a single server to collect at one time all the data elements that might be collected using different protocols (e.g. LDAP, DAP, OCSP) or by querying multiple servers. Then this information can locally be used to validate one or more certificates for the current time and according to a single path discovery policy. The path discovery policy MAY be known a priori by the DPD server. When it isn't, it MAY defined using an additional protocol (see section 8). None, one or several certification paths MAY be returned. Each path consists of a sequence of certificates, starting after the certificate to validate and ending with one self-signed certificate. In addition, the revocation information associated with each path MAY also be returned. The paths that are returned MAY need to match some additional local controls done by the client, e.g. verifying some certificate extensions. The client MAY indicate the maximum number of certification paths that MUST be returned (provided that they may be found). If the number is not specified, that number is defaulted to one. 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. The server may use a local cache to avoid to search again the same elements, but is not mandated to maintain any local state information from any previous request. The goal is to avoid to maintain state information on previous requests: if this is done, it optimizes the response time. Path discovery is performed according to the path discovery policy. Pinkas [Page 7]
Internet Draft DPV&DPD-REQ November 2001 The status of the response MAY be one out of three types: 1) one or more certification paths could be found according to the path discovery policy, with partial or full revocation information present. 2) one or more certification paths could be found according to the path discovery policy, with no revocation information present. 3) no certification path could be found according to the path validation 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. In order to be able to be confident that the values returned are coming from the DPV server, the client MAY require an authenticated response. 8. Components for a validation policy A validation policy is build from four components: 1. Certificate chain requirements, 2. Revocation requirements, 3. End-certificate specific requirements, 4. optionally, a cautionary period requirements. 8.1. Certificate chain requirements The certificate requirements identifies a sequence of trust anchors used to start (or end) certification path processing and initial conditions for certification path validation as defined in [PKIX-1]. 8.2. Revocation 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-certificate (i.e. the certificate for which a path is required) and on checks required on CA certificates. It can then specified if : - full CRLs (or full Authority revocation lists) have to be collected, - OCSP responses, using RFC 2560, have to be collected, - delta-CRLs and the relevant associated full CRLs (or full Authority revocation lists) are to be collected. None, one or more of the above conditions MAY apply. Pinkas [Page 8]
Internet Draft DPV&DPD-REQ November 2001 8.3. End-certificate specific requirements There MAY be requirements that apply only to the end-certificate (i.e. the certificate that is the object of the query). For example, the end-certificate must contain specific extensions with specific types or values (it does not matter whether they are critical or non critical). As an example, the end-certificate must contain a name form like an e-mail address either in the rfc822 subject alt name or in the emailAddress attribute in the subject name. 8.4. Cautionary period requirements When applicable, the cautionary period will define a minimum delay to be observed between a time T in the past, where the use of the private key or the public key is supposed to take took place, and the time of the current validation. 9. Components for a path discovery policy A path discovery must include certificate chain requirements, and MAY include revocation requirements, and end-certificate specific requirements. 10. Policy definition protocol (PDP) requirements The support of these request/response pairs is OPTIONAL. These request/response pairs allow either to define a policy, i.e. a validation policy and/or a path discovery policy, and to receive back a reference for that policy or to provide a reference to a previously defined policy and to receive back the definition of that policy. Policies locally predefined at the server may be more precise than policies defined using this optional protocol. Thus this OPTIONAL protocol exchanges will never have all the flexibility to describe any kind of policy. So in practice it will be restricted to define relatively simple policies. Usually, these protocol exchanges will be used by managers to register the policies to be used, e.g. within an organization for various applications. As a result of the registration, managers will receive a reference of the policy. These requests SHALL be able to be authenticated so that only authorized clients can register policies (and thus avoid denial of service attacks by registering useless policies). The reference of the policy MAY be specific to the request or MAY be a reference that has already been provided as the result of a previous request with an identical definition. Pinkas [Page 9]
Internet Draft DPV&DPD-REQ November 2001 It is up to server to decide how long a temporary defined policy will be kept. In case the policy is locally defined at the server, when querying a policy reference, it would be interesting to consider to provide back information about the purpose of the policy in a natural language. When using DPV, there are two possibilities: a) the client is a little bit PKI-aware, in the sense that it is only able to parse the end-certificate to check some properties in that certificate, and delegates the validation of the rest of the path to the server. It appears easier to remotely define such "partial policies" since the tests on the end-certificate are left to the client. b) the client is fully 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- certificate are made by the server and may be quite complex. When using DPD, simpler validation policies may be defined since anyway clients need to be fully PKI-aware to do other tests. 11. DPV versus DSV DPV does not return information allowing to prove to someone else, not trusting the same DPV server, that a digital signature from a signer was produced while the signer's certificate was valid. Another document [DSV-REQ] specifies requirements for a Delegated Signature Validation (DSV) service that allows to fully delegate the validation of a digital signature to a DSV (Delegated Signature Validation) server. In particular, DSV allows to prove later on to someone else, not trusting the same DSV server, that the signature was applied while the certificate was valid. 12. Security considerations A client may trust a DPV server to provide the right answer. However, this does not mean that all clients will trust the same servers. Thus while a positive answer MAY be sufficient for a client, that positive answer will not necessarily be able to convince another client. That other clients will trust their own servers and will query them. Queries relative to the current time can easily be done to another server. 13. Acknowledgments These requirements have been refined after some valuable inputs from Ambarish Malpani, Russ Housley and Paul Hoffman. Pinkas [Page 10]
Internet Draft DPV&DPD-REQ November 2001 14. References [DSV-REQ] Delegated Signature Validation Protocol Requirements <draft-ietf-pkix-dsv-req-00.txt> [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. [TSP] Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161 C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. [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. [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.) Pinkas [Page 11]
Internet Draft DPV&DPD-REQ November 2001 14. Authors' address Denis Pinkas Integris, Bull. 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE e-mail: Denis.Pinkas@bull.net 15. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Pinkas [Page 12]
