Internet Draft D. Pinkas draft-pinkas-pkix-lcvp-02.txt Bull SAS Expires in six months May, 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 May 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 revalidation 5 4.1. Initial validation 5 4.2. Revalidation 5 5. The LCVP protocol 6 5.1. General description 6 5.2. Detailed protocol 7 5.2.1. Request syntax 7 5.2.2. Response syntax 12 6. LCVP via HTTPS 12 7. Security considerations 12 8. IANA Considerations 13 9. References 13 9.1. Normative references 13 9.2. Informative references 14 10. Author’s address 14 11. Full copyright statement 14 Appendix A -- MIME Registrations 16 Appendix B (normative) -- ASN.1 Definitions 18 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 somebody 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 any parameter to a validation policy known by the server. Pinkas [Page 2] Internet Draft LCVP May 2007 2.1. Validation policies query For a validation policies request, the server MUST return the references, i.e. the OIDs, of the validation policies that are supported. 2.2. Certificate validation query 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. The validation is performed against a validation policy fully defined by an OID. When the validation 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 validation 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 revalidation. The support of revalidation is OPTIONAL. Revalidation allows to support the validation of electronic signatures already checked as valid. 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 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. Pinkas [Page 3] Internet Draft LCVP May 2007 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 May 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 revalidation The same validation protocol may be used to validate a certificate against a validation policy, either for: 1) an initial validation, or, 2) a revalidation, 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. Revalidation The support of revalidation is OPTIONAL for the server. It is useful in particular when a client wants to use that service to recheck an electronic signature that has been successfully validated in the past. 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 provide previously returned validation data that was valid at that date. Pinkas [Page 5] Internet Draft LCVP May 2007 5. The LCVP protocol 5.1. General description An LCVP request contains either a request to list the validation policies supported by the server, or a request to validate a certificate against one validation policy. In the former case, the request contains the following data: -- a protocol version. Each response includes the following data: -- a sequence of validation policy references. In the later case, the 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 revalidation, -- 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 reference of the validation policy that has been used, -- the validation time, -- the subject’s public key, -- the full subject name, i.e. a sequence of names, starting with the name of the subject, continuing with an ordered list of CA names and ending with the name of a trust anchor, -- the key usage extension field, if present, -- the extended key usage extension field, if present, -- optionally, the certificate, if not present in the request, -- optionally, validation data, -- optional extensions. Pinkas [Page 6] Internet Draft LCVP May 2007 5.2. Detailed protocol The ASN.1 syntax imports terms defined in [RFC3280] and in [RFC3126]. 5.2.1. Request syntax This section specifies the ASN.1 specification for a request. LCVPRequest ::= CHOICE { policyRequest [0] PolicyRequest, request [1] Request } 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 revalidation requestExtensions [0] Extensions OPTIONAL } version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } certToValidate is the certificate to validate. It is either the actual value of the certificate or an unambiguous reference to it. CertOrCertRef ::= CHOICE { certificate [0] OCTET STRING, 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 Pinkas [Page 7] Internet Draft LCVP May 2007 ValidationData is a set of certificates and revocation information that may be useful for the server to perform a validation operation. When a revalidation 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 revalidation operation. ValidationData ::= SEQUENCE { certificateValues [0] CertificateValues OPTIONAL, revocationValues [1] RevocationValues OPTIONAL } 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 revalidation. requestExtensions is a way to add other elements later on, if needed. If present, each extension in the sequence extends the request. This specification does not define any extensions; the facility is provided to allow future specifications to extendLCVP. The syntax for extensions is imported from [RFC3280]. The requestExtensions item, when present, MUST contain a sequence of extension items, and each of the extensions MUST contain extnID, critical, and extnValue items. The extnID item is an identifier for the extension. It contains the object identifier that names the extension. The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). By default, the extension is non-critical. An SCVP server MUST reject the query if it encounters a critical extension that it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The extnValue item is an octet string, which contains the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier. 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. Pinkas [Page 8] Internet Draft LCVP May 2007 LCVPResponse ::= CHOICE { policyResponse [0] PolicyResponse, certificateResponse [1] CertificateResponse } validationPolicyResponse is a response to a validation policies query. PolicyResponse ::= CHOICE { error ErrorStatus, valPolicyReferences 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), -- revalidation not supported validationDataMissing (8), -- validation data missing unrecognizedExtension (9) -- extension not recognized } The ErrorStatus values have the following meaning: 1 The request was malformed 2 This version of the protocol is not supported 3 An internal server error occurred 4 The server is too busy and cannot respond 5 The requested validation policy is unknown 6 The value of the certificate cannot be obtained 7 The server does not support revalidation 8 The validation is missing but necessary for revalidation 9 There is an unrecognized extension in the request Response ::= SEQUENCE { version Version DEFAULT v1, validationStatus CertStatus, valPolicyRef ValPolicyRef, validationTime GeneralizedTime, subjectPublicKeyInfo SubjectPublicKeyInfo, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, certificate OCTET STRING OPTIONAL, validationData [0] ValidationData OPTIONAL, responseExtensions [1] Extensions OPTIONAL } Pinkas [Page 9] Internet Draft LCVP May 2007 The various parameters from the Response are the following: version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } CertStatus ::= ENUMERATED { valid (0) , -- valid certificate invalid (1) , -- invalid certificate temporaryInvalid (2) , -- temporarily invalid certificate unknown (3) -- 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. 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. validationTime SHALL be the time for which the validation has been checked. 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. subjectPublicKeyInfo SHALL be the identifier of the algorithm and the value of the subject’s public key present in the certificate. fullSubjectName SHALL be a sequence of names, starting with the DN of the subject, if present, otherwise with the subject alternate name of the subject, continuing with an ordered list of DNs from the CAs, as found in the validated certification path, and ending with the DN of a trust anchor. Pinkas [Page 10] Internet Draft LCVP May 2007 For a given validation policy, this sequence of names uniquely identifies the subject, as long as the same issuer name is not used for different trust anchors. See section 7 for further explanations. FullSubjectName ::= SEQUENCE { leafName LeafName, cANames SEQUENCE OF Name } LeafName ::= CHOICE { subjectName [0] Name, subjectAltName [1] SubjectAltName } keyUsage SHALL be the value of the key usage extension field, if that extension is present in the certificate. extKeyUsage SHALL be the value of the extended key usage extension field, if that extension is present in the certificate. certificate SHALL be the full certificate. This field SHALL only be present, if the field certRef was used in the request. It allows the client to locally parse the certificate, if other fields from the certificate are needed. validationData is a set of certificates and revocation information that has been used by the server to perform the validation operation. It SHALL only be returned when the certificate is valid. responseExtensions is a way to add other elements later on, if needed. If present, the responseExtensions item contains a sequence of Extensions that extend the response. This specification does not define any extensions. The facility is provided to allow future specifications to extend LCVP. The syntax for Extensions is imported from [RFC3280]. The responseExtensions item, when present, contains a sequence of Extension items, each of which contains an extnID item, a critical item, and an extnValue item. The extnID item is an identifier for the extension. It contains the object identifier (OID) that names the extension. The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). An LCVP client MUST reject the response if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. Conforming clients MUST be able to determine if critical extensions are present in the responseExtensions item. The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier. Pinkas [Page 11] Internet Draft LCVP May 2007 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. A subject name, as specified in a certificate, is uniquely linked to an entity for a given CA, but not across CAs. Since the full subject name is a sequence of names starting with the name of the subject, continuing with CAs names and ending with the name of a trust anchor, it allows to make the difference in cases where different entities that obtained certificates from different CAs would have the same subject name. Issuers of validation policies should make sure that, for a given validation policy, there are not different trust anchors that bear the same name. Pinkas [Page 12] Internet Draft LCVP May 2007 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. 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/rfc2219.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 Pinkas [Page 13] Internet Draft LCVP May 2007 9.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 [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. Pinkas [Page 14] Internet Draft LCVP May 2007 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. 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 15] Internet Draft LCVP May 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 16] Internet Draft LCVP May 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 17] Internet Draft LCVP May 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, Name, SubjectPublicKeyInfo FROM PKIX1Explicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 18 } ExtKeyUsageSyntax, KeyUsage, SubjectAltName FROM PKIX1Implicit88 -- RFC 3280 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} 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-ExplicitSyntax97 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) eSignature-explicit97(29)} ; -- 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 revalidation requestExtensions [0] Extensions OPTIONAL } Pinkas [Page 18] Internet Draft LCVP May 2007 CertOrCertRef ::= CHOICE { certificate [0] OCTET STRING, 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 ::= CHOICE { error ErrorStatus, valPolicyReferences 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), -- revalidation not supported validationDataMissing (8), -- validation data missing unrecognizedExtension (8) -- extension not recognized } Response ::= SEQUENCE { version Version DEFAULT v1, validationStatus CertStatus, valPolicyRef ValPolicyRef, validationTime GeneralizedTime, subjectPublicKeyInfo SubjectPublicKeyInfo, fullSubjectName FullSubjectName, keyUsage KeyUsage OPTIONAL, extKeyUsage ExtKeyUsageSyntax OPTIONAL, certificate OCTET STRING OPTIONAL, validationData [0] ValidationData OPTIONAL, responseExtensions [1] Extensions OPTIONAL } Pinkas [Page 19] Internet Draft LCVP May 2007 CertStatus ::= ENUMERATED { valid (0) , -- valid certificate invalid (1) , -- invalid certificate temporaryInvalid (2) , -- temporarily invalid certificate unknown (3) -- validity unknown } FullSubjectName ::= SEQUENCE { leafName LeafName, cANames SEQUENCE OF Name } LeafName ::= CHOICE { subjectName [0] Name, subjectAltName [1] SubjectAltName } END Pinkas [Page 20]