Internet Draft Denis Pinkas, Integris draft-ietf-pkix-dsv-dpv-dpd-req-00.txt October 2001 Target Category: INFORMATIONAL Expires in six months Delegated Signature Validation Delegated Path Validation and Delegated Path Discovery Protocol Requirements 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 three main request/response pairs. The first one, called Delegated Signature Validation (DSV), can be used to fully delegate signature validation processing to an DSV server, according to a set of rules, called a signature policy. The second 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 third 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 signature validation server a signature policy, 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 the details of an already defined policy. Pinkas [Page 1] Internet Draft DSV-DPV&DPD October 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 three primary services: delegated signature validation, delegated path validation and delegated path discovery. Not all clients require all services in all scenarios. Some clients have requirements for offloaded signature validation since signature validation rules may be quite complex. 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. 2.1. Rational and benefits for DSV (Delegated Signature Validation) Offloading signature validation to a server may be required by a client that lacks the processing, and/or communication capabilities to perform 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). When there is no need to prove later on to someone else that the signature was indeed valid, the positive or negative answer from the DSV is sufficient. Pinkas [Page 2] Internet Draft DSV-DPV&DPD October 2001 However, there are cases where clients will need to prove later on to someone not trusting the same DSV server that the signature was indeed valid. So they need to get back from the DSV server the validation data that has been used by their server so that this information can be tested again by a different DSV server or a local software. In these cases, it is fundamental to be able to prove that the signature was indeed generated while the signer's certificate was valid, otherwise, should the private key be compromised, faked signatures could be recognized later on as valid. The end of validity of a certificate is determined either by the end of the validity period of the certificate or by the revocation date of the certificate, should the certificate be revoked. Since it is not possible to know for sure when the signature was generated, it is necessary to be able to prove that the signature was generated before a given time and then to compare that given time with either the date of the end of the validity of the certificate or with the date of revocation of the certificate, whichever is the sooner. The proof that the signature was generated before a given time may be obtained in two ways: 1) by using a time-stamp token applied to the signature. This proves that the signature was generated before the time/date included in the time-stamp token, 2) by using a time-mark applied to the signature. A time-mark is an audit record kept in a secure audit trail from a trusted third party which attaches a date to a signature value. This also proves that the signature was generated before the time/date from the time-mark. 2.2. Rational and benefits for DPV (Delegated Path Validation) 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 certificate 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. Pinkas [Page 3] Internet Draft DSV-DPV&DPD October 2001 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. 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 should 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. 2.3. 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. 3. Signature policy, 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 Pinkas [Page 4] Internet Draft DSV-DPV&DPD October 2001 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. Alternatively, clients may also define policies. However, such policy definition may be quite complex and only simple forms of policies can be defined in this way. 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. 3.1. Signature Policy 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. However, if signature validation is made in the context of a non- repudiation service (instead of a data origin authentication service) the above conditions are not sufficient. The signature policy has to define whether time-stamping or time marking shall be used as well as Pinkas [Page 5] Internet Draft DSV-DPV&DPD October 2001 the delay that may exist between the date included in the time-stamp or the time-mark and the delay until a possible revocation will be advertised. This delay may be necessary so that legitimate signers that have had their private key compromised have some time to report the compromise, and then that the revocation status information may be made available. When time-stamping is mandated by the signature policy, the policy must indicate the names or the characteristics of the TSA(s) to be used. 3.2. 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. 3.3. 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. 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. Pinkas [Page 6] Internet Draft DSV-DPV&DPD October 2001 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. 4. 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 (see section 10). 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 copy and paste 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 either to the date for the end of the validity of the certificate or to the date of revocation of the certificate, whichever is the sooner. That date must be returned in the response. 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 Pinkas [Page 7] Internet Draft DSV-DPV&DPD October 2001 best efforts to perform the signature validation (signature validation in the past may not be possible if the required data may not be collected). When it is a time in the past, the signature policy must include provisions to support non repudiation by using either time-stamping or time-marking. 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. 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 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. 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. A path has been able to be constructed, however one or more revocation status information are missing or one or more certificates are currently suspended. If another request could made later on, all the certificates could possibly be determined as not revoked. In some cases, it may be indicated when another request should be attempted. 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. Pinkas [Page 8] Internet Draft DSV-DPV&DPD October 2001 However, there are cases when the client needs to prove to another party that he got a response from the right responder. In that case a non repudiation service has to be supported. Both the data origin authentication service and the non-repudiation service may be obtained using signed responses. Finally, there are cases when that response cannot be trusted by the disputing parties, in particular by a judge when trying to solve the dispute. In that case 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. Validation data needed for non-repudiation 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. 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. 5. 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 8). In this way clients only need to be aware of the reference of the validation policy to be used by a given application. Pinkas [Page 9] Internet Draft DSV-DPV&DPD October 2001 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 copy and paste 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 selected is appropriate for its use. 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. 6. 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. Pinkas [Page 10] Internet Draft DSV-DPV&DPD October 2001 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. 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 will only require an authenticated response. 7. 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 7.1. Certificate chain requirements The certificate requirements identifies a sequence of trust anchors used to start (or end) certificate path processing and the initial conditions for certificate path validation as defined in [PKIX-1]. Pinkas [Page 11] Internet Draft DSV-DPV&DPD October 2001 7.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. 7.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. 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. 8. Components for a signature policy A signature policy is build from the same three elements of a validation policy and may include additional Time-Stamping requirements to support a non-repudiation service. 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. Pinkas [Page 12] Internet Draft DSV-DPV&DPD October 2001 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 this request/response pair (and its dual request/response pair) is optional. It allows to define signature policies, validation policies and/or path discovery policies. Policies locally predefined at the server may be more precise than policies defined using this optional protocol. Thus this optional protocol 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, this protocol 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). These request/response pairs allow either to define a 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. 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 or 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 Pinkas [Page 13] Internet Draft DSV-DPV&DPD October 2001 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. Security considerations A client may trust a DSV or a DCV 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. 12. Acknowledgments These requirements have been refined after some valuable inputs from Ambarish Malpani, Russ Housley and Paul Hoffman. 13. 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. [TSP] Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161 C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Pinkas [Page 14] Internet Draft DSV-DPV&DPD October 2001 [ES-F] Electronic Signature Formats for long term electronic signatures D. Pinkas, J. Ross, N. Pope. RFC 3126. [ES-P] Electronic Signature Policies D. Pinkas, J. Ross, N. Pope. RFC 3125. [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.) 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. Pinkas [Page 15] Internet Draft DSV-DPV&DPD October 2001 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 16]