3.  Validation Request

   An SCVP client request to the server MUST be a single CVRequest item.
   When a CVRequest is encapsulated in a MIME body part,
   application/scvp-cv-request MUST be used.  There are two forms of
   SCVP request: unprotected and protected.  A protected request is used
   to authenticate the client to the server or to provide anonymous
   client integrity over the request-response pair.  The protection is
   provided by a digital signature or message authentication code (MAC).
   In the later case, the MAC key is derived using a key agreement
   algorithm, such as Diffie-Hellman.  If the client's public key is
   contained in a certificate, then it may be used to authenticate the
   client.  More commonly, the client's key agreement public key will be
   ephemeral, supporting anonymous client integrity.

   A server MAY require all requests to be protected, and a server MAY
   discard all unprotected requests.  Alternatively, a server MAY choose
   to process unprotected requests.

   The unprotected request consists of a CVRequest encapsulated in a
   Cryptographic Message Syntax (CMS) ContentInfo [CMS].  An overview of
   this structure is provided below and is only intended as

   illustrative.  The definitive ASN.1 is found in [CMS].  Many details
   are not shown, but the way that SCVP makes use of CMS is clearly
   illustrated.

      ContentInfo {
        contentType        id-ct-scvp-certValRequest,
                                     -- (1.2.840.113549.1.9.16.1.10)
        content            CVRequest }

   The protected request consists of a CVRequest encapsulated in either
   a SignedData or AuthenticatedData, which is in turn encapsulated in a
   ContentInfo.  That is, the EncapsulatedContentInfo field of either
   SignedData or AuthenticatedData consists of an eContentType field
   with a value of id-ct-scvp-certValRequest and an eContent field that
   contains a Distinguished Encoding Rules (DER)-encoded CVRequest.
   SignedData is used when the request is digitally signed.
   AuthenticatedData is used with a message authentication code (MAC).

   All SCVP clients and servers MUST support SignedData for signed
   requests and responses.  SCVP clients and servers SHOULD support
   AuthenticatedData for MAC-protected requests and responses.

   If the client uses SignedData, it MUST have a public key that has
   been bound to a subject identity by a certificate that conforms to
   the PKIX profile [PKIX-1], and that certificate MUST be suitable for
   signing the SCVP request.  That is:

      1. If the key usage extension is present, either the digital
         signature or the non-repudiation bit MUST be asserted.

      2. If the extended key usage extension is present, it MUST contain
         either the SCVP client OID (see Section 3.11), the
         anyExtendedKeyUsage OID, or another OID acceptable to the SCVP
         server.

   The client MUST put an unambiguous reference to its certificate in
   the SignedData that encapsulates the request.  The client SHOULD
   include its certificate in the request, but MAY omit the certificate
   to reduce the size of the request.  The client MAY include other
   certificates in the request to aid the validation of its certificates
   by the SCVP server.  The signerInfos field of SignedData MUST include
   exactly one SignerInfo.  The SignedData MUST NOT include the
   unsignedAttrs field.

   The client MUST put its key agreement public key, or an unambiguous
   reference to a certificate that contains its key agreement public
   key, in the AuthenticatedData that encapsulates the request.  If an
   ephemeral key agreement key pair is used, then the ephemeral key
   agreement public key is carried in the originatorKey field of
   KeyAgreeRecipientInfo, which requires the client to obtain the
   server's key agreement public key before computing the message
   authentication code (MAC).  An SCVP server's key agreement key is
   included in its validation policy response message (see Section 6).
   The recipientInfos field of AuthenticatedData MUST include exactly
   one RecipientInfo, which contains information for the SCVP server.
   The AuthenticatedData MUST NOT include the unauthAttrs field.

   The syntax and semantics for SignedData, AuthenticatedData, and
   ContentInfo are defined in [CMS].  The syntax and semantics for
   CVRequest are defined below.  The CVRequest item contains the client
   request.  The CVRequest contains the cvRequestVersion and query
   items; the CVRequest MAY also contain the requestorRef, requestNonce,
   requestorName, responderName, requestExtensions, signatureAlg, and
   hashAlg items.

   The CVRequest MUST have the following syntax:

      CVRequest ::= SEQUENCE {
        cvRequestVersion        INTEGER DEFAULT 1,
        query                   Query,
        requestorRef        [0] GeneralNames OPTIONAL,
        requestNonce        [1] OCTET STRING OPTIONAL,
        requestorName       [2] GeneralName OPTIONAL,
        responderName       [3] GeneralName OPTIONAL,
        requestExtensions   [4] Extensions OPTIONAL,
        signatureAlg        [5] AlgorithmIdentifier OPTIONAL,
        hashAlg             [6] OBJECT IDENTIFIER OPTIONAL,
        requestorText       [7] UTF8String (SIZE (1..256)) OPTIONAL }

   Conforming clients MUST be able to construct requests with
   cvRequestVersion and query.  Conforming clients MUST DER encode the
   CVRequest in both protected and unprotected messages to facilitate
   unambiguous hash-based referencing in the corresponding response
   message.  SCVP clients that insist on creation of a fresh response
   (e.g., to protect against a replay attack or ensure information is up
   to date) MUST support requestNonce.  Support for the remaining items
   is optional in client implementations.

   Conforming servers MUST be able to parse CVRequests that contain any
   or all of the optional items.

   Each of the items within the CVRequest is described in the following
   sections.

3.1.  cvRequestVersion

   The cvRequestVersion item defines the version of the SCVP CVRequest
   used in a request.  The subsequent response MUST use the same version
   number.  The value of the cvRequestVersion item MUST be one (1) for a
   client implementing this specification.  Future updates to this
   specification must specify other values if there are any changes to
   syntax or semantics.  However, new extensions may be defined without
   changing the version number.

   SCVP clients MUST support asserting this value and SCVP servers MUST
   be capable of processing this value.

