Internet Draft Denis Pinkas, Integris draft-ietf-pkix-dsv-req-00.txt November 2001 Target Category: INFORMATIONAL Expires in six months Delegated Signature Validation Protocol Requirements (DSV-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. 1. Abstract This document specifies requirements to fully delegate the validation of a digital signature to a DSV (Delegated Signature Validation) server. The validation is performed using a set of rules, called a signature policy. It also defines the requirements for two optional request/response pairs, either for allowing to indicate to a signature validation server a signature policy, or giving the reference of a signature policy to obtain the details of an already defined signature policy. 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]. Pinkas [Page 1] Internet Draft DSV-REQ November 2001 2. Rational and benefits Offloading signature validation to a server may be required by a client that lacks the processing, and/or communication capabilities to perform digital signature validation by himself. In constrained execution environments such as telephones and PDAs, memory and processing limitations may preclude implementation of complete, PKIX- compliant signature validation. In applications where minimum latency is critical, delegating validation to a trusted server can offer significant advantages. The time required by the server for the processing can be considerably less than the time required by the client to perform the same thing. Even if a signature validation capabilities 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 signature validation is that it allows validation against signature policies defined by the management in a consistent fashion across an enterprise. Even clients able to do their own signature validation may rely on a trusted server to do signature validation if clients are in an environment where centralized management of signature policies is needed for some applications. When a client uses this service, it inherently trusts the server as much as it would its own signature validation software (if it contained such software). The protocol may be used in three instances: 1) When there is no need to prove later on to someone else that the digital signature was indeed valid, a positive authenticated answer from the DSV is sufficient. 2) When there is a need to prove to someone else trusting the same DSV server that the digital signature was indeed valid, a positive signed answer from the DSV is sufficient. 3) When there is a need to prove later on to someone else, not trusting the same DSV server that the signature was indeed valid, additional data MUST be returned by the DSV server so that this information can be tested again by a different DSV server or a local software. 4. Signature policy Policies may be a priori known by the server or may be specified by the client to the server. Pinkas [Page 2] Internet Draft DSV-REQ November 2001 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. 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. A signature policy is a set of rules against which the validation of a digital signature is performed. A signature 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 such a trust anchor: 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 signature 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. Before a digital signature may be declared as valid, the verifier has to be sure that the legitimate holder of the private key was really the only one in possession of key at the time of signing and that the certificate was valid at the time of signing. Since the time of signing, when indicated by the signer, cannot be trusted, an upper limit is used by using either time-stamping or time-marking. Pinkas [Page 3] Internet Draft DSV-REQ November 2001 A time-stamp allows to prove that a datum existed before a particular time. When the hash included in the time-stamp token is the hash of a digital signature, this allows to prove that this digital signature was generated before the date contained in the time-stamp token. A time-mark is an audit record kept in a secure audit trail which attaches a date to data. When that data is a digital signature value, this proves that the digital signature was generated before the date from the time-mark. The signature policy has to define whether time-stamping or time marking SHALL be used. In order to prove that the signature was applied while the certificate was valid, a time-stamp or a time-mark MUST be obtained: 1) before the end of the validity period of the signer's certificate. This is necessary since CAs are not mandated to process revocation status information beyond the end of the validity period of the certificates they have issued, and 2) before a possible revocation, should the signer's private key be revoked. The sooner they can be obtained, the better. In addition, it is important to notice that some delay will be necessary so that legitimate signers that have had their private key compromised have some time to report the compromise, and that CAs can then make available the corresponding revocation status information. Such a delay is specified as a cautionary period. The cautionary period allows some time: 1) for the end-entity to realize that the private key has been or could possibly be compromised, and 2) for the revocation Authority to make available that information, e.g. by providing an OCSP service, CRLs or delta-CRLs in addition to full CRLs. The signature policy MUST indicate the minimum delay to be observed between the date from the timeûmark or from the time-stamp, and the time of the current verification. A verifier will need to wait until the end of the cautionary period before knowing that the signature is indeed valid. Note: If the cautionary period is set to zero in the signature policy, then it must be realized that risks are taken by the verifier. However, such risks may be acceptable for low level transactions. Pinkas [Page 4] Internet Draft DSV-REQ November 2001 5. Delegated Signature Validation Protocol Requirements The Delegated Signature Validation (DSV) protocol allows to validate one digital signature for a time T and according to a single set of rules, called a signature policy. The signature policy SHALL be known by the DSV server. When it isn't, it MAY defined using an additional protocol exchange(see section 7). In this way clients only need to be aware of the reference of the signature policy to be used by a given application. The digital signature to be validated MUST be provided in the request. In addition, the certificate to be used to validate the signature MUST either be directly provided in the request or alternatively an unambiguous reference MUST 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. When time-stamping is required by the signature policy, the DSV server MUST provide the time-stamp token, unless it is already provided by the client. When time-marking is required by the signature policy, the client MUST provide the date of the time-mark so that the server can compare it to the date of the current request. The time T may be close to the present time or a time in the past. When it is a time close to the present time, the server MUST do its best efforts to perform the signature validation (signature validation in the past may not be possible if the required data may not be collected). The support of revalidation, i.e. validation in the past using some data previously obtained at the time of an initial signature verification, which does not require the server to keep validation data from the past is optional. Revalidation is useful when there is a dispute and when the signature validation originally performed by a given signature validation server is not trusted by the other party. Revalidation, can be done either by the same DSV server or by another DSV server. Presenting the data captured at the time of a previous validation is REQUIRED to get that service. The support of signature validation in the past without presenting some validation data previously obtained (and which thus requires the server to keep validation data from the past) is optional. Pinkas [Page 5] Internet Draft DSV-REQ November 2001 In order to obtain the revocation status information of any certificate from the certification path, the DSV 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 signature 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. The status of the response MAY be one out of four types: 1) the signature is valid according to the signature policy, 2) the signature is definitively invalid according to the signature policy, 3) the signature is not yet valid at this time according to the signature policy. If another request could made later on, the digital signature could possibly be determined as valid. 4) the server cannot determine the validity of the signature (e.g. a path cannot be constructed). In most instances, in order to be able to be confident that signature validation has correctly be done, the client will only require an authenticated response. However, there are cases when the client needs to prove to another party that he got a response from the right responder. When the response from the DSV server cannot be trusted by the disputing parties, in particular by a judge when trying to solve the dispute, the validation data that has been effectively be used during the validation process MUST be reused, so that the same validation data can be re-checked again either locally or by another validation server. If that validation data was directly part of the signed response, then the signed positive response could be rather long, if needed to be stored. For that reason, since the validation data still needs to be integrity protected, the protection SHOULD be obtained using a hash of the validation data included in the signed response instead of protecting directly the validation data itself by the signature. A structure of validation data has been defined in [ES-F]. In order to be able to directly copy and paste that validation data, the same data elements as defined in [ES-F] SHOULD be supported. [ES-F] mandates to keep the references of the path with the signature, while the actual values of the path (which are for more voluminous) MAY be stored elsewhere. This means that in this case, two hashes for the validation data SHOULD be supported: one for the path references and one for the path values. Pinkas [Page 6] Internet Draft DSV-REQ November 2001 Provisions SHOULD also exist in the protocol so that other validation data structures can be supported in the future. [ES-F] also allows to protect the path in case any key from the path is compromised after the validation time. This is provided by using one or more time-stamps tokens. The signature policy MUST indicate whether or not time-stamping is required and, when required, will indicate the TSA(s) to be used. When doing a re-validation, the client MAY need to send back the validation data that it originally received: either the references only or both the references and the actual values of the path. 6. Components for a signature policy A signature policy is build from five components: 1. Certificate chain requirements, 2. Revocation requirements, 3. End-certificate specific requirements, 4. Time-Stamping requirements, or 5. Time-Marking requirements. 6.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]. 6.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. 6.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). Pinkas [Page 7] Internet Draft DSV-REQ November 2001 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. Another more difficult example, is to make sure that the certificate is a Qualified Certificate, as meant by the European Directive on Electronic Signatures. There are two ways to check that property: 1) the OID of the Certification Policy contains a specific value, 2) a QC-Statement extension is present and contains a specific value. While defining the end-certificate requirements, these examples should be taken into consideration. 6.4. Time-Stamping requirements Either Time-Stamping requirements or Time-Marking requirements SHALL be specified. The Time-Stamping Requirements identify both the number of time-stamps to be used over the signer's digital signature as well as the names or the types of TSAs to be used. Additional Time-Stamping requirements MAY be specified over the references of the paths in order to protect against a compromission of a private key of any Authority (CAs, CRL Issuer or OCSP responder) from the path. There will be some delay between the time that a signature is created and the time the signer's digital signature is time-stamped. However, the longer this elapsed period the greater the risk of the signature being invalidated due to compromise or deliberate revocation of its private signing key by the signer. A cautionary period, part of these requirements, SHALL define the minimum delay to be observed between the time from the time-stamp and the time T of the validation. 6.5. Time-Marking requirements Either Time-Marking requirements or Time-Stamping requirements SHALL be specified. There will be some delay between the time that a signature is created and the time the signer's digital signature is time-marked. However, the longer this elapsed period the greater the risk of the signature being invalidated due to compromise or deliberate revocation of its private signing key by the signer. A cautionary period, part of these requirements, SHALL define the minimum delay to be observed between the time from the time-mark and the time T of the validation. Pinkas [Page 8] Internet Draft DSV-REQ November 2001 7. Policy definition protocol (PDP)requirements The support of these request/response pairs is optional. These request/response pairs allow to define a signature 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. 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. Should that functionality be supported, then it would be beneficial to enable such information to be defined while remotely defining the technical parts of a validation policy. See [ES-P] for more details on this topic. When using DSV, 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. Pinkas [Page 9] Internet Draft DSV-REQ November 2001 8. DSV versus DPV Another document [DPV&DPD-REQ] specifies requirements for Delegated Path Validation (DPV). DPV allows to perform a real time validation for a time T of any kind of certificate, in particular certificates used for digital signature purposes, but does not return information allowing to prove to someone else, not trusting the DPV server, that a digital signature from a signer was generated while the signer's certificate was valid. 9. Security considerations A client MAY trust a DSV 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. 10. Acknowledgments These requirements have been defined using information contained in RFC 3126 [ES-F] and in RFC 3125 [ES-P]. The content of these Informational RFCs is technically equivalent to ETSI TS 101 733 V.1.2.2. ETSI Technical Standards are under the ETSI Copyright (C). 11. References [DPV&DPD-REQ] Delegated Path Validation and Delegated Path Discovery Protocol Requirements [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. Pinkas [Page 10] Internet Draft DSV-REQ November 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.) 12. Authors' address Denis Pinkas Integris, Bull. 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE e-mail: Denis.Pinkas@bull.net 13. 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. Pinkas [Page 11] Internet Draft DSV-REQ November 2001 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]