Internet Draft Denis Pinkas, Bull draft-ietf-pkix-cvp-02.txt January, 2003 Expires in six months Certificate Validation Protocol 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 defines a protocol called Certificate Validation Protocol (CVP) that can be used to: (1) query the validation or discovery policies supported by a CVP server, (2) validate one or more public key certificates according to a single validation policy, or (3) obtain one or more certification paths for one or more certificates according to a single discovery policy. 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]. 2. Certificate Validation Protocol Overview This protocol specification is in accordance with the protocol requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) defined in [RFC3379]. A server may support either DPV or DPD, or both DPV and DPD. Pinkas [Page 1] Internet Draft CVP January 2003 Validation or discovery policy definitions may be long and complex, and some policies may allow for the setting of a few parameters (such as root self-signed certificates). The protocol allows the client to use pre-defined simple policies which include a few variable parameters; however, it is expected that most clients will simply reference a validation policy for a given application or accept the CVP serverĘs default validation policy. 2.1. Validation or discovery policy query. For a validation or discovery policy request, the server MUST return the OIDs of the policies that are supported and MAY also return the details of some pre-defined simple policies. This protocol MUST be supported both by DPV and DPD servers. 2.2. Delegated Certificate Validation Certificate Validation SHALL always be performed against a set of rules, called a validation policy. If the CVP server does not support the client requested validation policy, then the CVP server MUST return an error. If the CVP request does not specify a validation policy, the server response MUST indicate the validation policy that was used. The certificates for which the validation is requested MUST either be directly provided in the request or unambiguously referenced. The CVP 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 unambiguous referenced by the client. The CVP client MAY optionally provide to the validation server, associated with each certificate to be validated, useful certificates, as well as useful revocation information. Revocation information MAY include OCSP responses, CRLs, and delta CRLs. The client can request that the server determine the certificate validity at a time other than the current time. 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 CVP server MUST do its best efforts to perform the validation (validation may not be possible if the required data may not be collected). The support of validation in the past, using some data previously captured at the time of initial verification is optional. When supported, the server uses data that is provided by the requester which may be the validation data that has been previously returned when making an initial validation. This is called a re-validation. The CVP server MUST obtain revocation status information for the validation time in the client request. Pinkas [Page 2] Internet Draft CVP January 2003 If the revocation status information for the requested validation time is unavailable, then the CVP server MUST return a status indicating that the certificate is invalid. Additional information about the reason for invalidity is also provided. In order to obtain the revocation status information of any certificate from the certification path, the CVP server might use, in accordance with the validation policy, different sources of revocation information. For example, a combination of OCSP responses (see [OCSP]), CRLs, and delta CRLs could be used. Alternatively, a response from another CVP server could be used. Unless, the request cannot be understood due to an error, the CVP response indicates one of the following status alternatives: 1) the certificate is valid according to the validation policy, 2) the certificate is not valid according to the validation policy, 3) the validity of the certificate is unknown according to 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 CVP server successfully constructed a certification path, but it was not valid according to the validation algorithm in [RFC3280]. b) the CVP 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 not valid at this time. If another request could be made later on, the certificate could possibly be determined as valid. This condition may occur before a certificate validity period has begun or while a certificate is suspended. In order to be able to prove to a third party (that trusts the same CVP server) that a check has correctly been done, the client needs to present a CVP response. In order to keep the response as short as possible, only the important components from the request are copied in the response. In order to be able to prove to a third party (that does not trust the same CVP server ) that a check has correctly been done, the client will require to get all the data that has been collected during the validation so that the test can be redone again using the same information, in a subsequent validation (called re-validation). In such a case the server will need to return that information, called validation data. Pinkas [Page 3] Internet Draft CVP January 2003 Validation data may (not necessarily exclusively) 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, time-stamp tokens (see [TSP]) from TSAs responders trusted under the validation policy, or a CVP response from a CVP server that is trusted under the validation policy. When the certificate is valid, the server MUST, upon request, include the validation data in the response. However, the server MAY omit that information when the certificate is invalid or when it cannot determine the validity. 2.3. Delegated Path Discovery Delegated Path Discovery SHALL always be performed against a set of rules, called a discovery policy. If the CVP server does not support the client requested discovery policy, then the CVP server MUST return an error. If the CVP request does not specify a discovery policy, the server response MUST indicate the discovery policy that was used. The certificate for which certification paths are requested MUST either be directly provided in the request or unambiguously referenced. The CVP server MUST have the certificate for which certification paths are 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 unambiguous referenced by the client. The CVP server MUST include either the certificate or an unambiguous reference to the certificate (in case of a CA key compromise) in the CVP response. The CVP client MAY optionally provide to the validation server, associated with each certificate to be validated, useful certificates, as well as useful revocation information. Revocation information MAY include OCSP responses, CRLs, and delta CRLs. Unless, the request cannot be understood due to an error, the CVP response indicates one of the following status alternatives: 1) one or more certification paths was found according to the discovery policy, with all of the requested revocation information present. 2) one or more certification paths was found according to the discovery policy, with a subset of the requested revocation information present. 3) one or more certification paths was found according to the path discovery policy, with none of the requested revocation information present. Pinkas [Page 4] Internet Draft CVP January 2003 4) no certification path was found according to the path discovery policy. 2.4. General The following applies both for DPV and DPD requests. The certificate to be validated or for which certification paths are requested MUST either be directly provided in the request or unambiguously referenced, such as the CA distinguished name, the certificate serial number, a hash value computed over the ASN.1 DER encoded tbsCertificate field from the certificate, and the signature (value and algorithm identifier) of the certificate. The CVP client MAY optionally provide to the validation server, associated with each certificate, useful certificates, as well as useful revocation information. Revocation information includes OCSP responses, CRLs, and delta CRLs. As an example, an S/MIME message might include such information, and the client can simply copy that information into the CVP request. The CVP server MUST have the certificate to be validated or for which certification paths are 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 unambiguous referenced by the client. The CVP server MUST include in its response either the certificate or an unambiguous reference to the certificate (in case of a CA key compromise) in the CVP response. Server DPV responses and server DPD responses MAY be signed upon request from the client. When a response is signed, then an unambiguous reference of the certificate from the CVP server MUST be included as one of the signed parameters. In this way, the CVP serverĘs certificate authenticates the response. Client requests MAY be signed. The CVP server MAY require client authentication, therefore, the CVP server MAY refuse the service if the request is not authenticated. When a CVP request is authenticated, the client MAY include a client identifier in the request for the CVP server to copy into the response. Mechanisms for matching this identifier with the authenticated identity depends on local CVP server conditions and/or the validation policy. The CVP server MAY choose to blindly copy the identifier, omit the identifier, or return an error response. When confidentiality is needed, this is not achieved at the level of this protocol and this may be achieved with a lower-layer security protocol, by taking into consideration the properties of the transport protocol. Pinkas [Page 5] Internet Draft CVP January 2003 In order to prevent against replay attacks, if the client has a local clock well synchronized with UTC, then the time of the response can be used to detect replay attacks; alternatively the client may generate a nonce that MUST then be copied by the server in its response. Upon request, a text field provided by the client into the CVP response will be copied in the response. As an example, this field may relate to the nature or reason for the CVP query. 3. Policies 3.1. 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 rather than in the self-signed certificate itself. 3.2. Discovery policy A discovery policy is a set of rules against which the discovery of a certification path SHALL be performed. A path discovery policy MAY either be a reference to a discovery policy or contain only some major elements from a discovery policy, such as the trust anchors. Since the DPD client SHALL be "PKI aware", it can locally apply additional selection criteria to the certification paths returned by the server. Thus, simpler policies can be defined and used for path discovery. A discovery policy includes certification path requirements, revocation requirements, and end-entity certificate specific requirements. 4. Initial validation and re-validation The same validation protocol may be used to validate a certificate against a validation policy either for: 1) initial validation or for, 2) re-validation, using information captured by a CVP server and returned to the client at the time of initial validation. Pinkas [Page 6] Internet Draft CVP January 2003 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 Re-validation SHALL be performed according to a validation policy. The requester MUST specify the certificate to be validated and MUST provide previous returned references of the certification path, or the previous returned values of the certification path. 5. Description the CVP protocol A DVP/DPD request may be optionally signed and contains the following data: -- a protocol version, -- an optional nonce to prevent replays, -- either the identification of the certificate(s) to validate or the certificate(s) themselves, and for each certificate: -- optionally, useful certificates, -- optionally, useful revocation information, -- optionally, previous returned references for re-validation, -- optionally, previous returned values for re-validation, -- optionally, the validation or discovery policy to be used, -- whether it is a DPV or a DPD request, -- for a DPV request: -- whether the server response shall not be signed, -- whether the values of the path should be returned, -- whether the references of the path should be returned, -- whether the references of the path should be time-stamped -- for a DPD request: -- whether the server response shall be signed, -- optionally, a context information provided by the server for getting additional path information, -- whether the path and all the revocation status should be returned, -- whether both the path and only the certificate revocation status should be returned, -- whether both the path and the CA revocation status should be returned, -- whether only the path should be returned, -- optionally, identification(s) of the requester, to be copied in the response, when the request is authenticated, -- optionally, data from the requester to be copied in the response -- optional extensions, Pinkas [Page 7] Internet Draft CVP January 2003 Upon receipt of a request, a CVP 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 any one of the prior conditions is not met, the CVP responder produces an unsigned error message; otherwise, it returns a definitive signed or unsigned response, as requested. A CVP response contains a major status, followed by a response in case of "success" and optionally with the validation data. The validation data that has been collected during the validation may be rather long since it may consist of a certification path and its associated revocation status information for each element from the path. If the validation data was directly part of the signed response, then the signed response could also be rather long, if needed to be stored simply as a proof for a third party trusting the same CVP server. For that reason, only the hash of the validation data is part of the signed response, and the actual values of the validation data are not part of the signed response. Each response includes the following data: -- protocol version, -- an optional nonce to detect replays, -- a major status, -- a minor status -- the identification of the certificate, -- the reference of the validation policy that has been used, -- the kind of service that has been requested, -- a serial number for that response, -- the response time, -- the validation time, -- a hash over all parameters from the request (to detect changes), -- identification) of the server, when the response is signed, -- an optional unambiguous reference of the CVP server certificate. -- optional identification(s) of the requester, -- optional data from the requester that is copied in the response, -- optional context information, -- a field for future extensions. External to the signed part of the response, the response may include the validation data. 5.2. Detailed Protocol The ASN.1 syntax imports terms defined in [RFC3280] and in [RFC3126]. For signature calculation, the data that may be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. Pinkas [Page 8] Internet Draft CVP January 2003 ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. The terms imported from elsewhere are: Extensions, Name, AlgorithmIdentifier, CRLReason, RevocationValues, CompleteCertificateRefs, CompleteRevocationRefs. 5.2.1. Request This section specifies the ASN.1 specification for a request. The CVP request MAY be signed. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). CVPRequest ::= SEQUENCE { mbsRequest MBSRequest, -- May Be Signed Request optionalSignature [0] EXPLICIT CvpSignature OPTIONAL } CvpPSignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } signatureAlgorithm contains the identifier for the cryptographic algorithm used to sign the structure. It may be used initially as an hint to make sure that the algorithm is supported, but its value MUST be equal to the value of signatureAlgo field from the Request or the PolicyRequest which is itself protected by the signature. signatureValue contains a digital signature computed upon the ASN.1 DER encoded mbsRequest. The ASN.1 DER encoded mbsRequest is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signatureValue field. The details of this process are specified for each of algorithms listed in [RFC3279]. certs is an optional sequence of certificates that may be used to build the certification path in order to verify the signature. MBSRequest ::= CHOICE { policyRequest [0] PolicyRequest, request [1] Request } PolicyRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, signatureAlgo AlgorithmIdentifier, signatory CertOrCertRef OPTIONAL, validationPoliciesMaxNumber INTEGER, discoveryPoliciesMaxNumber INTEGER } Pinkas [Page 9] Internet Draft CVP January 2003 version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } signatureAlgo is an optional field that MUST be used when the request is signed. It contains the identifier for the cryptographic algorithm used by the client to sign his request. This algorithm MUST be used to verify the signature. signatory is an optional field that MUST be used when the request is signed. It contains the certificate or the certificate reference of the signer. Since it is protected by the signature, there can be no ambiguity about the signatory. validationPoliciesMaxNumber specifies the maximum number of validation policies to be returned. discoveryPoliciesMaxNumber specifies the maximum number of discovery policies to be returned. Request ::= SEQUENCE { version [0] Version DEFAULT v1, signatureAlgo AlgorithmIdentifier OPTIONAL, signatory CertOrCertRef OPTIONAL, nonce OCTET STRING OPTIONAL, certsQueries SEQUENCE OF CertsQuery valOrDiscoPolicy ValOrDiscoPolicy OPTIONAL, checks Checks, requesterName [1] EXPLICIT GeneralName OPTIONAL, requesterData [2] EXPLICIT CHARACTER STRING OPTIONAL, requestExtensions [3] EXPLICIT Extensions OPTIONAL } version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } signatureAlgo is an optional field that MUST be used when the request is signed. It contains the identifier for the cryptographic algorithm used by the client to sign his request. This algorithm MUST be used to verify the signature. signatory is an optional field that MUST be used when the request is signed. It contains the certificate or the certificate reference of the signer. Since it is protected by the signature, there can be no ambiguity about the signatory. nonce is a unique number (e.g. a large pseudo random number) generated by the client that may be used to detect replay. certQueries may be composed of a single or of multiple certQuery. Pinkas [Page 10] Internet Draft CVP January 2003 CertQuery ::= SEQUENCE { certToValidate CertOrCertRef, usefulCerts [0] CertificateValues OPTIONAL, usefulRevoc [1] RevocationValues OPTIONAL, -- defined in [RFC3126] previousValidationData [2] ValidationData OPTIONAL, CertQueryExtensions [3] EXPLICIT Extensions OPTIONAL } certToValidate is the certificate to validate. It is either the actual value of the certificate or an unambiguous reference of that certificate. usefulCerts is a set of certificates that may be useful for the server to build a path. usefulRevoc is a set of revocation information, that may be useful for the server to make sure that no element from the path is revoked. previousValidationData contains the validation data from a previous response. This information may be necessary for the CVP server to be able to perform a re-validation for a time T in the past. valOrDiscoPolicy is a reference to either the validation policy or the discovery policy to be used. If the field is missing, the server SHALL indicate which policy has been used. It MUST be the unambiguous reference of a policy without or with optional parameters (see section 6). checks is defined as Checks. Checks ::= CHOICE { dpvCheck [0] DpvCheck, dpdChecks [1] DpdChecks } There is a choice between a DPV request and a DPD request. DpvCheck ::= SEQUENCE { signed BOOLEAN DEFAULT TRUE validationTime GeneralizedTime OPTIONAL, -- for a time in the past returnValues [1] BOOLEAN Default FALSE, returnRefs [2] BOOLEAN Default FALSE, timeStampRefs [3] BOOLEAN Default FALSE } For a DPV request the following parameters can be specified: By default, all DPV responses are signed. However, the client may request unsigned responses if the communication is protected using other means (e.g. TLS). Pinkas [Page 11] Internet Draft CVP January 2003 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. returnValues is an indicator to ask the server to return the values of the path (both the values of the certificates used and the values of the revocation information used) or the value of a CVP response trusted under the validation policy. returnRefs is an indicator to ask the server to return the references of the path (both the references of the certificates used and the references of the revocation information used). For validation for a time in the past, this avoids path construction and saves storage space when multiple validations are using the same path values (certificates and CRLs). timeStampRefs is an indicator to ask the server to return a time- stamped version of the returnRefs. The number of time-stamps and the names of the TSAs are indicated in the validation policy. This provides a protection in case a key from a CA, CRL Issuer, OCSP responder or CVP server would be compromised after the date of issue of the time-stamps. DpdChecks ::= SEQUENCE { signed BOOLEAN DEFAULT FALSE, serverContextInfo OCTET STRING OPTIONAL, infoToBeReturned InfoToBeReturned } By default, all DPD responses are unsigned. However, the client may request signed responses if the communication is not protected (e.g. using TLS) by using the signed parameter. serverContextInfo, if present, contains context from a previous request-response transaction with the same server. It allows the server to return one by one certification paths for the same certificate to the client. For example, if a server constructs a particular certification path for a certificate, but the client finds it unacceptable, the client can then send the same query back to the server with the serverContextInfo from the first response, and the server will be able to provide a different certification path (if one can be found). Contents of the serverContextInfo are opaque to the client. That is, the client only knows that it needs to return the value provided by the server with the subsequent request to get a different certification path. Note that the subsequent query needs be essentially identical to the previous query (except that the nonce, if present, must change). Pinkas [Page 12] Internet Draft CVP January 2003 The client MUST NOT change any items other than: - nonce - serverContextInfo - the optional client's signature on the request infoToBeReturned specifies the four different kinds of information to be returned. InfoToBeReturned ::= ENUMERATED { pathWithRevocInfo (0), pathWithEndEntityRevocInfoOnly (1), pathWithCaRevocInfoOnly (2), pathWithoutRevocInfo (3) } pathWithRevocInfo indicates that the path and all the revocation status should be returned. pathWithEndEntityRevocInfoOnly indicates that both the path and only the certificate revocation status should be returned. pathWithCaRevocInfoOnly indicates that both the path and the CA revocation status should be returned. pathWithoutRevocInfo indicates that only the path should be returned. requesterName is an optional field that contains an identifier of the requester. It is used when the request is signed. In that case if the identifier of the requester matches one of the identifiers included in the signer's certificate, then it MAY be copied by the CVP server in its response. requesterData is a string of characters that SHOULD be blindly copied by the CVP server in the signed response. signatory MUST contain, when the request is signed, the certificate or the certificate reference from the requester. It is used to authenticate the requester. requestExtensions is a way to allow additional elements to be added later on, if needed. CertOrCertRef ::= CHOICE { certificate [1] Certificate, certRef [2] CertRef } CertOrCertRef may specify the certificate itself or an unambiguous reference of the certificate. CertRef ::= CHOICE { eSSCertId [0] ESSCertID, certIdWithSignature [1] CertIdWithSignature } Pinkas [Page 13] Internet Draft CVP January 2003 ESSCertID is defined in RFC2634. CertIdWithSignature ::= SEQUENCE { issuerSerial IssuerSerial, tbsCertificateHash BIT STRING, certSignature CertSignature } IssuerSerial is defined in RFC2634 section 5.4.1. tbsCertificateHash contains a hash value computed over the ASN.1 DER encoded tbsCertificate field from the certificate using the hash function identified in the signature algorithm from the signature. certSignature contains the signature fields from the certificate. CertSignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } ValOrDiscoPolicy ::= SEQUENCE { valOrDiscoPolicyId OBJECT IDENTIFIER, parameters ANY DEFINED BY valPolicyId OPTIONAL } ValOrDiscoPolicy is an OID followed by optional parameters either a simple policy or referenced policy. CertificateValues ::= SEQUENCE OF Certificate UsefulCerts is a set of certificates, some of them may be useful to build the path. ValidationData ::= CHOICE { pathInfo PathInfo, tbsResponse TBSResponse } ValidationData may either be: - information on the path (certificates, CRLs or OCSP responses), - or a single CVP signed response, from a CVP server trusted under the validation policy. PathInfo ::= SEQUENCE { certificateValues [0] CertificateValues OPTIONAL, revocationValues [1] RevocationValues OPTIONAL, certPathRefs [2] CertPathRefs OPTIONAL -- only used for DPV } RevocationValues is defined in [RFC3126]. Pinkas [Page 14] Internet Draft CVP January 2003 CertPathRefs ::= SEQUENCE { pathRefrences ValidatedPathRefs, timeStamps SEQUENCE OF TimeStampToken OPTIONAL } ValidatedPathRefs ::= SEQUENCE { certificateRefs CompleteCertificateRefs, -- defined in [RFC3126] revocationRefs CompleteRevocationRefs -- defined in [RFC3126] } PathInfo contains a sequence of certificates, from the certificate to validate up to a trust anchor, exclusive of the self-signed certificate of the trust anchor, if any; a sequence of revocation status information; and optionally the references of the path that may be time-stamped. The hash of the time-stamp token(s) SHALL be computed on the DER encoding of ValidatedPathRefs. 5.2.2. Response Syntax This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). An CVP response at a minimum consists of a cVPStatus field indicating the processing status of the prior request. If the value of cVPStatus is one of the error conditions, tbsResponse and optionalSignature are not set. CvpResponse ::= SEQUENCE { mbsResponse MBSResponse, -- May Be Signed Response optionaldpDSignature [0] EXPLICIT DpdSignature OPTIONAL -- only used for DPD responses } The full response MAY be signed, only when it is a DPD response. Otherwise, for DPV, individual signatures may be placed on for each individual DPV response data (i.e. individualResponseData). DpdSignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } signatureAlgorithm contains the identifier for the cryptographic algorithm used to sign the structure. It may be used initially as an hint to make sure that the algorithm is supported, but its value MUST be equal to the value of signatureAlgo field from the MBSResponse which is itself protected by the signature. Pinkas [Page 15] Internet Draft CVP January 2003 signatureValue contains a digital signature computed upon the ASN.1 DER encoded mbsResponse. The ASN.1 DER encoded mbsResponse is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signatureValue field. The details of this process are specified for each of algorithms listed in [RFC3279]. certs is an optional sequence of certificates that may be used to build the certification path in order to verify the signature. MBSResponse ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, signatureAlgo AlgorithmIdentifier OPTIONAL, -- only when the DPD response is signed signatory CertOrCertRef OPTIONAL, -- only when the DPD response is signed cVPStatus CVPResponseStatus, response Response } version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } signatureAlgo is an optional field that MUST be used when the whole DPD response is signed. It contains the identifier for the cryptographic algorithm used by the server to sign his response. This algorithm MUST be used to verify the signature. signatory is an optional field that MUST be used when the whole DPD response is signed. It contains the certificate or a certificate reference from the signer. Since it is protected by the signature, there can be no ambiguity about the identity of the server. cVPStatus status indicates if an error was encountered. CVPResponseStatus ::= ENUMERATED { successful (0), -- Request was understood malformedRequest (1), -- malformed request unsupportedVersion (2), -- version not supported internalError (3), -- internal error in issuer tryLater (4), -- try again later sigRequired (5), -- must sign the request badSignature (6), -- signature verification failed unauthorized (7), -- request unauthorized unknownPolicy (8), -- policy unknown incorrectSignature (9), -- incorrect signature unrecognizedExtension (10), -- extension not recognized relayingLoop (20) -- a loop has been detected } response may either be a response to a query for listing the policies known to the server or to a DPV or DPD query. Response ::= CHOICE { policyResponse [0] PolicyResponse, responses [1] SEQUENCE OF IndividualResponse } Pinkas [Page 16] Internet Draft CVP January 2003 policyResponse is a response to a policy query. Separate lists are provided for validation policies and discovery policies. PolicyResponse ::= SEQUENCE { valPolices [0] ValOrDiscoPolicies OPTIONAL, discoveryPolicies [1] ValOrDiscoPolicies OPTIONAL } ValOrDiscoPolicies ::= SEQUENCE OF ValOrDiscoPolicy If one of the simple policies, as defined in the present document, is supported, then the server MUST provide the additional parameters which are associated with it. IndividualResponse ::= SEQUENCE { individualResponseData IndividualResponseData, optionalSignature [0] EXPLICIT IndividalSignature OPTIONAL, validationData ValidationData OPTIONAL } The individualResponseData when it is a DPV response is usually signed, unless the client requires the signature to be absent. Each IndividualResponse may be individually signed so the client can keep individual signed DPV responses in order to demonstrate that the validation was effectively done by the DPV server. optionalSignature MUST be used when the individual response is signed. IndividalSignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } signatureAlgorithm contains the identifier for the cryptographic algorithm used to sign the structure. It may be used initially as an hint to make sure that the algorithm is supported, but its value MUST be equal to the value of signatureAlgo field from the IndividualResponseData hich is itself protected by the signature. signatureValue contains a digital signature computed upon the ASN.1 DER encoded mbsResponse. The ASN.1 DER encoded individualResponseData is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signatureValue field. The details of this process are specified for each of algorithms listed in [PKIXALGS]. certs is an optional sequence of certificates that MAY used to build the certification path in order to verify the signature. Pinkas [Page 17] Internet Draft CVP January 2003 validationData is an optional field that is not directly part of the signed data but only the hash of this field is included in the signature to keep the signed part short. IndividualResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, signatureAlgo AlgorithmIdentifier OPTIONAL, -- only when the DPV response is signed signatory CertOrCertRef OPTIONAL, -- only when the DPV response is signed nonce OCTET STRING OPTIONAL, majorStatus MajorStatus, minorStatus MinorStatus OPTIONAL, certProcessed CertOrCertRef, policy Policy, checks Checks, -- copied from the request serialNumber INTEGER -- allows to uniquely reference the response, producedAt GeneralizedTime, validationTime GeneralizedTime OPTIONAL, -- only for a DPV response requestHash AnyHash, -- computed over a single CertQuery requesterName [1] EXPLICIT GeneralName OPTIONAL, requesterData [2] EXPLICIT CHARACTER STRING OPTIONAL, validationDataHash [3] OCTET STRING OPTIONAL, serverContextInfo [4] OCTET STRING OPTIONAL, -- only for a DPD response responseExtensions [5] EXPLICIT Extensions OPTIONAL } The various parameters from the IndividualResponseData are the following: version allows to identify the version of the protocol. Version ::= INTEGER { v1(0) } signatureAlgo is an optional field that MUST be used when the individual DPV response is signed. It contains the identifier for the cryptographic algorithm used by the server to sign his response. This algorithm MUST be used to verify the signature. signatory is an optional field that MUST be used when the individual DPV response is signed. It contains the certificate or the certificate reference of the server. Since it is protected by the signature, there can be no ambiguity about the identity of the server. nonce if present in the request MUST be copied in that field. Pinkas [Page 18] Internet Draft CVP January 2003 majorStatus indicates the validity of the certificate according to either the validation or the discovery policy. For DPV: MajorStatus ::= CHOICE { valid [0] IMPLICIT NULL, invalid [1] IMPLICIT NULL, unknown [2] IMPLICIT NULL } 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 invalid according to the validation policy. When the response indicates "unknown", this means that information is missing to build a path between the certificate and a trusted anchor. This may also be, when the reference to the certificate is used, because the server is unable to get the actual value of the certificate. When the major status indicates that certificate is not valid according to the validation policy for the validation time, this may be a definitive invalidity (e.g. one of the certificates of the path is revoked), 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. The minor status provides more information. MinorStatus ::= CHOICE { referenceCertIncorrect [0] IMPLICIT NULL, -- Certificate reference incorrect certPathConstructFail [1] IMPLICIT NULL, -- path construction not possible certPathInvalid [2] IMPLICIT NULL, -- path constructed but invalid missingRevocStatus [3] IMPLICIT NULL, tryLater [4] IMPLICIT TryLater, revokedInfo [5] IMPLICIT RevokedInfo } referenceCertIncorrect indicates that the certificate reference is incorrect. CertPathConstructFail indicates that the path construction was not possible. CertPathInvalid indicates that the path could be successfully constructed but is invalid. Pinkas [Page 19] Internet Draft CVP January 2003 missingRevocStatus indicates that revocation status information could not be obtained or the one that could be obtained was not up to date (e.g. an old CRL). tryLater indicates the time at which another request could be attempted. At that time, the certificate could be determined as valid. As an example, this may be the case when a certificate is onHold. TryLater ::= GeneralizedTime revokedInfo indicates the reason for the revocation. RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revokedCert CertOrCertRef, revocationReason [0] EXPLICIT CRLReason OPTIONAL } For DPD: MajorStatus ::= CHOICE { requiredInfoPresent [0] IMPLICIT NULL, partialRequiredInfoPresent [1] IMPLICIT NULL, noRequiredInfoPresent [2] IMPLICIT NULL } When requiredInfoPresent is present, this means that all the requested information has been found; hence at least one path has been able to be constructed. When the major status indicates that partialRequiredInfoPresent is present then the minor status provides more details: MinorStatus ::= CHOICE { noRevocationInformation [0] IMPLICIT NULL, subsetOfRevocationInformation [1] IMPLICIT NULL, caRevocationInfoMissing [2] IMPLICIT NULL, certificateRevocationInfoMissing [3] IMPLICIT NULL } noRevocationInformation indicates that no revocation information is present. subsetOfRevocationInformation indicates that only a subset of the requested revocation information is present. caRevocationInfoMissing indicates that the revocation status of all or of some CAs is missing. certificateRevocationInfoMissing indicates that the revocation status of the certificate that was the object of the query could not be found. Pinkas [Page 21] Internet Draft CVP January 2003 When noRequiredInfoPresent is present, this means that none of the requested information has been found; hence no path has been able to be constructed. certProcessed is the certificate to validate. It MUST be a copy of the field present in the request. policy is either the validation or the discovery 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 is the object identifier that has been used to perform the validation, and any parameters when applicable. The caller SHOULD make sure that the policy field matches either matches the valOrDiscoPolicy field from the Request, if present, or matches its expectations, if missing. checks MUST be a copy of the corresponding field from the request. It allows to know what was the request type, without the need to keep a copy of the whole request. serialNumber MUST be an integer which is unique for the CVP server and which thus may be used to unambiguously reference a response together with the certificate from the CVP server. producedAt is the time at which the response has been formed. 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 be missing in the response. requestHash is hash computed over all the parameters from Request. The hash algorithm is chosen by the CVP server. signatory contains the certificate or the certificate reference under which the server is providing his signature. requesterName is a copy of the requesterName present in the request, if that field matches one of the identifiers of the requester when the requester is authenticated. requesterData MUST be a copy of the character string contained in the requesterData field from the request, if that field was present in the request. validationDataHash SHALL be present when the validationData field from the IndividualResponse is present. In that case, it SHALL be computed on the hash of the DER encoding of when the validationData field from the IndividualResponse. serverContextInfo, MUST only be present for a DPD response. It contains context for a request-response transaction. Since only one path at a time is being returned, the client can then use this value (and send the same query back to the server) and the server may be able to provide additional certification paths (if they may be found). Pinkas [Page 21] Internet Draft CVP January 2003 requestExtensions is a way to allow additional elements to be added later on, if needed. Some extensions are defined in section 7. 6. Definition of some simple validation-discovery policies The support of these policies is optional. The validation-discovery policies which are defined here are very simplified. The validation algorithm shall be conformant with the algorithm defined in section 6.1 from RFC 3280. This means that all these simple policies have a single trust anchor. Up to three parameters may be defined: - one self-signed certificate (trustanchor); (this parameter is mandatory), - a set of Certificate Policy (acceptablePolicySet); - the length of the certification path (pathLenConstraint). The validation-discovery policies are defined under the following arc: id-xy OBJECT IDENTIFIER ::= { XXXXXXXXXXXXXXXX } 6.1. Simple validation-discovery policy 1 This validation-discovery policy has the following characteristics: - the self-signed certificate starts (or ends) the certificate path processing. It SHALL not contain extensions like basicConstraints. - the revocation requirements are as follows: for each certificate from the path either a valid CRL or a valid OCSP response MUST be obtained. - there are no Time-Stamping requirements. - there are no specific requirements on the certificate to be validated. This validation-discovery policy has the following OID: id-xx OBJECT IDENTIFIER ::= { XXXXXXXXXXXXXXXX } 6.2. Simple validation-discovery policy 2 This validation policy has the following characteristics: - the self-signed certificate SHALL not contain extension like basicConstraints. - the revocation requirements are as follows: for each CA certificate from the path a valid CRL MUST be obtained. For the certificate under test, if that certificate is a CA certificate then a valid CRL Pinkas [Page 22] Internet Draft CVP January 2003 MUST be obtained, whereas if that certificate is an end-entity certificate then a valid OCSP response MUST be obtained. - there are no Time-Stamping requirements. - there are no specific requirements on the certificate to be validated. This validation policy has the following OID: id-yy OBJECT IDENTIFIER ::= { XXXXXXXXXXXXXXXX } 6.3. Parameters specific to the simple validation-discovery policies. One mandatory parameter, i.e. a self-signed certificate must be present. Two additional parameters allow to define the acceptable certificate policies and the path length constraints, if any. The parameters items of these policies are composed of the following three items: trustanchor Certificate, -- self-signed certificate acceptablePolicySet [0] AcceptablePolicySet OPTIONAL, -- if not present "any policy" pathLenConstraint [1] PathLenConstraint OPTIONAL -- if not present "any length" trustanchor provides the self signed certificate for the CA that is used as the trust anchor for the start of certificate path processing. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId acceptablePolicySet identifies the initial set of certificate policies, any of which MUST be included in the certificates from the path. For a certificate to be valid against that criteria, any certificate of the path MUST include one of these policies. PathLenConstraint is defined in RFC 3280. pathLenConstraint indicates the maximum number of CA certificates that may be in a certification path following the trust anchor. A value of zero indicates that only the given trust anchor and an end-entity certificate must form the path. If present, pathLenConstraint must be greater than or equal to zero. Where pathLenConstraint is not present, there is no limit to the allowed length of the certification path. 7. Extensions to support relaying and re-direction In some network environments, especially ones that include firewalls, a CVP server might not be able to obtain all of the information that it needs to process a request. However, the CVP server might be Pinkas [Page 23] Internet Draft CVP January 2003 configured to use the services of one or more other CVP servers to fulfill all requests. In such cases, the client is unaware that the queried CVP server is using the services of other CVP servers, and the client-queried CVP server acts as a CVP client to another CVP server. Unlike the original client, the CVP server is expected to have moderate computing and memory resources, enabling the use of relay, re-direct or multicasting mechanisms. The features mentioned in this section support CVP server-to-CVP server exchanges without imposing them on CVP client-to-CVP server exchanges. All these features are provided using non-critical extensions that are included either in requests or responses. In this way clients or servers automatically do not process the extensions if they do not support them. Each extension is associated with an OID. These OIDs are members of the id-xy arc, which is defined by the following: id-xy OBJECT IDENTIFIER ::= { XXXXXXXXXXXXXXXX } For relaying, the CVP server must leave a trace that it has relayed the request, in case, the request is relayed back. This information will allow to detect and stop loops. Ordinary servers may ignore this extension, since it is non-critical. However server that supports relaying using that protocol MUST understand and process that extension. For referrals, the CVP server may provide in the response additional information specifying the referrals. Since the extension is non critical, it may be ignored by the client. 7.1. Extensions for relaying This extension may only be present in a the requestExtensions field from a Request. This extension MUST NOT be marked critical. id-xy-relaying OBJECT IDENTIFIER ::= { id-xy Z } Relaying ::= SEQUENCE OF RelayInfo RelayInfo ::= OCTET STRING RelayInfo is used as a pseudo self-identifier. It is an octet string freely chosen by the CVP server in a way that it is likely to be unique for the server. It may be derived from its name, its certificate or any information specific to the server. That octet string must be memorized by the CVP server during a period of time that is sufficient for a loop to be formed (usually a few second). Pinkas [Page 24] Internet Draft CVP January 2003 When a CVP server wishes to relay a request towards another CVP server using this protocol, then, for each single request, it SHALL support the relaying extension. If a relaying extension was present in the request, then an additional RelayInfo SHALL be added to the content of the Relaying extension and included in the next request. If a Relaying extension was not present in the request, then a Relaying extension field shall be created and included in the next request. When a CVP server receives a request that includes a Relaying extension, then : - if it does not support relaying, the processing can continue. - if it supports relaying, it SHALL check if its pseudo self-identifier is present in any of the RelayInfo data: - If this is not the case, then there is no loop and ordinary processing can continue. - If this is the case, then there is a loop and it shall return to the caller an unknown major status in order to stop the loop. 7.2. Extensions for referrals This extension may only be present in a responseExtensions field from IndividualResponseData. This extension MUST NOT be marked critical. id-xy-referrals OBJECT IDENTIFIER ::= { id-xy W } Referrals ::= SEQUENCE OF Referral Referral ::= GeneralName Referral is defined as a GeneralName, which can take several forms. Where the information is available via http, then it MUST be a uniformResourceIdentifier. Where the information is available via electronic mail, it MUST be an rfc822Name. The client may ignore this extension, since it is non-critical or may use it to access another CVP server. 8. Transports There is no mandatory transport mechanism. However one of the three transport mechanisms described in this document MUST be supported. Pinkas [Page 25] Internet Draft CVP January 2003 8.1. CVP via sockets The following simple TCP-based protocol is to be used for transport of CVP messages. This protocol is suitable for cases where an entity initiates a transaction and can poll to pick up the results. The protocol basically assumes a listener process on a CVP server that can accept CVP messages on a well-defined port (IP port number XXX). Typically an initiator binds to this port and submits the initial CVP message. The responder replies with a CVP message and/or with a reference number to be used later when polling for the actual CVP message response. The initiator of a transaction sends a "direct TCP-based CVP message" to the recipient. The recipient responds with a similar message. A "direct TCP-based CVP message" consists of: length (32-bits), flag (8-bits), value (defined below) The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order. Message name flag value cvpMsg '00'H DER-encoded CVP message -- CVP message pollRep '01'H polling reference (32 bits), time-to-check-back (32 bits) -- poll response where no CVP message response ready; use polling -- reference value (and estimated time value) for later polling pollReq '02'H polling reference (32 bits) -- request for a CVP message response to initial message negPollRep '03'H '00'H -- no further polling responses (i.e., transaction complete) partialMsgRep '04'H next polling reference (32 bits), time-to-check-back (32 bits), DER-encoded CVP message -- partial response (receipt) to initial message plus new polling -- reference (and estimated time value) to use to get next part of -- response finalMsgRep '05'H DER-encoded CVP message -- final (and possibly sole) response to initial message errorMsgRep '06'H human readable error message -- produced when an error is detected (e.g., a polling reference -- is received which doesn't exist or is finished with) The sequence of messages that can occur is: a) entity sends cvpMsg and receives one of pollRep, negPollRep, partialMsgRep, or finalMsgRep in response. Pinkas [Page 26] Internet Draft CVP January 2003 b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in response. The "time-to-check-back" parameter is an unsigned 32-bit integer. It is the time in seconds indicating the minimum interval after which the client SHOULD check the status again. It provides an estimate of the time that the end entity should send its next pollReq. 8.2. CVP via HTTP ASN.1-encoded messages are wrapped with by MIME objects. Two MIME objects are specified as follows. Content-Type: application/pkcval-query <> Content-Type: application/pkcval-reply <> These MIME objects can be sent and received using common HTTP processing engines over WWW links and provides a simple browser- server transport for CVP messages. Upon receiving a valid request, the server MUST respond with either a valid response with content type application/pkcval-response or with an HTTP error. 8.3 CVP using Email The DER encoded CVPRequest and CVPResponses are encapsulated using MIME objects. Two MIME objects are specified as follows: Content-Type: application/pkcval-query Content-Transfer-Encoding: base64 <> Content-Type: application/pkcval-reply Content-Transfer-Encoding: base64 <> These MIME objects can be respectively sent and received using common MIME processing engines and provides a simple Internet mail transport for public key certificate validation messages. For the application/pkcval-query and application/pkcval-reply MIME types, implementations SHOULD include the optional "name" and "filename" parameters. Including a file name helps preserve type information when queries and replies are saved as files. Pinkas [Page 27] Internet Draft CVP January 2003 When these parameters are included, a file name with the appropriate extension SHOULD be selected: MIME Type File Extension application/pkcval-query .CVQ application/pkcval-reply .CVR In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name. 9. Security considerations A CVP client must trust a CVP server to provide the correct answer. However, this does not mean that all CVP clients will trust the same CVP servers. While a positive answer might be sufficient for one CVP client, that same positive answer will not necessarily convince another CVP client. Other clients may trust their own CVP servers, or they might perform certification path validation themselves. CVP clients operating under an organizational validation policy must ensure that each of the CVP servers they trust is operating under that organizational validation policy. The client SHOULD include a nonce in every request to prevent an attacker from replaying old responses from the server. When no policy reference is present in the CVP request, the CVP client ought to verify that the policy selected by the CVP server is appropriate. The revocation status information is obtained for the validation time. In case of the verification of a certificate used to verify a digital signature, the validation time is not necessarily identical to the time when the corresponding private key was used. The validation time ought to be adjusted by the CVP client to compensate for: 1) time for the end-entity to realize that its private key has been or could possibly be compromised, and/or 2) time for the end-entity to report the key compromise, and/or 3) time for the revocation authority to process the revocation request from the end-entity, and/or 4) time for the revocation authority to update and distribute the revocation status information. Pinkas [Page 28] Internet Draft CVP January 2003 10. Acknowledgments Many thanks to Ambarish Malpani, Russ Housley and Trevor Freeman. Several ideas from their alternative proposal to fulfill the requirements from RFC 3379 have been used to greatly improve this document. 11. Normative references [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. S.Bradner. March 1997 [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 [RFC3280] Internet X.509 Public Key Infrastructure. Certificate and CRL Profile. RFC 3280 R. Housley, W. Ford, W. Polk, D. Solo. April 2002. [RFC3379] Delegated Path Validation and Delegated Path Discovery Protocol Requirements. RFC 3379. R. Housley, D.Pinkas. September 2002 [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. [RFC3126] Electronic Signature Formats for long term electronic signatures D. Pinkas, J. Ross, N. Pope. RFC 3126. [RFC2634] Enhanced Security Services for S/MIME. P. Hoffman. RFC 2634. June 1999. Pinkas [Page 29] Internet Draft CVP January 2003 12. Authors' addresses Denis Pinkas Bull Rue Jean Jaures 78340 LES Clayes-sous-Bois FRANCE e-mail: Denis.Pinkas@bull.net 13. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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 30] Internet Draft CVP January 2003 Annex A (normative): ASN.1 Definitions To be provided. Pinkas [Page 31]