3.2.  query

   The query item specifies one or more certificates that are the
   subject of the request; the certificates can be either public key
   certificates [PKIX-1] or attribute certificates [PKIX-AC].  A query
   MUST contain a queriedCerts item as well as one checks item, and one
   validationPolicy item; a query MAY also contain wantBack,
   responseFlags, serverContextInfo, validationTime, intermediateCerts,
   revInfos, producedAt, and queryExtensions items.

   A Query MUST have the following syntax:

      Query ::= SEQUENCE {
        queriedCerts            CertReferences,
        checks                  CertChecks,
         -- Note: tag [0] not used --
        wantBack            [1] WantBack OPTIONAL,
        validationPolicy        ValidationPolicy,
        responseFlags           ResponseFlags OPTIONAL,
        serverContextInfo   [2] OCTET STRING OPTIONAL,
        validationTime      [3] GeneralizedTime OPTIONAL,
        intermediateCerts   [4] CertBundle OPTIONAL,
        revInfos            [5] RevocationInfos OPTIONAL,
        producedAt          [6] GeneralizedTime OPTIONAL,
        queryExtensions     [7] Extensions OPTIONAL }

   The list of certificate references in the queriedCerts item tells the
   server the certificate(s) for which the client wants information.
   The checks item specifies the checking that the client wants
   performed.  The wantBack item specifies the objects that the client
   wants the server to return in the response.  The validationPolicy
   item specifies the validation policy that the client wants the server

   to employ.  The responseFlags item allows the client to request
   optional features for the response.  The serverContextInfo item tells
   the server that additional information from a previous request-
   response is desired.  The validationTime item tells the date and time
   relative to which the client wants the server to perform the checks.
   The intermediateCerts and revInfos items provide context for the
   client request.  The queryExtensions item provides for future
   expansion of the query syntax.  The syntax and semantics of each of
   these items are discussed in the following sections.

   Conforming clients MUST be able to construct a Query with a
   queriedCerts item that specifies at least one certificate, checks,
   and validationPolicy.  Conforming SCVP clients MAY support
   specification of multiple certificates and MAY support the optional
   items in the Query structure.

   SCVP clients that support delegated path discovery (DPD) as defined
   in [RQMTS] MUST support wantBack and responseFlags.  SCVP clients
   that insist on creation of a fresh response (e.g., to protect against
   a replay attack or ensure information is up to date) MUST support
   responseFlags.

   Conforming servers MUST be able to process a Query that contains any
   of the optional items, and MUST be able to process a Query that
   specifies multiple certificates.

3.2.1.  queriedCerts

   The queriedCerts item is a SEQUENCE of one or more certificates, each
   of which is a subject of the request.  The specified certificates are
   either public key certificates or attribute certificates; if more
   than one certificate is specified, all must be of the same type.
   Each certificate is either directly included, or it is referenced.
   When referenced, a hash value of the referenced item is included to
   ensure that the SCVP client and the SCVP server both obtain the same
   certificate when the referenced certificate is fetched.  Certificate
   references use the SCVPCertID type, which is described below.  A
   single request MAY contain both directly included and referenced
   certificates.

   CertReferences has the following syntax:

   CertReferences ::= CHOICE {
     pkcRefs     [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
     acRefs      [1] SEQUENCE SIZE (1..MAX) OF ACReference }

   PKCReference ::= CHOICE {
     cert        [0] Certificate,
     pkcRef      [1] SCVPCertID }

   ACReference ::= CHOICE {
     attrCert    [2] AttributeCertificate,
     acRef       [3] SCVPCertID }

   SCVPCertID ::= SEQUENCE {
     certHash        OCTET STRING,
     issuerSerial    SCVPIssuerSerial,
     hashAlgorithm   AlgorithmIdentifier DEFAULT { algorithm sha-1 } }

   The ASN.1 definition of Certificate is imported from [PKIX-1] and the
   definition of AttributeCertificate is imported from [PKIX-AC].

   When creating a SCVPCertID, the certHash is computed over the entire
   DER-encoded certificate including the signature.  The hash algorithm
   used to compute certHash is specified in hashAlgorithm.  The hash
   algorithm used to compute certHash SHOULD be one of the hash
   algorithms specified in the hashAlgorithms item of the server's
   validation policy response message.

   When encoding SCVPIssuerSerial, serialNumber is the serial number
   that uniquely identifies the certificate.  For public key
   certificates, the issuer MUST contain only the issuer name from the
   certificate encoded in the directoryName choice of GeneralNames.  For
   attribute certificates, the issuer MUST contain the issuer name field
   from the attribute certificate.

   Conforming clients MUST be able to reference a certificate by direct
   inclusion.  Clients SHOULD be able to specify a certificate using the
   SCVPCertID.  Conforming clients MAY be able to reference multiple
   certificates and MAY be able to reference both public key and
   attribute certificates.

   Conforming SCVP Server implementations MUST be able to process
   CertReferences with multiple certificates.  Conforming SCVP server
   implementations MUST be able to parse CertReferences that contain
   either public key or attribute certificates.  Conforming SCVP server
   implementations MUST be able to parse both the cert and pkcRef
   choices in PKCReference.  Conforming SCVP server implementations that
   process attribute certificates MUST be able to parse both the
   attrCert and acRef choices in ACReference.

3.2.2.  checks

   The checks item describes the checking that the SCVP client wants the
   SCVP server to perform on the certificate(s) in the queriedCerts
   item.  The checks item contains a sequence of object identifiers
   (OIDs).  Each OID tells the SCVP server what checking the client
   expects the server to perform.  For each check specified in the
   request, the SCVP server MUST perform the requested check, or return
   an error.  A server may choose to perform additional checks (e.g., a
   server that is only asked to build a validated certification path may
   choose to also perform revocation status checks), although the server
   cannot indicate in the response that the additional checks have been
   performed, except in the case of an error response.

   The checks item uses the CertChecks type, which has the following
   syntax:

      CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

   For public key certificates, the following checks are defined in this
   document:

   -  id-stc-build-pkc-path: Build a prospective certification path to a
      trust anchor (as defined in Section 6.1 of [PKIX-1]);

   -  id-stc-build-valid-pkc-path: Build a validated certification path
      to a trust anchor (revocation checking not required);

   -  id-stc-build-status-checked-pkc-path: Build a validated
      certification path to a trust anchor and perform revocation status
      checks on the certification path.

   Conforming SCVP server implementations that support delegated path
   discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build-
   pkc-path check.  Conforming SCVP server implementations that support
   delegated path validation (DPV) as defined in [RQMTS] MUST support
   the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
   path checks.

   For attribute certificates, the following checks are defined in this
   document:

   -  id-stc-build-aa-path: Build a prospective certification path to a
      trust anchor for the Attribute Certificate (AC) issuer;

   -  id-stc-build-valid-aa-path: Build a validated certification path
      to a trust anchor for the AC issuer;

   -  id-stc-build-status-checked-aa-path: Build a validated
      certification path to a trust anchor for the AC issuer and perform
      revocation status checks on the certification path for the AC
      issuer;

   -  id-stc-status-check-ac-and-build-status-checked-aa-path: Build a
      validated certification path to a trust anchor for the AC issuer
      and perform revocation status checks on the AC as well as the
      certification path for the AC issuer.

   Conforming SCVP server implementations MAY support the attribute
   certificates checks.

   For these purposes, the following OIDs are defined:

      id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
              dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }

      id-stc-build-pkc-path         OBJECT IDENTIFIER ::= { id-stc 1 }
      id-stc-build-valid-pkc-path   OBJECT IDENTIFIER ::= { id-stc 2 }
      id-stc-build-status-checked-pkc-path
                                    OBJECT IDENTIFIER ::= { id-stc 3 }
      id-stc-build-aa-path          OBJECT IDENTIFIER ::= { id-stc 4 }
      id-stc-build-valid-aa-path    OBJECT IDENTIFIER ::= { id-stc 5 }
      id-stc-build-status-checked-aa-path
                                    OBJECT IDENTIFIER ::= { id-stc 6 }
      id-stc-status-check-ac-and-build-status-checked-aa-path
                                    OBJECT IDENTIFIER ::= { id-stc 7 }

   Other specifications may define additional checks.

   Conforming client implementations MUST support assertion of at least
   one of the standard checks.  Conforming clients MAY support assertion
   of multiple checks.  Conforming clients need not support all of the
   checks defined in this section.

