Internet Draft Denis Pinkas, Integris draft-ietf-pkix-dpv-dpd-00.txt July, 2001 Expires in six months Delegated Path Validation and Delegated Path Discovery Protocols Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document specifies two protocols. The first one, called Delegated Path Validation (DPV) can be used to fully delegate a path validation processing to an DPV server, according to a set of rules called a validation policy. The second one, called Delegated Path Discovery (DPD) can be used to obtain from a DPD server all the information needed (e.g. leaf certificates, CA certificates, full CRLs, delta-CRLs, OCSP responses) to locally validate a certificate according to a set of rules called a path validation criteria. This provides a single protocol to collect at one time all data elements that normally require different protocols. It also defines an optional protocol allowing to define the set of rules to validate a certificate or to build a path for a certificate. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. Pinkas [Page 1] Internet Draft DPV&DPD July 2001 2. Delegated Path Validation Protocol Overview The Delegated Path Validation (DPV) protocol allows to validate one certificate for a time T and according to a set of rules, called a validation policy. The validation policies may be known a priori by the DPV server or may be defined by the DPV client. When the validation policy is not a priori known by the DPV server, the client may define it using an additional protocol. The support of that additional protocol is optional. In this way, the validation protocol always refers to a validation policy defined both by an OID and a hash in order to make sure that the definition of the validation policy is as intended. The time T may be close to the present time or a time in the past. When it is a time close to the present time, the server MUST do its best efforts to perform the validation (validation may not be possible if the required data may not be collected). This is called an initial validation. The support of validation in the past, using some data previously captured at the time of initial verification is optional. When supported, the server MUST be able to use the 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. In order to obtain the revocation status information of any certificate from the certification path, the DPV server MAY use, as appropriate and accordingly to the validation policy, any combination of OCSP requests, CRLs or delta-CRLs. 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, in particular to the leaf certificate MAY also be specified in the validation policy. Pinkas [Page 2] Internet Draft DPV&DPD July 2001 An optional protocol allows to define the validation policy. See section 8. 4. Initial validation and re-validation The same validation protocol may be used either for: 1) initial validation or for, 2) re-validation. 4.1 Initial validation The initial validation is performed according to the validation policy. Additional conditions MAY be locally added, e.g. in order to test the presence of some extensions in the certificate chain. 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 MUST verify that the one selected is appropriate for its use. The status of the response may be one out of four types: 1) the certificate is valid according to the validation policy, 2) the certificate is not valid according to the validation policy, 3) the certificate is conditionally valid according to the validation policy. A path has been able to be constructed, however one or more revocation status information are missing. If another request could made later on, the certificate could be determined as valid. 4) the server cannot determine the validity (e.g. a path cannot be constructed). In most instances, in order to be able to prove to a third party that the check has correctly be done, the client will only require a signed response. In other cases, the client will need 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 re- validation. In such a case the server will need to return that information, called validation data. The validation data can be rather long since it consists 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 response could be rather long if needed to be stored. For that reason, only the unambiguous references to the certification path and the revocation status information are optionally returned, and only the hash of it is part of the signed response. Pinkas [Page 3] Internet Draft DPV&DPD July 2001 In addition the actual values of the validation data (certificates, CRLs, delta-CRLs or OCSP responses) may also be returned and only the hash of it is part of the signed response. 4.2 Re-validation Re-validation is performed according to a validation policy. The client MUST specify in its request the validation policy to be used. The requestor MUST specify the certificate to be validated and MUST provide previous returned references of the certification path, but may need to provide as well previous returned values of the certification path. 5. Description the DPV protocol A DPV request may be optionally signed and contains the following data: -- protocol version -- optionally, the identification of the requestor -- identification of the certificate to validate -- optionally, the validation policy to be used -- whether or not the references of the path should be returned -- whether or not the values of the path should be returned -- whether or not the references of the path should be time-stamped -- 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, when the client has no clock -- optional extensions Upon receipt of a request, a DPV 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 DPV responder produces an error message; otherwise, it returns a definitive response. A DPV response contains a major status, followed by a signed response in case of "success" and optionally followed with path references and path values. Pinkas [Page 4] Internet Draft DPV&DPD July 2001 The signed response includes the following data: -- protocol version, -- an optional identification of the requestor, -- the validation status, -- identification of the certificate that has been validated, -- the reference of the validation policy that has been used -- the validation time, -- the response time, -- an optional hash of the path references, that may include a sequence of time-stamps, -- an optional hash of the path values, -- an optional nonce to detect replays, -- a field for future extensions. 5.2. Detailed Protocol The ASN.1 syntax imports terms defined in [RFC2459] and in [ES-F]. For signature calculation, the data to 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, CompleteCertificateRefs, CompleteRevocationRefs. 5.2.1. Request This section specifies the ASN.1 specification for a request. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). DPVRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, certToValidate CertOrCertRef, valPolicyRef ValPolicyRef OPTIONAL, validationTime GeneralizedTime OPTIONAL, returnRefs [2] BOOLEAN Default FALSE, returnValues [3] BOOLEAN Default FALSE, timeStampRefs [4] BOOLEAN Default FALSE, usefulCerts UsefulCerts OPTIONAL, usefulRevoc UsefulRevoc OPTIONAL, previousReturnedRefs PathReferences OPTIONAL, nonce INTEGER OPTIONAL, requestExtensions [5] EXPLICIT Extensions OPTIONAL } Pinkas [Page 5] Internet Draft DPV&DPD July 2001 Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } Version ::= INTEGER { v1(0) } CertOrCertRef ::= CHOICE { certificate [1] Certificate, certRef [2] OtherCertID } ValPolicyRef ::= SEQUENCE{ valPolicyID ValPolicyID, valPolicyHashAlg AlgorithmIdentifier, valPolicyHash ValPolicyHash, valPolLocation ValPolLocations OPTIONAL } ValPolicyID :: = CHOICE { policybyOId OBJECT IDENTIFIER, policybyURN NAME } ValPolicyHash ::= OCTET STRING 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 UsefulCerts ::= CHOICE { certificateSet CertificateSet, completeCertificateRefs CompleteCertificateRefs } UsefulRevoc ::= CHOICE { certificateRevocationLists CertificateRevocationLists, completeRevocationRefs CompleteRevocationRefs } PathReferences :: = SEQUENCE { completeCertificateRefs CompleteCertificateRefs, completeRevocationRefs CompleteRevocationRefs } PathValues :: = SEQUENCE { certificateValues CertificateValues, revocationValues RevocationValues } version allows to identify the version of the protocol. requestorName is an optional field that allows to identify the requestor. It is used when the request is signed. In that case the name of the requestor must match one of the names found in the certificate. Pinkas [Page 6] Internet Draft DPV&DPD July 2001 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 against compromission of CA keys. Structures like ESSCertID can be used as a reference. validationPolicyRef is a reference to the validation policy to be used. If the field is missing, the server will indicate which pre- defined policy has been used. 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. validationTime is the time for which the validation should be performed. If that field is missing, then the current time is assumed. 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). 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). 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 or OCSP responder would be compromised after the date of issue of the time- stamps. usefulCerts is a set of certificates, usually obtained through the application protocol that may be useful for the server to build a path. usefulRevoc is a set of revocation information, usually obtained through the application protocol that may be useful for the server to make sure that no element from the path is revoked. previousReturnedRefs is used to avoid to return previous returned paths. nonce is a unique number (e.g. a large pseudo random number) generated by the client that may be used to detect replay. requestExtensions is a way to allow additional elements to be added later on, if needed. 5.2.2. Response Syntax This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). Pinkas [Page 7] Internet Draft DPV&DPD July 2001 An DPV response at a minimum consists of a dPVStatus field indicating the processing status of the prior request. If the value of dPVStatus is one of the error conditions, tbsResponse and optionalSignature are not set. DPVResponse ::= SEQUENCE { dPVStatus DPVResponseStatus, tbsResponse TBSResponse OPTIONAL, optionalSignature [0] EXPLICIT Signature OPTIONAL, pathReferences CertPathRefs OPTIONAL, pathValues CertPathValues OPTIONAL } CertPathRefs :: = SEQUENCE { pathReferences SEQUENCE OF PathReferences, timeStamping SEQUENCE OF TimeStampToken OPTIONAL } CertPathValues ::= SEQUENCE OF PathValues DPVResponseStatus ::= ENUMERATED { successful (0), -- Request was understood malformedRequest (1), -- malformed request internalError (2), -- internal error in issuer tryLater (3), -- try again later -- (4) is not used sigRequired (5), -- must sign the request unauthorized (6) -- request unauthorized } TBSResponse ::= SEQUENCE { tbsResponseData DPVResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } The value for signature SHALL be computed on the hash of the DER encoding of DPVResponseData. DPVResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, validationStatus ValidationStatus certProcessed CertOrCertRef, valPolicyRef ValPolicyRef, validationTime GeneralizedTime, producedAt GeneralizedTime, pathReferencesHash OCTET STRING OPTIONAL, pathValuesHash OCTET STRING OPTIONAL, nonce INTEGER OPTIONAL, responseExtensions [2] EXPLICIT Extensions OPTIONAL } The value for returnedRefsHash SHALL be computed on the hash of the DER encoding of CertPathRefs. Pinkas [Page 8] Internet Draft DPV&DPD July 2001 The value for returnedValuesHash SHALL be computed on the hash of the DER encoding of CertPathValues. ValidationStatus ::= CHOICE { valid [0] IMPLICIT NULL, invalid [1] IMPLICIT RevokedInfo, conditionallyValid [2] IMPLICIT TryLater, unknown [3] IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revokedCert CertOrCertRef, revocationReason [0] EXPLICIT CRLReason OPTIONAL } TryLater ::= GeneralizedTime UnknownInfo ::= NULL -- this can be replaced with an enumeration The response MUST be integrity protected. Thus the signature MUST be used if the request was successful. The various parameters from the DPVResponseData are the following: version allows to identify the version of the protocol. requestorName is a copy of the field present in the request, if that field was present. validationStatus 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. When the response indicates "conditionallyValid", this means that either some revocation information is currently missing or that the one element of the certification path is currently "on hold". In that case the server indicates when another attempt could be done. 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. certProcessed is the certificate to validate. It is a copy of the field present in the request. Pinkas [Page 9] Internet Draft DPV&DPD July 2001 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. 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 dPVResponseStatus 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 dPVResponseStatus from the response. nonce is a pseudo random number generated by the client that may be used to detect replay. requestExtensions is a way to allow additional elements to be added later on, if needed. 6. Delegated Path Discovery Protocol Overview The Delegated Path Discovery (DPD) protocol allows to obtain information that can be used to locally validate one certificate for the current time and according to a path validation criteria. The path validation criteria may either be a sequence of self-signed certificates or a reference to a validation policy. None, one or several certification paths may be returned. Each path consists of a sequence of certificates, starting with the certificate to validate and ending with one self-signed certificate. In addition, the revocation information associated with each path may also be returned. The client may indicate the maximum number of certification paths that MUST be returned, provided that they may be found. If the number is not specified, that number is defaulted to one. Pinkas [Page 10] Internet Draft DPV&DPD July 2001 The paths that are returned may need to match some additional local controls done by the client, e.g. verifying some certificate extensions. If the paths that are returned do not mach the local conditions, then the number of number of certification paths to be returned can be extended, by augmenting this value. The server may use a local cache to avoid to search again the same elements, but is not mandated to maintain any local state information from any previous request. Path discovery is performed according to the path validation criteria. The status of the response may be one out of three types: 1) one or more certification paths could be found according to the path validation criteria, with partial or full revocation information present. 2) one or more certification paths could be found according to the path validation criteria, with no revocation information present. 3) no certification path could be found according to the path validation criteria, The information that is returned consists of one or more certification paths and its associated revocation status information for each element from the path. 6.1. Description the DPD protocol A DPD request may be optionally signed and contains the following data: -- protocol version -- identification of the certificate for the path discovery -- the path discovery criteria to be used -- optionally, the number of certification paths to be returned -- whether or not the revocation data should be returned -- optionally, useful certificates that can be used by the server -- optionally, useful revocation information that can be used by the server -- a nonce to allow replay protection, when the client has no clock -- optional extensions Upon receipt of a request, a DPD 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. Pinkas [Page 11] Internet Draft DPV&DPD July 2001 If any one of the prior conditions are not met, the DPD responder produces an error message; otherwise, it returns a definitive response. A DPD response contains a major status, followed by a response in case of "success" and with path values. The response includes the following data: -- protocol version, -- the discovery status, -- identification of the certificate under path discovery, -- the path discovery criteria that has been used -- the response time, -- the path values, -- an optional limit for the number of certification paths that have been returned -- an optional nonce to detect replays, -- a field for future extensions. The response SHOULD be protected by a data origin authentication service combined with a data integrity service. A TLS protection or an IPSEC protection may be appropriate. 6.2. Detailed Protocol The ASN.1 syntax imports terms defined in [RFC2459] and in [ES-F]. ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. The terms imported from elsewhere are: Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReason, CompleteCertificateRefs, CompleteRevocationRefs. 6.2.1. Request This section specifies the ASN.1 specification for a request. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). DPDRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, certUnderDiscovery CertOrCertRef, pathDiscoveryCriteria PathDiscoveryCriteria, pathsNumber INTEGER DEFAULT 1, returnRevocInfo BOOLEAN DEFAULT TRUE, usefulCerts UsefulCerts OPTIONAL, usefulRevoc UsefulRevoc OPTIONAL, nonce INTEGER OPTIONAL, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Version ::= INTEGER { v1(0) } Pinkas [Page 12] Internet Draft DPV&DPD July 2001 CertOrCertRef ::= CHOICE { certificate [1] Certificate, certRef [2] OtherCertID } PathDiscoveryCriteria :: = CHOICE { trustpoints SEQUENCE OF Certificate -- self-signed certificates valpolref ValPolicyRef } version allows to identify the version of the protocol. certUnderDiscovery is the certificate for which one or more path should be formed. 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 against compromission of CA keys. Structures like ESSCertID can be used as a reference. pathDiscoveryCriteria is either a sequence of self-signed root certificates or a reference to a validation policy to be used. This field MUST be present. pathsNumber indicates the number of paths to be returned. The default value is one. returnRevocInfo indicates whether or not revocation information should be returned. By default, revocation information is returned. usefulCerts is a set of certificates, usually obtained through the application protocol that may be useful for the server to build a path. usefulRevoc is a set of revocation information, usually obtained through the application protocol that may be useful for the server to make sure that no element from the path is revoked. nonce is a unique number (e.g. a large pseudo random number) generated by the client that may be used to detect replay. requestExtensions is a way to allow additional elements to be added later on, if needed. 6.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 DPD response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, discoveryResponse is not present. Pinkas [Page 13] Internet Draft DPV&DPD July 2001 DPDResponse ::= SEQUENCE { responseStatus DPDResponseStatus, discoveryResponse DiscoveryResponse OPTIONAL } DPDResponseStatus ::= ENUMERATED { successful (0), -- request was understood malformedRequest (1), -- malformed request internalError (2), -- internal error in issuer tryLater (3), -- try again later -- (4) is not used -- (5) is not used unauthorized (6) -- request unauthorized } DiscoveryResponse ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, discoveryStatus DiscoveryStatus certUnderDiscovery CertOrCertRef, pathDiscoveryCriteria PathDiscoveryCriteria, producedAt GeneralizedTime, pathsDiscovered PathsDiscovered OPTIONAL, pathsNumberLimit INTEGER OPTIONAL, nonce INTEGER OPTIONAL, responseExtensions [2] EXPLICIT Extensions OPTIONAL } DiscoveryStatus ::= CHOICE { certswithRevoc [0] IMPLICIT NULL, certsNoRevoc [1] IMPLICIT NULL, noPathFound [2] IMPLICIT NULL } PathsDiscovered::= SEQUENCE OF PathValues The various parameters from the DiscoveryResponse are the following: version allows to identify the version of the protocol. discoveryStatus indicates the result of the discovery according to path validation criteria. When the response indicates "certswithRevoc", this means at least one path has been found, with partial or full revocation information is present. When the response indicates "certsNoRevoc", this means that at least one path has been found, but no revocation information is present. When the response indicates "noPathFound", this means that the no path has been able to be found. certUnderDiscovery is the certificate for which one or more path should be formed. It is a copy of the field present in the request. Pinkas [Page 14] Internet Draft DPV&DPD July 2001 pathDiscoveryCriteria is either a sequence of self-signed root certificates or a reference to a validation policy to be used. It is a copy of the field present in the request. producedAt is the time at which the response has been formed. pathsDiscovered is a sequence of PathValues. Each sequence corresponds to one path. pathsNumberLimit is an optional element that is used by the server to indicate that the number of paths that have been returned has been limited by the server to this value. Rules with a lower granularity should be used for further requests. nonce is a pseudo random number generated by the client that may be used to detect replay. requestExtensions is a way to allow additional elements to be added later on, if needed. 7. Components for a validation policy A validation policy is build from three components: 1. Certificate requirements, 2. Revocation requirements, 3. Optional Time-Stamping requirements. The ASN.1 construct for a validation policy definition is as follows: ValPolicyDef :: = SEQUENCE OF PolicyRequirement PolicyRequirement :: = SEQUENCE { certificateRequirements CertificateTrustPoint, revocRequirements RevocRequirements, timeStampingRequirements TimeStampingRequirements OPTIONAL } 7.1. Certificate Requirements The certificateRequirements identifies a self-signed root certificate used to start (or end) certificate path processing and the initial conditions for certificate path validation as defined RFC 2459 [7] section 4. CertificateTrustPoint ::= SEQUENCE { trustpoint Certificate, -- self-signed certificate pathLenConstraint [0] PathLenConstraint OPTIONAL, acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, -- if not present "any policy" nameConstraints [2] NameConstraints OPTIONAL, policyConstraints [3] PolicyConstraints OPTIONAL } Pinkas [Page 15] Internet Draft DPV&DPD July 2001 The trustPoint field gives the self signed certificate for the CA that is used as the trust point for the start of certificate path processing. The pathLenConstraint field gives the maximum number of CA certificates that may be in a certification path following the trustpoint. A value of zero indicates that only the given trustpoint certificate and an end-entity certificate may be used. If present, the pathLenConstraint field 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. PathLenConstraint ::= INTEGER (0..MAX) The acceptablePolicySet field identifies the initial set of certificate policies, any of which are acceptable under the signature policy. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId CertPolicyId ::= OBJECT IDENTIFIER The nameConstraints field indicates a name space within which all subject names in subsequent certificates in a certification path must be located. Restrictions may apply to the subject distinguished name or subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable. Restrictions are defined in terms of permitted or excluded name subtrees. Any name matching a restriction in the excludedSubtrees field is invalid regardless of information appearing in the permittedSubtrees. NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL } BaseDistance ::= INTEGER (0..MAX) The policyConstraints extension constrains path processing in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier. The policyConstraints field, if present specifies requirement for explicit indication of the certificate policy and/or the constraints on policy mapping. Pinkas [Page 16] Internet Draft DPV&DPD July 2001 PolicyConstraints ::= SEQUENCE { requireExplicitPolicy [0] SkipCerts OPTIONAL, inhibitPolicyMapping [1] SkipCerts OPTIONAL } SkipCerts ::= INTEGER (0..MAX) If the inhibitPolicyMapping field is present, the value indicates the number of additional certificates that may appear in the path (including the trustpoint's self certificate) before policy mapping is no longer permitted. For example, a value of one indicates that policy mapping may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path. If the requireExplicitPolicy field is present, subsequent certificates must include an acceptable policy identifier. The value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path (including the trustpoint's self certificate) before an explicit policy is required. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping. 7.2. Revocation Requirements The RevocRequirements specifies minimum requirements for revocation information, obtained through CRLs, delta-CRLs or OCSP responses, to be used in checking the revocation status of certificates. This ASN1 structure is used to define policy for validating the certificate. RevocRequirements ::= SEQUENCE { endCertRevReq RevReq, caCerts RevReq } Certificate revocation requirements are specified in terms of checks required on: * endCertRevReq: end certificates (i.e. the signers certificate, the attribute certificate or the timestamping authority certificate). * caCerts: CA certificates. RevReq ::= BIT STRING { crlCheck (0), ocspCheck (1), deltaCrlCheck (2) } Bits in RevReq are used as follows: The crlCheck bit is asserted when checks are to be done against full CRLs (or full Authority revocation lists). The ocspCheck bit is asserted when the revocation status check is to be done using the OCSP protocol (i.e. RFC 2560). Pinkas [Page 17] Internet Draft DPV&DPD July 2001 The deltaCrlCheck bit is asserted when checks are to be done against delta CRLs and relevant associated full CRLs (or full Authority revocation lists). When more than one bit is set, then any of the indicated sources of revocation information MUST be used. When a single bit is set, then the indicated source of revocation information MUST be used. When no bit is set, then no revocation status check SHALL be done. 7.3. Time-Stamping requirements The TimeStampingRequirements identifies the number of time stamps to be used over the references from the path and the name of the TSAs to be used. TimeStampingRequirements ::= SEQUENCE OF GeneralName 8. Validation policy definition protocol In order to validate a certificate, it is needed to refer to a validation policy through an OID or a URI. This reference can be temporary defined by the requester. This protocol allows to define a validation policy. It is up to server to decide how long a temporary defined validation policy should be kept in memory. 8.1. Request The ASN.1 construct for the request is as follows: VPDefRequest ::= SEQUENCE { tbsRequest TbsVPDefRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TbsVPDefRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, valPolicyId ValPolicyID, valPolicyDef ValPolicyDef, requestExtensions [2] EXPLICIT Extensions OPTIONAL } 8.2. Response The ASN.1 construct for the response is as follows: VPDefResponse ::= SEQUENCE { vPDefStatus VPDefResponseStatus, tbsResponse TbsVPDefResponse OPTIONAL } VPDefResponseStatus ::= ENUMERATED { successful (0), -- Request was understood malformedRequest (1), -- malformed request Pinkas [Page 18] Internet Draft DPV&DPD July 2001 internalError (2), -- internal error in issuer tryLater (3), -- try again later -- (4) is not used sigRequired (5), -- must sign the request unauthorized (6) -- request unauthorized } TbsDefResponse ::= SEQUENCE { tbsResponseData VPDefResponseData, signatureAlgorithm AlgorithmIdentifier OPTIONAL, signature BIT STRING OPTIONAL, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } The value for signature SHALL be computed on the hash of the DER encoding of VPDefResponseData. VPDefResponseData :: = SEQUENCE { responseStatus VPDefResponseStatus, validationPolicyRef ValidationPolicyRef OPTIONAL } vPDefResponseStatus ::= CHOICE { registered [0] IMPLICIT NULL, notregistered [1] IMPLICIT NULL } When both the request is understood (i.e. there is no syntax error) and the validation policy can be correctly interpreted (i.e. there is no semantic error) then a validation policy reference is returned. The identifier of the policy may be specific to the request or may be an identifier that has already been attributed as the result of a previous request with an identical definition. 9. Security considerations To be provided. 10. Acknowledgments To be provided. 11. References [PKIX-1] Internet X.509 Public Key Infrastructure. Certificate and CRL Profile. RFC 2459 R. Housley, W. Ford, W. Polk, D. Solo. or its successor as soon as it can be referenced. Pinkas [Page 19] Internet Draft DPV&DPD July 2001 [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 YYYY 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 (to be published). [CMS] Cryptographic Message Syntax. RFC 2630. R. Housley June 1999. [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 1997 edition, use 1993 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1996.) 12. Authors' addresses Denis Pinkas Integris, Bull. 68, Route de Versailles 78434 Louveciennes CEDEX 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 Pinkas [Page 20] Internet Draft DPV&DPD July 2001 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 21] Internet Draft DPV&DPD July 2001 Annex A (normative): ASN.1 Definitions To be provided. Pinkas [Page 22]