Internet Draft D. Pinkas draft-pinkas-pkix-lcvp-00.txt Bull SAS Expires in six months April, 2007 Category: Experimental Lightweight Certificate Validation Protocol (LCVP) Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2007). 1. Abstract LCVP allows a client to delegate certificate path validation to a trusted server. The path validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a set of rules called a validation policy. It allows simplification of client implementations and only uses of a set of predefined validation policies. This document defines a protocol that can be used to: (1) validate one certificate according to one validation policy, (2) query the validation policies supported by an LCVP server. Key words used in this document 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 LCVP April 2007 Table of Contents 1. Abstract 1 2. Lightweight Certificate Validation Protocol Overview 2 2.1. Validation policy query 3 2.2. Certificate validation query 3 3. Validation policy 5 4. Initial validation and re-validation 5 4.1. Initial validation 5 4.2. Re-validation 5 5. The LCVP protocol 6 5.1. General description 6 5.2. Detailed protocol 6 5.2.1. Request syntax 6 5.2.2. Response syntax 8 6. LCVP via HTTPS 10 7. Security considerations 10 8. IANA Considerations 10 9. References 10 9.1. Normative references 10 9.2. Informative references 11 10. Author’s address 11 11. Full copyright statement 11 Appendix A -- MIME Registrations 14 Appendix B (normative) -- ASN.1 Definitions 16 2. Lightweight Certificate Validation Protocol Overview This document supports Delegated Certificate Validation (DCV). Since it only supports a subset of the mandatory requirements described in [RFC3379] for DPV, it does not conform to RFC 3379. This document is not either a profile of [SCVP]. The server is trusted by the client. The protocol can only be used in the case where a client does not need to demonstrate to someone else that it got a given response: the security of the communication is achieved using session oriented security, i.e. HTTPS. A compliant implementation MUST support the validation of a certificate at the present time. It MAY optionally support the validation of a certificate in the past. However in the later case, the client MUST provide all the necessary information, i.e. the server will not fetch any extra information. The major differences with [SCVP] are the following: - the protocol only supports DPV, i.e. it includes no provisions to support Delegated Path Discovery (DPD); - requests and responses are not signed, since they are protected by TLS, where clients are not authenticated; - validation is only for one certificate at a time; - there is no specific parameter in the request to add another parameter to a validation policy known by the server. Pinkas [Page 2] Internet Draft LCVP April 2007 2.1. Validation policy query For a validation policy request, the server MUST return the references, i.e. the OIDs, of the validation policies that are supported. 2.2. Certificate validation query The validation protocol always refers to a validation policy fully defined either by an OID. The LCVP protocol allows to validate, according to a validation policy, one certificate for the current time, and optionally for a time T in the past. The certificate to be validated MUST either be directly provided in the request or be unambiguously referenced in the request. The LCVP server MUST get the certificate to be validated. When the certificate is not provided in the request, the server MUST obtain the certificate and then verify that the certificate is indeed the one being unambiguous referenced by the client. The LCVP server MUST include the certificate in its response. When the time is the current time, the server MUST do its best efforts to perform the validation (validation may not be possible if the required data may not be collected). When the time is a time in the past, the server MAY support it. If it does, then the client MUST provide some data captured at the time of a previous validation. Validation at a time in the past is called re-validation. The support of re-validation is OPTIONAL. Re-validation allows to support the validation of electronic signatures. See [RFC3126]. In order to obtain the revocation status information of any certificate from the certification path, the LCVP server MAY use, as appropriate and accordingly to the validation policy, a combination of OCSP responses and CRLs. If the LCVP server does not support the client requested validation policy, then the LCVP server MUST return an error. If the LCVP request does not specify a validation policy, the server response MUST indicate the validation policy that has been used. The certificates for which the validation is requested MUST either be directly provided in the request or be unambiguously referenced. Pinkas [Page 3] Internet Draft LCVP April 2007 The LCVP server MUST have the certificate for which the validation is requested. When the certificate is not provided in the request, the server MUST obtain the certificate and then verify that the certificate is indeed the one being unambiguously referenced by the client. The LCVP client MAY optionally provide to the validation server, useful certificates, as well as useful revocation information. Revocation information MAY include OCSP responses and/or CRLs. This information is called input validation data. As an example, an S/MIME message might include such information, and the client can simply copy and paste that information into the LCVP request. Unless, the request cannot be understood due to an error, the LCVP response indicates one of the following status alternatives: 1) the certificate is valid according to the validation policy, 2) the certificate is invalid according to the validation policy, 3) the certificate is temporary invalid according to the validation policy, 4) the validity of the certificate is unknown according to the validation policy, When the certificate is valid according to the validation policy, then the date of the freshness of the revocation status of the certificate MUST be returned. See section 7 for further explanations. In addition, upon request, the certification path and the information used to check that each certificate from the certification path was not revoked MAY be returned. This information is called output validation data. Output validation data may consist of a certification path, revocation status information from authorized CRL issuers or authorized OCSP responders, revocation status information from CRL issuers or OCSP responders trusted under the validation policy. When the certificate is not valid according to the validation policy, then the reason MUST also be indicated. Invalidity reasons include: a) the LCVP server successfully constructed a certification path, but it was not valid according to the validation algorithm in [RFC3280]. b) the LCVP server successfully constructed a certification path, cannot determine the validity of the certificate because certificate revocation information as specified in the validation policy is missing. c) the certificate is temporary invalid. If another request could be made later on, the certificate could possibly be determined as valid. This condition may occur while a certificate is suspended. Pinkas [Page 4] Internet Draft LCVP April 2007 3. Validation policy A validation policy is a set of rules against which the validation of the certificate SHALL be performed. 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. A trust anchor is defined as a public key for a given CA name and valid during some time interval, a set of Certification Policy constraints and a set of naming constraints. 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 MAY be included in the self-signed certificate. Additional conditions that apply to the certificates from the chain, MAY also be specified in the validation policy. 4. Initial validation and re-validation The same validation protocol may be used to validate a certificate against a validation policy, either for: 1) an initial validation, or, 2) a re-validation, performed later on, using information captured by an LCVP server and returned to the client at the time of an initial validation. 4.1. Initial validation An initial validation SHALL be performed according to a validation policy. If the client does not specify in its request the validation policy to be used, the server will indicate in the response the one that has been used. In such a case, the client SHOULD verify that the one selected is appropriate for its use. 4.2. Re-validation The support of re-validation is OPTIONAL for the server. When a client wants to invoke that service, it MUST specify the date in the past at which the validation should be performed. The requester MUST also provide previously returned validation data that was valid at that date. Pinkas [Page 5] Internet Draft LCVP April 2007 5. The LCVP protocol 5.1. General description A request contains the following data: -- a protocol version, -- either the identification of the certificate to validate or the certificate itself, -- optionally, the reference of the validation policy to be used, -- optionally, useful validation data, -- whether validation data should be returned, -- optionally ,the validation time, if different from the current time, -- optionally, previous validation data for re-validation, -- optional extensions, Upon receipt of a request, an LCVP Responder determines if: 1. the message is well formed; 2. the responder is configured to provide the requested service; and 3. the request contains the information needed by the responder. If anyone of the prior conditions is not met, the LCVP responder produces an error message; otherwise, it returns a response, as requested. Each response includes the following data: -- a protocol version, -- a validation status, -- the certificate, -- the reference of the validation policy that has been used, -- optionally, validation data -- the validation time, -- optional extensions, 5.2. Detailed protocol The ASN.1 syntax imports terms defined in [RFC3280] and in [RFC3126]. ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. 5.2.1. Request syntax This section specifies the ASN.1 specification for a request. LCVPRequest ::= CHOICE { policyRequest [0] PolicyRequest, request [1] Request } Pinkas [Page 6] Internet Draft LCVP April 2007 PolicyRequest ::= SEQUENCE { version Version DEFAULT v1 } version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { version Version DEFAULT v1, certToValidate CertOrCertRef, valPolicyRef ValPolicyRef OPTIONAL, validationData ValidationData OPTIONAL, returnValidationData BOOLEAN DEFAULT FALSE, validationTime GeneralizedTime OPTIONAL, -- only present for re-validation requestExtensions [1] Extensions OPTIONAL } version allows to identify the version of the protocol. certToValidate is the certificate to validate. It is either the actual value of the certificate or an unambiguous reference of that certificate. CertOrCertRef ::= CHOICE { certificate [0] Certificate, certRef [1] ESSCertIDv2 } ESSCertIDv2 is defined in [ESSCertIDv2]. valPolicyRef is a reference to the validation policy to be used. If the field is missing, the server SHALL use a default validation policy. ValPolicyRef ::= OBJECT IDENTIFIER ValidationData is a set of certificates and revocation information that may be useful for the server to perform a validation operation. When a re-validation operation is requested (i.e. the validationTime element is present) then it is the only set of certificates and revocation information that must be used by the server to perform the re-validation operation. ValidationData ::= SEQUENCE { certificateValues [0] CertificateValues OPTIONAL, revocationValues [1] RevocationValues OPTIONAL } Pinkas [Page 7] Internet Draft LCVP April 2007 CertificateValues and RevocationValues are defined in [RFC3126]. returnValidationData indicates whether validation data SHOULD be returned. By default, no validation data is returned. validationTime is the time for which the validation should be performed for a time in the past. If that field is missing, then the current time is assumed. This field is only present for re-validation. requestExtensions is a way to allow additional elements to be added later on, if needed. 5.2.2. Response syntax This section specifies the ASN.1 specification for a response. The response may either be a response to a query for listing the validation policies known to the server or to a certificate validation query. LCVPResponse ::= CHOICE { policyResponse [0] PolicyResponse, certificateResponse [1] CertificateResponse } validationPolicyResponse is a response to a validation policies query. PolicyResponse ::= SEQUENCE OF ValPolicyRef certificateResponse is a response to certificate validation query. CertificateResponse ::= CHOICE { error ErrorStatus, response Response } ErrorStatus ::= ENUMERATED { malformedRequest (1), -- malformed request unsupportedVersion (2), -- version not supported internalError (3), -- internal error tryLater (4), -- try again later unknownPolicy (5), -- policy unknown certificateUnknown (6), -- certificate unknown revalidationNotSupported (7), -- re-validation not supported unrecognizedExtension (8) -- extension not recognized } Response ::= SEQUENCE { version Version DEFAULT v1, validationStatus CertStatus, validatedCert Certificate, valPolicyRef ValPolicyRef, validationData ValidationData OPTIONAL, validationTime GeneralizedTime, Pinkas [Page 8] Internet Draft LCVP April 2007 responseExtensions Extensions OPTIONAL } The various parameters from the Response are the following: version allows to identify the version of the protocol. validationStatus indicates the status of the certificate. CertStatus ::= ENUMERATED { valid (1), -- valid certificate invalid (2), -- invalid certificate temporaryInvalid (3), -- certificate temporary invalid unknown (4) -- validity unknown } When the response indicates "valid", this means that the certificate is valid according to the validation policy. When the response indicates "invalid", this means that the certificate is definitively invalid according to the validation policy (e.g. one of the certificates of the path is revoked). When the response indicates "temporaryInvalid", this means that the certificate is temporary invalid according to the validation policy, because the revocation status of one of the certificates cannot be obtained or because one of the certificates is on hold at the time of validation. When the response indicates "unknown", this means that information is missing to build a path between the certificate and a trusted anchor. validatedCert is the certificate that has been validated. valPolicyRef is the validation policy that has been used. It MUST be a copy of the field present in the request, if that field was present. If the field was not present, it MUST be the reference of the validation policy that has been used to perform the validation. The caller SHOULD make sure that this field matches the requirements of its application. validationData is a set of certificates and revocation information that has been used by the server to perform the validation operation. It is only returned when the certificate is valid. validationTime is the time in the past for which the validation has been performed. If that field was present in the request, then it SHALL be a copy of the field present in the request. If that field was missing in the request, then it SHALL correspond to the date the thisUpdate field from the CRL relative to the certificate, or to the thisUpdate field from an OCSP response relative to the certificate. See section 7 for further explanations. Pinkas [Page 9] Internet Draft LCVP April 2007 requestExtensions is a way to allow additional elements to be added later on, if needed. 6. LCVP via HTTPS ASN.1-encoded messages are wrapped with by MIME objects. Two MIME objects are specified as follows. Content-Type: application/lcvp-request <> Content-Type: application/lcvp-response <> These MIME objects can be sent and received using common HTTP processing engines over WWW links and provides a simple browser- server transport for LCVP messages. Upon receiving a valid request, the server MUST respond with either a valid response with content type application/lcvp-response or with an HTTP error. 7. Security considerations An LCVP client must trust an LCVP server to provide the correct answer. However, this does not mean that all LCVP clients will trust the same LCVP servers. While a positive answer might be sufficient for one LCVP client, that same positive answer will not necessarily convince another LCVP client. When no policy reference is present in the LCVP request, the LCVP client ought to verify that the policy selected by the LCVP server is appropriate. When performing a validation for the present time, the LCVP server is required to include a validationTime in the request which corresponds to the date of the thisUpdate field from the CRL relative to the certificate, or to the thisUpdate field from an OCSP response relative to the certificate. This information is useful when verifying a non repudiation certificate used in the context of an electronic signature. It allows to take care of the grace period, which may be defined in a signature policy. See [RFC3126]. In that case, the returned validationTime needs to be compared to the date included in the time- stamp token computed over the digital signature. The time interval between these two dates must be greater than the grace period. 8. IANA Considerations This document includes two MIME type registrations in Appendix A. No further action by IANA is necessary for this document or any anticipated updates. Pinkas [Page 10] Internet Draft LCVP April 2007 9. References Normative and informative references are provided. 9.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt [RFC3279] Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 3279. W. Polk, Housley, L. Bassham. April 2002. http://www.ietf.org/rfc/rfc3279.txt [RFC3280] Internet X.509 Public Key Infrastructure. Certificate and CRL Profile. RFC 3280. R. Housley, W. Ford, W. Polk, D. Solo. April 2002. http://www.ietf.org/rfc/rfc3280.txt [OCSP] X.509 Internet Public Key Infrastructure. Online Certificate Status Protocol. OCSP. RFC 2560. M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 1999. http://www.ietf.org/rfc/rfc2560.txt [RFC3126] Electronic Signature Formats for long term electronic signatures RFC 3126. D. Pinkas, J. Ross, N. Pope. September 2001. http://www.ietf.org/rfc/rfc3126.txt [ESSCertIDv2] ESS Update: Adding CertID Algorithm Agility. J. Schaad. To be published in 2007. http://www.ietf.org/internet-drafts/draft-ietf-smime- escertid-04.txt 8.2. Informative references [RFC3379] Delegated Path Validation and Delegated Path Discovery Protocol Requirements. RFC 3379. D. Pinkas, R. Housley. September 2002. http://www.ietf.org/rfc/rfc3379.txt Pinkas [Page 11] Internet Draft LCVP April 2007 [SCVP] Server-based Certificate Validation Protocol (SCVP) T. Freeman, R. Housley, A. Malpani, D. Cooper, T. Polk To be published in 2007. http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-31.txt 10. Author’s address Denis Pinkas Bull SAS Rue Jean Jaures 78340 LES Clayes-sous-Bois FRANCE e-mail: Denis.Pinkas@bull.net 11. Full copyright statement Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Pinkas [Page 12] Internet Draft LCVP April 2007 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pinkas [Page 13] Internet Draft LCVP April 2007 Appendix A -- MIME Registrations Two MIME type registrations are provided in this appendix. A.1 application/lcvp-request To: ietf-types@iana.org Subject: Registration of MIME media type application/lcvp-request MIME media type name: application MIME subtype name: lcvp-request Required parameters: format Optional parameters: None Encoding considerations: binary Security considerations: Carries a request for information. This request should be protected using HTTPS. Interoperability considerations: None Published specification: IETF Lightweight Certificate Validation Protocol (LCVP) Applications that use this media type: LCVP clients Additional information: Magic number(s): None File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Denis Pinkas < Denis.Pinkas@bull.net> Intended usage: COMMON Author/Change controller: Denis Pinkas < Denis.Pinkas@bull.net> Pinkas [Page 14] Internet Draft LCVP April 2007 A.2 application/lcvp-response To: ietf-types@iana.org Subject: Registration of MIME media type application/lcvp-response MIME media type name: application MIME subtype name: lcvp-response Required parameters: format Optional parameters: None Encoding considerations: binary Security considerations: Carries a response. This response should be protected using HTTPS. Interoperability considerations: None Published specification: IETF Lightweight Certificate Validation Protocol (LCVP) Applications that use this media type: LCVP servers Additional information: Magic number(s): None File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Denis Pinkas < Denis.Pinkas@bull.net> Intended usage: COMMON Author/Change controller: Denis Pinkas < Denis.Pinkas@bull.net> Pinkas [Page 15] Internet Draft LCVP April 2007 Appendix B (normative) -- ASN.1 Definitions LCVP { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) XX } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS Certificate, Extensions, FROM PKIX1Explicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 18 } ESSCertIDv2, FROM ExtendedSecurityServices-2006 -- ESS Update: Adding CertID Algorithm Agility { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } CertificateValues, RevocationValues, FROM ETS-ElectronicSignatureFormats-97Syntax -- Electronic Signature Formats for long term electronic signatures { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6} ; -- LCVPRequest LCVPRequest ::= CHOICE { policyRequest [0] PolicyRequest, request [1] Request } PolicyRequest ::= SEQUENCE { version Version DEFAULT v1 } Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { version Version DEFAULT v1, certToValidate CertOrCertRef, valPolicyRef ValPolicyRef OPTIONAL, validationData ValidationData OPTIONAL, returnValidationData BOOLEAN DEFAULT FALSE, validationTime GeneralizedTime OPTIONAL, -- only present for re-validation requestExtensions [1] Extensions OPTIONAL } Pinkas [Page 16] Internet Draft LCVP April 2007 CertOrCertRef ::= CHOICE { certificate [0] Certificate, certRef [1] ESSCertIDv2 } ValPolicyRef ::= OBJECT IDENTIFIER ValidationData ::= SEQUENCE { certificateValues [0] CertificateValues OPTIONAL, revocationValues [1] RevocationValues OPTIONAL } -- LCVPResponse LCVPResponse ::= CHOICE { policyResponse [0] PolicyResponse, certificateResponse [1] CertificateResponse } PolicyResponse ::= SEQUENCE OF ValPolicyRef CertificateResponse ::= CHOICE { error ErrorStatus, response Response } ErrorStatus ::= ENUMERATED { malformedRequest (1), -- malformed request unsupportedVersion (2), -- version not supported internalError (3), -- internal error tryLater (4), -- try again later unknownPolicy (5), -- policy unknown certificateUnknown (6), -- certificate unknown revalidationNotSupported (7), -- re-validation not supported unrecognizedExtension (8) -- extension not recognized } Response ::= SEQUENCE { version Version DEFAULT v1, validationStatus CertStatus, validatedCert Certificate, valPolicyRef ValPolicyRef, validationData ValidationData OPTIONAL, validationTime GeneralizedTime, responseExtensions Extensions OPTIONAL } Pinkas [Page 17] Internet Draft LCVP April 2007 CertStatus ::= ENUMERATED { valid (1), -- valid certificate invalid (2), -- invalid certificate temporaryInvalid (3), -- certificate temporary invalid unknown (4) -- validity unknown } END Pinkas [Page 18]