3.2.3.  wantBack

   The optional wantBack item describes any information the SCVP client
   wants from the SCVP server for the certificate(s) in the queriedCerts
   item in addition to the results of the checks specified in the checks
   item.  If present, the wantBack item MUST contain a sequence of
   object identifiers (OIDs).  Each OID tells the SCVP server what the
   client wants to know about the queriedCerts item.  For each type of
   information specified in the request, the server MUST return
   information regarding its finding (in a successful response).

   For example, a request might include a checks item that only
   specifies certification path building and include a wantBack item
   that requests the return of the certification path built by the
   server.  In this case, the response would not include a status for
   the validation of the certification path, but it would include a
   prospective certification path.  A client that wants to perform its
   own certification path validation might use a request of this form.

   Alternatively, a request might include a checks item that requests
   the server to build a certification path and validate it, including
   revocation checking, and not include a wantBack item.  In this case,
   the response would include only a status for the validation of the
   certification path.  A client that completely delegates certification
   path validation might use a request of this form.

   The wantBack item uses the WantBack type, which has the following
   syntax:

      WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

   For public key certificates, the following wantBacks are defined in
   this document:

   -  id-swb-pkc-cert: The certificate that was the subject of the
      request;

   -  id-swb-pkc-best-cert-path: The certification path built for the
      certificate including the certificate that was validated;

   -  id-swb-pkc-revocation-info: Proof of revocation status for each
      certificate in the certification path;

   -  id-swb-pkc-public-key-info: The public key from the certificate
      that was the subject of the request;

   -  id-swb-pkc-all-cert-paths: A set of certification paths for the
      certificate that was the subject of the request;

   -  id-swb-pkc-ee-revocation-info: Proof of revocation status for the
      end entity certificate in the certification path; and

   -  id-swb-pkc-CAs-revocation-info: Proof of revocation status for
      each CA certificate in the certification path.

   All conforming SCVP server implementations MUST support the id-swb-
   pkc-cert and id-swb-pkc-public-key-info wantBacks.  Conforming SCVP
   server implementations that support delegated path discovery (DPD) as
   defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and id-
   swb-pkc-revocation-info wantBacks.

   SCVP provides two methods for a client to obtain multiple
   certification paths for a certificate.  The client could use
   serverContextInfo to request one path at a time (see Section 3.2.6).
   After obtaining each path, the client could submit the
   serverContextInfo from the previous request to obtain another path
   until either the client found a suitable path or the server indicated
   (by not returning a serverContextInfo) that no more paths were
   available.  Alternatively, the client could send a single request
   with an id-swb-pkc-all-cert-paths wantBack, in which case the server
   would return all of the available paths in a single response.

   The server may, at its discretion, limit the number of paths that it
   returns in response to the id-swb-pkc-all-cert-paths.  When the
   request includes an id-swb-pkc-all-cert-paths wantBack, the response
   SHOULD NOT include a serverContextInfo.

   For attribute certificates, the following wantBacks are defined in
   this document:

   -  id-swb-ac-cert: The attribute certificate that was the subject of
      the request;

   -  id-swb-aa-cert-path: The certification path built for the AC
      issuer certificate;

   -  id-swb-ac-revocation-info: Proof of revocation status for each
      certificate in the AC issuer certification path; and

   -  id-swb-aa-revocation-info: Proof of revocation status for the
      attribute certificate.

   Conforming SCVP server implementations MAY support the attribute
   certificate wantBacks.

   The following wantBack can be used for either public key or attribute
   certificates:

   -  id-swb-relayed-responses: Any SCVP responses received by the
      server that were used to generate the response to this query.

   Conforming SCVP servers MAY support the id-swb-relayed-responses
   wantBack.

   For these purposes, the following OIDs are defined:

      id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
              dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }

      id-swb-pkc-best-cert-path      OBJECT IDENTIFIER ::= { id-swb 1 }
      id-swb-pkc-revocation-info     OBJECT IDENTIFIER ::= { id-swb 2 }
      id-swb-pkc-public-key-info     OBJECT IDENTIFIER ::= { id-swb 4 }
      id-swb-aa-cert-path            OBJECT IDENTIFIER ::= { id-swb 5 }
      id-swb-aa-revocation-info      OBJECT IDENTIFIER ::= { id-swb 6 }
      id-swb-ac-revocation-info      OBJECT IDENTIFIER ::= { id-swb 7 }
      id-swb-relayed-responses       OBJECT IDENTIFIER ::= { id-swb 9 }
      id-swb-pkc-cert                OBJECT IDENTIFIER ::= { id-swb 10}
      id-swb-ac-cert                 OBJECT IDENTIFIER ::= { id-swb 11}
      id-swb-pkc-all-cert-paths      OBJECT IDENTIFIER ::= { id-swb 12}
      id-swb-pkc-ee-revocation-info  OBJECT IDENTIFIER ::= { id-swb 13}
      id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14}

   Other specifications may define additional wantBacks.

   Conforming client implementations that support delegated path
   validation (DPV) as defined in [RQMTS] SHOULD support assertion of at
   least one wantBack.  Conforming client implementations that support
   delegated path discovery (DPD) as defined in [RQMTS] MUST support
   assertion of at least one wantBack.  Conforming clients MAY support
   assertion of multiple wantBacks.  Conforming clients need not support
   all of the wantBacks defined in this section.

