Internet Draft Denis Pinkas, Bull draft-ietf-pkix-cvp-00.txt June, 2002 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 fully delegate the validation of a certificate to a CVP server, according to a set of rules called a validation 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 The Certificate Validation Protocol (CVP) allows a server to validate one or more public key certificates on behalf of a client according to a single validation policy. The validation policy may be defined using any kind of language (natural or not). Pinkas [Page 1] Internet Draft CVP June 2002 Policy definitions can be quite 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 simple policies which include a few parameters in the CVP request; 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. 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 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. 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. The certificate to be validated MUST either be directly provided in the request or unambiguously referenced, such as the CA distinguished name, certificate serial number, and the hash of the certificate, like ESSCertID as defined in [ESS]. 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 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. Pinkas [Page 2] Internet Draft CVP June 2002 The CVP server MUST have 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 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. Unless, validity cannot be determined 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 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 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 will then be copied by the server in its response. The client may request the server to include in its response additional information which will allow relying parties not trusting the CVP server to be confident that the certificate validation has correctly been performed. Such information 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 according to the validation policy, the server MUST, upon request, include that information in the response. However, the server will omit that information when the certificate is invalid or when it cannot determine the validity. Pinkas [Page 3] Internet Draft CVP June 2002 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. The client may check that the response is bound to the CVP request so that the client, to make sure that all the parameters from the request have been taken into consideration by the CVP server to build the response. This is accomplished by including a one-way hash of the request parameters in the response. In some environments it may be necessary to present only a CVP response to another relying party without the corresponding request. In this case the response MUST be self contained. This can be accomplished by repeating the important components from the request in the response. For the client to be confident that the certificate validation was handled by the expected CVP server, and unless an error is reported (such as a badly formatted request or unknown validation policy)the CVP response is digitally signed and an unambiguous reference of the certificate from the CVP server is included as one of the signed parameters. In this way, the CVP serverĘs certificate authenticates the CVP server. For the client to be able prove to a third party that trusts the same CVP server that the certificate validation was handled correctly, the CVP response is digitally signed, unless an error is reported. In order to be able to prove to a third party (that does not trust the same CVP server ) that the 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. The CVP server MAY require client authentication, therefore, the CVP request MAY refuse the service if the request is not authenticated. When the 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. Note: 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 4] Internet Draft CVP June 2002 3. Validation Policy A validation policy is a set of rules against which the validation of the certificate is 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. 4. Initial validation and re-validation The same validation protocol may be used 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. 4.1 Initial validation The initial validation is performed according to the 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 is 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, but may also provide as well previous returned values of the certification path. 5. Description the CVP protocol A CVP request may be optionally signed and contains the following data: -- a protocol version -- either the identification of the certificate(s) to validate or the certificate(s) themselves -- optionally, the validation policy to be used Pinkas [Page 5] Internet Draft CVP June 2002 -- whether or not the references of the path should be returned -- whether or not the references of the path should be time-stamped -- whether or not the values of the path should be returned -- optionally, useful certificates that can be used by the server -- optionally, useful revocation information that can be used by the server -- optionally, previous returned references for re-validation -- optionally, previous returned values for re-validation -- a nonce to allow replay protection -- 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 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 are not met, the CVP responder produces an unsigned error message; otherwise, it returns a definitive signed response. A CVP response contains a major status, followed by a signed response in case of "success" and optionally with path references and path values. For each certificate to be validated, the major status of the response may be one out of three types: 1) the certificate is valid according to the validation policy. 2) the certificate is not valid according to the validation policy. 3) the validity of the certificate is unknown according to the validation policy (e.g. a path cannot be constructed). 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. If another request could made later on, the certificate could be determined as valid. This level of detail is indicated in a secondary status. 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. Pinkas [Page 6] Internet Draft CVP June 2002 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 unambiguous references to the certification path and the revocation status information is part of the signed response, and the actual values of the validation data (certificates, CRLs, delta-CRLs or OCSP responses) are not part of the signed response. The signed response includes the following data: -- protocol version, -- the reference of the CVP server certificate (ESSCertID). and for each certificate validated: -- the validation status, -- identification of the certificate that has been validated, -- the reference of the validation policy that has been used -- a serial number for that response -- the validation time, -- the response time, -- an optional nonce to detect replays, -- optional identification(s) of the requester, -- optional data from the requester that is copied in the response -- an optional hash of the validation data, -- 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 [ES-F]. For signature calculation, the data that may be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. The terms imported from elsewhere are: Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, 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, optionalSignature [0] EXPLICIT Signature OPTIONAL } Pinkas [Page 7] Internet Draft CVP June 2002 MBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, valPolicy ValPolicy OPTIONAL, signatory ESSCertID OPTIONAL multipleRequests SEQUENCE OF SingleRequest } Version ::= INTEGER { v1(0) } version allows to identify the version of the protocol. valPolicy is a reference to the validation policy to be used. If the field is missing, the server will indicate which validation policy has been used. It is may either be the unambiguous reference of a validation policy or a simple policy as defined in this document or in other RFCs. signatory MUST contain, when the request is signed, an unambiguous reference to the certificate from the requester. It is used to authenticate the requester. multipleRequests may be composed of a single request or of multiple requests. SingleRequest ::= SEQUENCE { certToValidate CertOrCertRef, validationTime GeneralizedTime OPTIONAL, nonce INTEGER OPTIONAL, usefulCerts CertificateValues OPTIONAL, usefulRevoc RevocationValues OPTIONAL, -- defined in [ES-F] returnValues [1] BOOLEAN Default FALSE, returnRefs [2] BOOLEAN Default FALSE, timeStampRefs [3] BOOLEAN Default FALSE, requesterName [4] EXPLICIT GeneralName OPTIONAL, requesterData [5] EXPLICIT CHARACTER STRING OPTIONAL, previousValidationData ValidationData OPTIONAL, requestExtensions [6] 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: the issuer name and the serial number of the certificate, and a hash value of the certificate in order to guard both against compromission of CA keys and CA name homonyms. nonce is a unique number (e.g. a large pseudo random number) generated by the client that may be used to detect replay. validationTime is the time for which the validation should be performed. If that field is missing, then the current time is assumed. usefulCerts is a set of certificates that may be useful for the server to build a path. Pinkas [Page 8] Internet Draft CVP June 2002 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. 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. 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. 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. requestExtensions is a way to allow additional elements to be added later on, if needed. Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } CertOrCertRef ::= CHOICE { certificate [1] Certificate, certRef [2] CertRef } CertOrCertRef may specify the certificate itself or an unambiguous reference of the certificate (which includes a hash value of the certificate). Pinkas [Page 9] Internet Draft CVP June 2002 CertRef ::= CHOICE { eSSCertId ESSCertID, otherCertId OtherCertId } OtherCertId ::= SEQUENCE { issuerSerial IssuerSerial, certHash AnyHash } AnyHash ::= CHOICE { sha1Hash HashValue, -- This contains a SHA-1 hash value otherHash OtherHashAlgAndValue } HashValue ::= OCTET STRING OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue HashValue } The hash value of the certificate may be computed using SHA-1 (i.e. using ESSCertID) or another hash algorithm (i.e. using OtherCerttID) ValPolicy ::= CHOICE { simpleValPolicy SimpleValPolicy, otherValPolicy ValPolicyRef } ValPolicy is either a simple validation policy or referenced validation policy. When it is a referenced validation policy, then it is composed of an OID or a URN, the hash algorithm to be used to compute the hash value of the policy and the hash value of the policy. When it is a simple validation policy, it must include one mandatory parameter, i.e. a self-signed certificate and may include two additional parameters to define the acceptable Certificate Policies and the path length constraints, if any. See section 6 for the exact definition of the simple validation policies defined in this document. SimpleValPolicy ::= SEQUENCE { valPolicyID OBJECT IDENTIFIER, 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. Pinkas [Page 10] Internet Draft CVP June 2002 acceptablePolicySet identifies the initial set of certificate policies, any of which MUST be included in the certificates from the path. 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. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId CertPolicyId ::= OBJECT IDENTIFIER AcceptablePolicySet specifies a set of certificate policies. For a certificate to be valid against that criteria, any certificate of the path MUST include one of these policies. ValPolicyRef ::= SEQUENCE{ valPolicyID ValPolicyID, valPolicyHashAlg AlgorithmIdentifier, valPolicyHash ValPolicyHash, valPolLocation ValPolLocations OPTIONAL } ValPolicyID :: = CHOICE { policybyOId OBJECT IDENTIFIER, policybyURN NAME } ValPolicyHash ::= OCTET STRING The valPolicyID field contains an object-identifier or a URI which uniquely identifies a specific version of the signature policy The value for valPolicyHash SHALL be computed on the hash of the DER encoding of ValidationPolicyDef when the policy is locally defined or of the definition of the policy when it is externally defined. ValPolLocations :: = SEQUENCE OF Name valPolLocation contains web URIs or URL references to the definition of signature policy. CertificateValues ::= SEQUENCE OF Certificate UsefulCerts is a set of certificates, some of them may be useful to build the path. Pinkas [Page 11] Internet Draft CVP June 2002 ValidationData ::= CHOICE { pathInfo PathInfo, singleCvpResponse SingleCvpResponse } ValidationData may either be: - information on the path (certificates, CRLs or OCSP responses), - or a single CVP response, from a CVP server trusted under the validation policy. PathInfo ::= SEQUENCE { certificateValues CertificateValues, revocationValues RevocationValues, certPathRefs CertPathRefs OPTIONAL } CertPathRefs ::= SEQUENCE { pathRefrences ValidatedPathRefs, timeStamps SEQUENCE OF TimeStampToken OPTIONAL } ValidatedPathRefs ::= SEQUENCE { certificateRefs CompleteCertificateRefs, -- defined in [ES-F] revocationRefs CompleteRevocationRefs -- defined in [ES-F] } 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 { version [0] EXPLICIT Version DEFAULT v1, cVPStatus CVPResponseStatus, multipleResponses SEQUENCE OF SingleCvpResponse } Pinkas [Page 12] Internet Draft CVP June 2002 CVPResponseStatus ::= ENUMERATED { successful (0), -- Request was understood malformedRequest (1), -- malformed request internalError (2), -- internal error in issuer tryLater (3), -- try again later sigRequired (4), -- must sign the request unauthorized (5), -- request unauthorized unknownValPolicy (6) -- validation policy unknown } SingleCvpResponse ::= SEQUENCE { tbsResponse TBSResponse OPTIONAL, validationReferences ValidationReferences OPTIONAL, validationData ValidationData OPTIONAL } TBSResponse ::= SEQUENCE { individualResponse SingleResponseData, optionalSignature [0] EXPLICIT Signature OPTIONAL } } The value for signature SHALL be computed on the hash of the DER encoding of SingleResponseData. SingleResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, majorStatus MajorStatus, minorStatus MinorStatus OPTIONAL, cVPServerCert ESSCertID, requestHash AnyHash, certProcessed CertOrCertRef, valPolicy ValPolicy, serialNumber INTEGER, validationTime GeneralizedTime, producedAt GeneralizedTime, nonce INTEGER OPTIONAL, requesterName [1] EXPLICIT GeneralName OPTIONAL, requesterData [2] EXPLICIT CHARACTER STRING OPTIONAL, validationDataHash OCTET STRING OPTIONAL, responseExtensions [3] EXPLICIT Extensions OPTIONAL } The various parameters from the SingleResponseData are the following: version allows to identify the version of the protocol. majorStatus indicates the validity of the certificate according to the validation policy. 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. Pinkas [Page 13] Internet Draft CVP June 2002 When the response indicates "unknown", this means that information is missing to build a path between the leaf 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 leaf certificate. requestHash is hash computed over all the parameters from SingleRequest. The hash algorithm is chosen by the CVP server. Since requestHash does not include the valPolicy field from MBSRequest, the caller SHOULD make sure that the valPolicy field from each SingleResponseData matches either matches the valPolicy field from MBSRequest, if present, or matches its expectations, if missing. certProcessed is the certificate to validate. It is a copy of the field present in the request. validationPolicy is the validation policy that has been used. It is a copy of the field present in the request, if that field was present. If the field was not present, it is the object identifier that has been used to perform the validation. serialNumber is 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. validationTime is the time for which the validation should be performed. If that field was present in the request it is a copy of the field present in the request. If that field was not present then the current time is being assumed and that time is identical to the next field: producedAt. producedAt is the time at which the response has been formed. pathReferencesHash is a hash computed over the references of the path (both the references of the certificates used and the references of the revocation information used). It may also include a sequence of time-stamps, if this has been requested in the request. Since only the hash is included in the signature, this allows to keep signatures short and does not mandate to know the values of the references of the path to verify the cVPResponseStatus from the response. pathValuesHash is a hash computed over the values of the path (both the values of the certificates used and the values of the revocation information used). Since only the hash is included in the signature, this allows to keep signatures short and does not mandate to know the values of the values of the path to verify the cVPResponseStatus from the response. nonce is a pseudo random number generated by the client that may be used to detect replay. requesterName is a copy of one field present in the request, that matches one of the identifiers of the requester when the requester is authenticated. Pinkas [Page 14] Internet Draft CVP June 2002 requesterData is a copy of character string, when present in the request validationDataHash SHALL be present when the validationData field from the SingleCvpResponse is present. In that case, it SHALL be computed on the hash of the DER encoding of when the validationData field from the SingleCvpResponse. requestExtensions is a way to allow additional elements to be added later on, if needed. Some extensions are defined in section 7. MajorStatus ::= CHOICE { valid [0] IMPLICIT NULL, invalid [1] IMPLICIT NULL, unknown [3] IMPLICIT NULL } MinorStatus ::= CHOICE { missingRevocStatus [0] IMPLICIT NULL, onHold [1] IMPLICIT TryLater, revokedInfo [2] IMPLICIT RevokedInfo } TryLater ::= GeneralizedTime RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revokedCert CertOrCertRef, revocationReason [0] EXPLICIT CRLReason OPTIONAL } 6. Definition of some simple validation policies The validation 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 policies are defined under the following arc: id-xy OBJECT IDENTIFIER ::= { XXXXXXXXXXXXXXXX } Pinkas [Page 15] Internet Draft CVP June 2002 6.1. Simple validation policy 1 This validation 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 policy has the following OID: T.B.A. 6.2. Simple validation 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 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: T.B.A. Pinkas [Page 16] Internet Draft CVP June 2002 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 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. 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 SingleRequest. This extension MUST NOT be marked critical. id-xy-relaying OBJECT IDENTIFIER ::= { id-xy Z } Relaying ::= SEQUENCE OF RelayInfo RelayInfo ::= ESSCertID RelayInfo allows to unambiguously identify the CVP server. 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. Pinkas [Page 17] Internet Draft CVP June 2002 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 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 a SingleResponseData. 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 18] Internet Draft CVP June 2002 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 19] Internet Draft CVP June 2002 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. Pinkas [Page 20] Internet Draft CVP June 2002 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 certificate validation queries and replies are saved as files. 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. 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 21] Internet Draft CVP June 2002 10. Acknowledgments To be provided. 11. Normative references [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. S.Bradner. March 1997 [RFC3280] Internet X.509 Public Key Infrastructure. Certificate and CRL Profile. RFC 3280 R. Housley, W. Ford, W. Polk, D. Solo. April 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. [ES-F] Electronic Signature Formats for long term electronic signatures D. Pinkas, J. Ross, N. Pope. RFC 3126. [ESS] Enhanced Security Services for S/MIME. P. Hoffman June 1999. 12. Authors' addresses Denis Pinkas Bull 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE e-mail: Denis.Pinkas@bull.net Pinkas [Page 22] Internet Draft CVP June 2002 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 23] Internet Draft CVP June 2002 Annex A (normative): ASN.1 Definitions To be provided. Pinkas [Page 24]