3.2.4.  validationPolicy

   The validationPolicy item defines the validation policy that the
   client wants the SCVP server to use during certificate validation.
   If this policy cannot be used for any reason, then the server MUST
   return an error response.

   A validation policy MUST define default values for all parameters
   necessary for processing an SCVP request.  For each parameter, a
   validation policy may either allow the client to specify a non-
   default value or forbid the use of a non-default value.  If the
   client wishes to use the default values for all of the parameters,
   then the client need only supply a reference to the policy in this
   item.  If the client wishes to use non-default values for one or more
   parameters, then the client supplies a reference to the policy plus
   whatever parameters are necessary to complete the request in this
   item.  If there are any conflicts between the policy referenced in
   the request and any supplied parameter values in the request, then
   the server MUST return an error response.

   The syntax of the validationPolicy item is:

      ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        validationAlg         [0] ValidationAlg OPTIONAL,
        userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                    IDENTIFIER OPTIONAL,
        inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
        requireExplicitPolicy [3] BOOLEAN OPTIONAL,
        inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
        trustAnchors          [5] TrustAnchors OPTIONAL,
        keyUsages             [6] SEQUENCE OF KeyUsage OPTIONAL,
        extendedKeyUsages     [7] SEQUENCE OF KeyPurposeId OPTIONAL,
        specifiedKeyUsages    [8] SEQUENCE OF KeyPurposeId OPTIONAL }

   The validationPolRef item is required, but the remaining items are
   optional.  The optional items are used to provide validation policy
   parameters.  When the client uses the validation policy's default
   values for all parameters, all of the optional items are absent.

   At a minimum, conforming SCVP client implementations MUST support the
   validationPolRef item.  Conforming client implementations MAY support
   any or all of the optional items in ValidationPolicy.

   Conforming SCVP servers MUST support processing of a ValidationPolicy
   that contains any or all of the optional items.

   The validationAlg item specifies the validation algorithm.  The
   userPolicySet item provides an acceptable set of certificate
   policies.  The inhibitPolicyMapping item inhibits certificate policy
   mapping during certification path validation.  The
   requireExplicitPolicy item requires at least one valid certificate
   policy in the certificate policies extension.  The inhibitAnyPolicy
   item indicates whether the anyPolicy certificate policy OID is
   processed or ignored when evaluating certificate policy.  The
   trustAnchors item indicates the trust anchors that are acceptable to
   the client.  The keyUsages item indicates the technical usage of the
   public key that is to be confirmed by the server as acceptable.  The
   extendedKeyUsages item indicates the application-specific usage of
   the public key that is to be confirmed by the server as acceptable.
   The syntax and semantics of each of these items are discussed in the
   following sections.

3.2.4.1.  validationPolRef

   The reference to the validation policy is an OID that the client and
   server have agreed represents a particular validation policy.

   The syntax of the validationPolRef item is:

      ValidationPolRef::= SEQUENCE {
        valPolId              OBJECT IDENTIFIER,
        valPolParams          ANY DEFINED BY valPolId OPTIONAL }

   Where a validation policy supports additional policy-specific
   parameter settings, these values are specified using the valPolParams
   item.  The syntax and semantics of the parameters structure are
   defined by the object identifier encoded as the valPolId.  Where a
   validation policy has no parameters, such as the default validation
   policy (see Section 3.2.4.1.1), this item MUST be omitted.

   Parameters specified in this item are independent of the validation
   algorithm and the validation algorithm's parameters (see Section
   3.2.4.2).  For example, a server may support a validation policy
   where it validates a certificate using the name validation algorithm
   and also makes a determination regarding the creditworthiness of the
   subject.  In this case, the validation policy parameters could be
   used to specify the value of the transaction.  The validation
   algorithm parameters are used to specify the application identifier
   and name for the name validation algorithm.

   Conforming SCVP client implementations MUST support specification of
   a validation policy.  Conforming SCVP client implementations MAY be
   able to specify parameters for a validation policy.  Conforming SCVP
   server implementations MUST be able to process valPolId and MAY be
   able to process valPolParams.

3.2.4.1.1.  Default Validation Policy

   The client can request the SCVP server's default validation policy or
   another validation policy.  The default validation policy corresponds
   to standard certification path processing as defined in [PKIX-1] with
   server-chosen default values (e.g., with a server-determined policy
   set and trust anchors).  The default values can be distributed out of
   band or using the policy request mechanism (see Section 5).  This
   mechanism permits the deployment of an SCVP server without obtaining
   a new object identifier.

   The object identifier that identifies the default validation policy
   is:

      id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }

      id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }

   The default validation policy MUST use the basic validation algorithm
   as its default validation algorithm (see Section 3.2.4.2.1), and has
   no validation policy parameters (see Section 3.2.4.1).

   When using the default validation policy, the client can override any
   of the default parameter values by supplying a specific value in the
   request.  The SCVP server MUST make use of the provided parameter
   values or return an error response.

   Conforming implementations of SCVP servers MUST support the default
   policy.  However, an SCVP server may be configured to send an error
   response to all requests using the default policy to meet local
   security requirements.

3.2.4.2.  validationAlg

   The optional validationAlg item defines the validation algorithm to
   be used by the SCVP server during certificate validation.  The value
   of this item can be determined by agreement between the client and
   the server.  The validation algorithm is represented by an object
   identifier.

   The syntax of the validationAlg item is:

      ValidationAlg ::= SEQUENCE {
        valAlgId              OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valAlgId OPTIONAL }

   The following section specifies the basic validation algorithm and
   the name validation algorithm.

   SCVP servers MUST recognize and support both validation algorithms
   defined in this section.  SCVP clients that support explicit
   assertion of the validation algorithm MUST support the basic
   validation algorithm and SHOULD support the name validation
   algorithm.  Other validation algorithms can be specified in other
   documents for use with specific applications.  SCVP clients and
   servers MAY support any such validation algorithms.

3.2.4.2.1.  Basic Validation Algorithm

   The client can request use of the SCVP basic validation algorithm or
   another algorithm.  For identity certificates, the basic validation
   algorithm MUST implement the certification path validation algorithm
   as defined in Section 6 of [PKIX-1].  For attribute certificates, the
   basic validation algorithm MUST implement certification path
   validation as defined in Section 5 of [PKIX-AC].  Other validation
   algorithms MAY implement functions over and above those in the basic

   algorithm, but validation algorithms MUST generate results compliant
   with the basic validation algorithm.  That is, none of the validation
   requirements in the basic algorithm may be omitted from any newly
   defined validation algorithms.  However, other validation algorithms
   MAY reject paths that are valid using the basic validation algorithm.
   The object identifier to identify the basic validation algorithm is:

      id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }

   When id-svp-basicValAlg appears in valAlgId, the parameters item MUST
   be absent.

3.2.4.2.2.  Basic Validation Algorithm Errors

   The following errors are defined for the basic validation algorithm
   for inclusion in the validationErrors item in the response (see
   Section 4.9.6).  These errors can be used by any other validation
   algorithm since all validation algorithms MUST implement the
   functionality of the basic validation algorithm.

      id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg

      id-bvae-expired              OBJECT IDENTIFIER ::= { id-bvae 1 }
      id-bvae-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 }
      id-bvae-wrongTrustAnchor     OBJECT IDENTIFIER ::= { id-bvae 3 }
      id-bvae-noValidCertPath      OBJECT IDENTIFIER ::= { id-bvae 4 }
      id-bvae-revoked              OBJECT IDENTIFIER ::= { id-bvae 5 }
      id-bvae-invalidKeyPurpose    OBJECT IDENTIFIER ::= { id-bvae 9 }
      id-bvae-invalidKeyUsage      OBJECT IDENTIFIER ::= { id-bvae 10 }
      id-bvae-invalidCertPolicy    OBJECT IDENTIFIER ::= { id-bvae 11 }

   The id-bvae-expired value means that the validation time used for the
   request was later than the notAfter time in the end certificate (the
   certificate specified in the queriedCerts item).

   The id-bvae-not-yet-valid value means that the validation time used
   for the request was before the notBefore time in the end certificate.

   The id-bvae-wrongTrustAnchor value means that a certification path
   could not be constructed for the client-specified trust anchor(s),
   but a path exists for one of the trust anchors specified in the
   server's default validation policy.

   The id-bvae-noValidCertPath value means that the server could not
   construct a sequence of intermediate certificates between the trust
   anchor and the target certificate that satisfied the request.

   The id-bvae-revoked value means that the end certificate has been
   revoked.

   The id-bvae-invalidKeyPurpose value means that the extended key usage
   extension ([PKIX-1], Section 4.2.1.13) in the end certificate does
   not satisfy the validation policy.

   The id-bvae-invalidKeyUsage value means that the keyUsage extension
   ([PKIX-1], Section 4.2.1.3) in the end certificate does not satisfy
   the validation policy.  For example, the keyUsage extension in the
   certificate may assert only the keyEncipherment bit, but the
   validation policy specifies in the keyUsages item that
   digitalSignature is required.

   The id-bvae-invalidCertPolicy value means that the path is not valid
   under any of the policies specified in the user policy set and
   explicit policies are required.  That is, the valid_policy_tree is
   NULL and the explicit_policy variable is zero ([PKIX-1], Section
   6.1.5).

3.2.4.2.3.  Name Validation Algorithm

   The name validation algorithm allows the client to specify one or
   more subject names that MUST appear in the end certificate in
   addition to the requirements specified for the basic validation
   algorithm.  The name validation algorithm allows the client to supply
   an application identifier and a name to the server.  The application
   identifier defines the name matching rules to use in comparing the
   name supplied in the request with the names in the certificate.

      id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }

   When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST
   use the NameValidationAlgParms syntax:

      NameValidationAlgParms ::= SEQUENCE {
        nameCompAlgId     OBJECT IDENTIFIER,
        validationNames   GeneralNames }

   GeneralNames is defined in [PKIX-1].

   If more than one name is supplied in the validationNames value, all
   names MUST be of the same type.  The certificate must contain a
   matching name for each of the names supplied in validationNames
   according to the name matching rules associated with the
   nameCompAlgId.  This specification defines three sets of name
   matching rules.

   If the nameCompAlgId supplied in the request is id-nva-dnCompAlg,
   then GeneralNames supplied in the request MUST be a directoryName,
   and the matching rules to be used are defined in [PKIX-1].  The
   certificate must contain a matching name in either the subject field
   or a directoryName in the subjectAltName extension.  This
   specification defines the OID for id-nva-dnCompAlg as follows:

      id-nva-dnCompAlg   OBJECT IDENTIFIER ::= { id-svp 4 }

   If the nameCompAlgId supplied in the request is id-kp-serverAuth
   [PKIX-1], then GeneralNames supplied in the request MUST be a
   dNSName, and the matching rules to be used are defined in [PKIX-1].

   If a subjectAltName extension is present and includes one or more
   names of type dNSName, a match in any one of the set is considered
   acceptable.  If the subjectAltName extension is omitted, or does not
   include any names of type dNSName, the (most specific) Common Name
   field in the subject field of the certificate MUST be used.

   Names may contain the wildcard character *, which is considered to
   match any single domain name component.  That is, *.a.com matches
   foo.a.com but not bar.foo.a.com.

   If the nameCompAlgId supplied in the request is id-kp-mailProtection
   [PKIX-1], then GeneralNames supplied in the request MUST be an
   rfc822Name, and the matching rules are defined in [SMIME-CERT].

   Conforming SCVP servers MUST support the name validation algorithm
   and the matching rules associated with id-nva-dnCompAlg, id-kp-
   serverAuth, and id-kp-mailProtection.  SCVP servers MAY support other
   name matching rules.

3.2.4.2.4.  Name Validation Algorithm Errors

   The following errors are defined for the name validation algorithm:

      id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg

      id-nvae-name-mismatch    OBJECT IDENTIFIER ::= { id-nvae 1 }
      id-nvae-no-name          OBJECT IDENTIFIER ::= { id-nvae 2 }
      id-nvae-unknown-alg      OBJECT IDENTIFIER ::= { id-nvae 3 }
      id-nvae-bad-name         OBJECT IDENTIFIER ::= { id-nvae 4 }
      id-nvae-bad-name-type    OBJECT IDENTIFIER ::= { id-nvae 5 }
      id-nvae-mixed-names      OBJECT IDENTIFIER ::= { id-nvae 6 }

   The id-nvae-name-mismatch value means the client supplied a name with
   the request, which the server recognized and the server found a
   corresponding name type in the certificate, but was unable to find a

   match to the name supplied.  For example, the client supplied a DNS
   name of example1.com, and the certificate contained a DNS name of
   example.com.

   The id-nvae-no-name value means the client supplied a name with the
   request, which the server recognized, but the server could not find
   the corresponding name type in the certificate.  For example, the
   client supplied a DNS name of example1.com, and the certificate only
   contained a rfc822Name of user@example.com.

   The id-nvae-unknown-alg value means the client supplied a
   nameCompAlgId that the server does not recognize.

   The id-nvae-bad-name value means the client supplied either an empty
   or malformed name in the request.

   The id-nvae-bad-name-type value means the client supplied an
   inappropriate name type for the application identifier.  For example,
   the client specified a nameCompAlgId of id-kp-serverAuth, and an
   rfc822Name of user@example.com.

   The id-nvae-mixed-names value means the client supplied multiple
   names in the request of different types.

3.2.4.3.  userPolicySet

   The userPolicySet item specifies a list of certificate policy
   identifiers that the SCVP server MUST use when constructing and
   validating a certification path.  The userPolicySet item specifies
   the user-initial-policy-set as defined in Section 6 of [PKIX-1].  A
   userPolicySet containing the anyPolicy OID indicates a user-initial-
   policy-set of any-policy.

   SCVP clients SHOULD support the userPolicySet item in requests, and
   SCVP servers MUST support the userPolicySet item in requests.

3.2.4.4.  inhibitPolicyMapping

   The inhibitPolicyMapping item specifies an input to the certification
   path validation algorithm, and it controls whether policy mapping is
   allowed during certification path validation (see [PKIX-1], Section
   6.1.1).  If the client wants the server to inhibit policy mapping,
   inhibitPolicyMapping is set to TRUE in the request.  SCVP clients MAY
   support inhibiting policy mapping.  SCVP servers SHOULD support
   inhibiting policy mapping.

3.2.4.5.  requireExplicitPolicy

   The requireExplicitPolicy item specifies an input to the
   certification path validation algorithm, and it controls whether
   there must be at least one valid policy in the certificate policies
   extension (see [PKIX-1], Section 6.1.1).  If the client wants the
   server to require at least one policy, requireExplicitPolicy is set
   to TRUE in the request.

   SCVP clients MAY support requiring explicit policies.  SCVP servers
   SHOULD support requiring explicit policies.

3.2.4.6.  inhibitAnyPolicy

   The inhibitAnyPolicy item specifies an input to the certification
   path validation algorithm (see [PKIX-1], Section 6.1.1), and it
   controls whether the anyPolicy OID is processed or ignored when
   evaluating certificate policy.  If the client wants the server to
   ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in the
   request.

   SCVP clients MAY support ignoring the anyPolicy OID.  SCVP servers
   SHOULD support ignoring the anyPolicy OID.

3.2.4.7.  trustAnchors

   The trustAnchors item specifies the trust anchors at which the
   certification path must terminate if the path is to be considered
   valid by the SCVP server for the request.  If a trustAnchors item is
   present, the server MUST NOT consider any certification paths ending
   in other trust anchors as valid.

   The TrustAnchors type contains one or more trust anchor
   specifications.  A certificate reference can be used to identify the
   trust anchor by certificate hash and distinguished name with serial
   number.  Alternatively, trust anchors can be provided directly.  The
   order of trust anchor specifications within the sequence is not
   important.  Any CA certificate that meets the requirements of
   [PKIX-1] for signing certificates can be provided as a trust anchor.
   If a trust anchor is supplied that does not meet these requirements,
   the server MUST return an error response.

   The trust anchor itself, regardless of its form, MUST NOT be included
   in any certification path returned by the SCVP server.

   TrustAnchors has the following syntax:

      TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference

   SCVP servers MUST support trustAnchors.  SCVP clients SHOULD support
   trustAnchors.

3.2.4.8.  keyUsages

   The key usage extension ([PKIX-1], Section 4.2.1.3) in the
   certificate defines the technical purpose (such as encipherment,
   signature, and CRL signing) of the key contained in the certificate.
   If the client wishes to confirm the technical usage, then it can
   communicate the usage it wants to validate by the same structure
   using the same semantics as defined in [PKIX-1].  For example, if the
   client obtained the certificate in the context of a digital
   signature, it can confirm this use by including a keyUsage structure
   with the digital signature bit set.

   If the keyUsages item is present and contains an empty sequence, it
   indicates that the client does not require any particular key usage.

   If the keyUsages item contains one or more keyUsage definitions, then
   the certificate MUST satisfy at least one of the specified keyUsage
   definitions.  If the client is willing to accept multiple
   possibilities, then the client passes in a sequence of possible
   patterns.  Each keyUsage can contain a set of one or more bits set in
   the request, all bits MUST be set in the certificate to match against
   an instance of the keyUsage in the SCVP request.  The certificate key
   usage extension may contain more usages than requested.  For example,
   if a client wishes to check for either digital signature or non-
   repudiation, then the client provides two keyUsage values, one with
   digital signature set and the other with non-repudiation set.  If the
   key usage extension is absent from the certificate, the certificate
   MUST be considered good for all usages and therefore any pattern in
   the SCVP request will match.

   SCVP clients SHOULD support keyUsages, and SCVP servers MUST support
   keyUsages.

3.2.4.9.  extendedKeyUsages

   The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines
   more specific technical purposes, in addition to, or in place of, the
   purposes indicated in the key usage extension, for which the
   certified public key may be used.  If the client will accept
   certificates that are consistent with a particular value (or values)
   in the extended key usage extension, then it can communicate the
   appropriate usages using the same semantics as defined in [PKIX-1].

   For example, if the client obtained the certificate in the context of
   a Transport Layer Security (TLS) server, it can confirm the
   certificate is consistent with this usage by including the extended
   key usage structure with the id-kp-serverAuth object identifier.

   If the extension is absent, or is present and asserts the
   anyExtendedKeyUsage OID, then all usages specified in the request are
   a match.  If the extension is present and does not assert the
   anyExtendedKeyUsage OID, all usages in the request MUST be present in
   the certificate.  The certificate extension may contain more usages
   than requested.

   Where the client does not require any particular extended key usage,
   the client can specify an empty SEQUENCE.  This may be used to
   override extended key usage requirements imposed in the validation
   policy specified by valPolId.

   SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST
   support extendedKeyUsages.

3.2.4.10.  specifiedKeyUsages

   The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines
   more specific technical purposes, in addition to or in place of the
   purposes indicated in the key usage extension, for which the
   certified public key may be used.  If the client requires that a
   particular value (or values) appear in the extended key usage
   extension, then it can specify the required usage(s) using the same
   semantics as defined in [PKIX-1].  For example, if the client
   obtained the certificate in the context of a TLS server, it might
   require that the server certificate include the extended key usage
   structure with the id-kp-serverAuth object identifier.  In this case,
   the client would include a specifiedKeyUsages item in the request and
   assert the id-kp-serverAuth object identifier.

   If one or more specified usages are included in the request, the
   certificate MUST contain the extended key usage extension, and all
   usages specified in the request MUST be present in the certificate
   extension.  The certificate extension may contain more usages than
   specified in the request.  Specified key usages are not satisfied by
   the presence of the anyExtendedKeyUsage OID.

   Where the client does not require any particular extended key usage,
   the client can specify an empty SEQUENCE.  This may be used to
   override specified key usage requirements imposed in the validation
   policy specified by valPolId.

   SCVP clients SHOULD support specifiedKeyUsages, and SCVP servers MUST
   support specifiedKeyUsages.

3.2.5.  responseFlags

   The optional responseFlags item allows the client to indicate which
   optional features in the CVResponse it wants the server to include.
   If the default values for all of the flags are used, then the
   responseFlags item MUST NOT be included in the request.

   The syntax of the responseFlags item is:

      ResponseFlags ::= SEQUENCE {
        fullRequestInResponse      [0] BOOLEAN DEFAULT FALSE,
        responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
        protectResponse            [2] BOOLEAN DEFAULT TRUE,
        cachedResponse             [3] BOOLEAN DEFAULT TRUE }

   Each of the response flags is described in the following sections.

3.2.5.1.  fullRequestInResponse

   By default, the server includes a hash of the request in non-cached
   responses to allow the client to identify the response.  If the
   client wants the server to include the full request in the non-cached
   response, fullRequestInResponse is set to TRUE.  The main reason a
   client would request the server to include the full request in the
   response is to archive the request-response exchange in a single
   object.  That is, the client wants to archive a single object that
   includes both request and response.

   SCVP clients and servers MUST support the default behavior.  SCVP
   clients MAY support requesting and processing the full request.  SCVP
   servers SHOULD support returning the full request.

3.2.5.2.  responseValidationPolByRef

   The responseValidationPolByRef item controls whether the response
   includes just a reference to the policy or a reference to the policy
   plus all the parameters by value of the policy used to process the
   request.  The response MUST contain a reference to the validation
   policy.  If the client wants the validation policy parameters to be
   included by value also, then responseValidationPolByRef is set to
   FALSE.  The main reason a client would request the server to include
   validation policy to be included by value is to archive the request-
   response exchange in a single object.  That is, the client wants to
   archive the CVResponse and have it include every aspect of the
   validation policy.

   SCVP clients MUST support requesting and processing the validation
   policy by reference, and SCVP servers MUST support returning the
   validation policy by reference.  SCVP clients MAY support requesting
   and processing the validation policy by values.  SVCP servers SHOULD
   support returning the validation policy by values.

3.2.5.3.  protectResponse

   The protectResponse item indicates whether the client requires the
   server to protect the response.  If the client is performing full
   certification path validation on the response and it is not concerned
   about the source of the response, then the client does not benefit
   from a digital signature or MAC on the response.  In this case, the
   client can indicate to the server that protecting the message is
   unnecessary.  However, the server is always permitted to return a
   protected response.

   SCVP clients that support delegated path discovery (DPD) as defined
   in [RQMTS] MUST support setting this value to FALSE.

   SCVP clients that support delegated path validation (DPV) as defined
   in [RQMTS] require an authenticated response.  Unless a protected
   transport mechanism (such as TLS) is used, such clients MUST always
   set this value to TRUE or omit the responseFlags item entirely, which
   requires the server to return a protected response.

   SCVP servers MUST support returning protected responses, and SCVP
   servers SHOULD support returning unprotected responses.  Based on
   local policy, the server can be configured to return protected or
   unprotected responses if this value is set to FALSE.  If, based on
   local policy, the server is unable to return protected responses,
   then the server MUST return an error if this value is set to TRUE.

3.2.5.4.  cachedResponse

   The cachedResponse item indicates whether the client will accept a
   cached response.  To enhance performance and limit the exposure of
   signing keys, an SCVP service may be designed to cache responses
   until new revocation information is expected.  Where cachedResponse
   is set to TRUE, the client will accept a previously cached response.

   Clients may insist on creation of a fresh response to protect against
   a replay attack and ensure that information is up to date.  Where
   cachedResponse is FALSE, the client will not accept a cached
   response.  To ensure that a response is fresh, the client MUST also
   include the requestNonce as defined in Section 3.4.

   Servers MUST process the cachedResponse flag.  Where cachedResponse
   is FALSE, servers that cannot produce fresh responses MUST reply with
   an error message.  Servers MAY choose to provide fresh responses even
   where cachedResponse is set to TRUE.

3.2.6.  serverContextInfo

   The optional serverContextInfo item, if present, contains context
   from a previous request-response exchange with the same SCVP server.
   It allows the server to return more than one certification path 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 another one can be found).

   Contents of the serverContextInfo are opaque to the SCVP 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 to be
   identical to the previous query with the exception of the following:

      - requestNonce,

      - serverContextInfo, and

      - the client's digital signature or MAC on the request.

   SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD
   support serverContextInfo.

3.2.7.  validationTime

   The optional validationTime item, if present, tells the date and time
   relative to which the SCVP client wants the server to perform the
   checks.  If the validationTime is not present, the server MUST
   perform the validation using the date and time at which the server
   processes the request.  If the validationTime is present, it MUST be
   encoded as GeneralizedTime.  The validationTime provided MUST be a
   retrospective time since the server can only perform a validity check
   using the current time (default) or previous time.  A server can
   ignore the validationTime provided in the request if the time is
   within the clock skew of the server's current time.

   The revocation status information is obtained with respect to the
   validation time.  When specifying a validation time other than the
   current time, the validation time should not necessarily be identical
   to the time when the private key was used.  The validation time
   specified by the client may be adjusted 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.

   GeneralizedTime values MUST be expressed in Universal Coordinated
   Time (UTC) (which is also known as Greenwich Mean Time and Zulu time)
   and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when
   the number of seconds is zero.  GeneralizedTime values MUST NOT
   include fractional seconds.

   The information in the corresponding CertReply item in the response
   MUST be formatted as if the server created the response at the time
   indicated in the validationTime.  However, if the server does not
   have appropriate historical information, the server MUST return an
   error response.

   SCVP servers MUST apply a clock skew to the validation time to allow
   for minor time synchronization errors.  The default value is 10
   minutes.  If the server uses a value other than the default, it MUST
   include the clock skew value in the validation policy response.

   SCVP clients MAY support validationTime other than the current time.
   SCVP servers MUST support using its current time, and SHOULD support
   the client setting the validationTime in the request.

3.2.8.  intermediateCerts

   The optional intermediateCerts item may help the SCVP server create
   valid certification paths.  The intermediateCerts item, when present,
   provides certificates that the server MAY use when forming a
   certification path.  When building certification paths, the server
   MAY use the certificates in the intermediateCerts item in addition to
   any other certificates that the server can access.  When present, the
   intermediateCerts item MUST contain at least one certificate, and

   the intermediateCerts item MUST be structured as a CertBundle.  The
   certificates in the intermediateCerts item MUST NOT be considered as
   valid by the server just because they are present in this item.

   The CertBundle type contains one or more certificates.  The order of
   the entries in the bundle is not important.  CertBundle has the
   following syntax:

      CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate

   SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST
   support intermediateCerts.

3.2.9.  revInfos

   The optional revInfos item specifies revocation information such as
   CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP
   server MAY use when validating certification paths.  The purpose of
   the revInfos item is to provide revocation information to which the
   server might not otherwise have access, such as an OCSP response that
   the client received along with the certificate.  Note that the
   information in the revInfos item might not be used by the server.
   For example, the revocation information might be associated with
   certificates that the server does not use in the certification path
   that it constructs.

   Clients SHOULD be courteous to the SCVP server by separating CRLs and
   delta CRLs.  However, since the two share a common syntax, SCVP
   servers SHOULD accept delta CRLs even if they are identified as
   regular CRLs by the SCVP client.

   CRLs, delta CRLs, and OCSP responses can be provided as revocation
   information.  If needed, additional object identifiers can be
   assigned for additional revocation information types in the future.

   The revInfos item uses the RevocationInfos type, which has the
   following syntax:

      RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo

      RevocationInfo ::= CHOICE {
        crl                    [0] CertificateList,
        delta-crl              [1] CertificateList,
        ocsp                   [2] OCSPResponse,
        other                  [3] OtherRevInfo }

      OtherRevInfo ::= SEQUENCE {
        riType                     OBJECT IDENTIFIER,
        riValue                    ANY DEFINED BY riType }

3.2.10.  producedAt

   The client MAY allow the server to use a cached SCVP response.  When
   doing so, the client MAY use the producedAt item to express
   requirements on the freshness of the cached response.  The producedAt
   item tells the earliest date and time at which an acceptable cached
   response could have been produced.  The producedAt item represents
   the date and time in UTC, using the GeneralizedTime type.  The value
   in the producedAt item is independent of the validation time.

   GeneralizedTime value MUST be expressed in UTC, as defined in Section
   3.2.7.

   SCVP clients MAY support using producedAt values in the request.
   SCVP servers MAY support the producedAt values in the request.  SCVP
   servers that support cached responses SHOULD support the producedAt
   value in requests.

3.2.11.  queryExtensions

   The optional queryExtensions item contains extensions.  If present,
   each extension in the sequence extends the query.  This specification
   does not define any extensions; the facility is provided to allow
   future specifications to extend SCVP.  The syntax for Extensions is
   imported from [PKIX-1].  The queryExtensions item, when present, MUST
   contain a sequence of Extension items, and each of the extensions
   MUST contain extnID, critical, and extnValue items.  Each of these is
   described in the following sections.

3.2.11.1.  extnID

   The extnID item is an identifier for the extension.  It contains the
   object identifier that names the extension.

3.2.11.2.  critical

   The critical item is a BOOLEAN.  Each extension is designated as
   either critical (with a value of TRUE) or non-critical (with a value
   of FALSE).  By default, the extension is non-critical.  An SCVP
   server MUST reject the query if it encounters a critical extension
   that it does not recognize; however, a non-critical extension MAY be
   ignored if it is not recognized, but MUST be processed if it is
   recognized.

3.2.11.3.  extnValue

   The extnValue item contains an OCTET STRING.  Within the OCTET STRING
   is the extension value.  An ASN.1 type is specified for each
   extension, identified by the associated extnID object identifier.