The unsigned request consists of a certValRequest encapsulated in a   ContentInfo.  An overview of this structure is provided below.  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 signed request consists of a certValRequest encapsulated in a   SignedData which is in turn encapsulated in a ContentInfo.  An   overview of this structure is provided below. Again, many details are   not shown, but the way that SCVP makes use of CMS is clearly   illustrated.      ContentInfo {        contentType        id-signedData, -- (1.2.840.113549.1.7.2)        content            SignedData }      SignedData {        version            CMSVersion,        digestAlgorithms   DigestAlgorithmIdentifiers,        encapContentInfo   EncapsulatedContentInfo,        certificates       CertificateSet, -- (Optional)        crls               CertificateRevocationLists, -- (Optional)        signerInfos        SET OF SignerInfos } -- (only one in SCVP)      SignerInfo {        version            CMSVersion,        sid                SignerIdentifier,        digestAlgorithm    DigestAlgorithmIdentifier,        signedAttrs        SignedAttributes, -- (Required)        signatureAlgorithm SignatureAlgorithmIdentifier,        signature          SignatureValue,        unsignedAttrs      UnsignedAttributes } -- (not used in SCVP)      EncapsulatedContentInfo {        eContentType       id-ct-scvp-certValRequest,                                    -- (1.2.840.113549.1.9.16.1.10)        eContent           OCTET STRING } -- Contains CVRequest   The syntaxes for SignedData and ContentInfo are defined in [CMS]. The   syntax for CVRequest is defined below. The CVRequest item contains   the client request. The CVRequest item contains the scvpVersion and   query items; and the CVRequest item MAY also contain the requestor,   requestNonce, and reqExtensions items.Malpani, Housley, & Freeman                                     [Page 7]INTERNET DRAFT                    SCVP                     December 2002   The CVRequest MUST have the following syntax:      CVRequest ::= SEQUENCE {        scvpVersion           INTEGER,        query                 Query,        requestor         [0] OCTET STRING OPTIONAL,        requestNonce      [1] OCTET STRING OPTIONAL,        reqExtensions     [2] Extensions OPTIONAL }   Each of the items within the CVRequest are described in the following   sections.3.1 scvpVersion   The scvpVersion item tells the version of SCVP used in a request or a   response. The value of the scvpVersion item MUST be one (1). Future   updates to this specification ought to specify other integer values.3.2 query   The query specifies one or more certificates that are the object of   the request; the certificates can be either public key certificates   [PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain a   sequence of one or more certificate references, checks, and wantBack   items; and a query MAY also contain valPolicy, validityTime,   trustAnchors, intermediateCerts, revInfos, and queryExtensions items.   Query MUST have the following syntax:      Query ::= SEQUENCE {        queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference,        checks                CertChecks,        wantBack              WantBack,        serverContextInfo [0] OCTET STRING OPTIONAL,        valPolicy         [1] ValidationPolicy OPTIONAL,        validityTime      [2] GeneralizedTime OPTIONAL,        trustAnchors      [3] TrustAnchors OPTIONAL,        intermediateCerts [4] CertBundle OPTIONAL,        revInfos          [5] RevocationInfos OPTIONAL,        queryExtensions   [6] Extensions OPTIONAL }   The list of certificate references in the Query item tells the server   the certificate(s) for which the client wants information. The   OPTIONAL serverContextInfo item tells the server that additional   information from a previous request-response in desired. The OPTIONAL   validityTime item tells the date and time relative to which the   client wants the server to perform the checks. The OPTIONAL   valPolicy, trustAnchors, intermediateCerts, and revInfos itemsMalpani, Housley, & Freeman                                     [Page 8]INTERNET DRAFT                    SCVP                     December 2002   provide context for the client request. The OPTIONAL queryExtensions   item provides for future expansion of the query syntax.3.2.1 queriedCerts   The queriedCerts item, using the CertReference type, identifies the   certificate that is the object of the request. The certificate is   either a public key certificate or an attribute certificate. The   certificate is either directly included or it is referenced. When   referenced, a SHA-1 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 ESSCertID type defined in [ESS]. CertReference has   the following syntax:      CertReference ::= CHOICE {        pkc                   PKCReference,        ac                    ACReference }      PKCReference ::= CHOICE {        cert              [1] Certificate,        pkcRef            [2] ESSCertID }      ACReference ::= CHOICE {        attrCert          [3] AttributeCertificate,        acRef             [4] ESSCertID }   The ASN.1 definition of Certificate is imported from [PKIX-1]; the   definition of AttributeCertificate is imported from [PKIX-AC]; and   the definition of ESSCertID is imported from [ESS].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 MUST contain a sequence of object identifiers.   Each object identifier 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 all of the requested checks, or   return an error.   Revocation status checking inherently includes path construction.   Also, building a validated certification path does not imply   revocation status checks (although a server may still choose to   perform revocation status checks).Malpani, Housley, & Freeman                                     [Page 9]INTERNET DRAFT                    SCVP                     December 2002   The checks item uses the CertChecks type, which has the following   syntax:      CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER   A list of object identifiers (OIDs) indicates the checking that the   client wants the SCVP server to perform on the certificate(s) in the   queriedCerts item.   For public key certificates, OIDs are defined for the following   checks:      - Build a certification path to a trusted root;      - Build a validated certification path to a trusted root; and      - Do revocation status checks on the certification path.   For attribute certificates, OIDs are defined for the following   checks:      - Build a certification path to a trusted root for the AC issuer;      - Build a validated certification path to a trusted root for the        AC issuer;      - Do revocation status checks on the certification path for the        AC issuer; and      - Do revocation status checks on the AC as well as the        certification path for the AC issuer.   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 }Malpani, Housley, & Freeman                                    [Page 10]INTERNET DRAFT                    SCVP                     December 20023.2.3 wantBack   The wantBack item describes the kind of information the SCVP client   wants from the SCVP server for the certificate(s) in the queriedCerts   item. The wantBack item MUST contain a sequence of object   identifiers. Each object identifier 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   certification path that the server considers to be valid. 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 include a wantBack item that requests the   return of the status. 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 types of information that can be   requested are:      - Certification path built for the certificate;      - Proof of revocation status for each certificate in the        certification path;      - Status indication; and      - Public key from the certificate.Malpani, Housley, & Freeman                                    [Page 11]INTERNET DRAFT                    SCVP                     December 2002   For attribute certificates, the types of information that can be   requested are:      - Certification path built for the AC issuer certificate;      - Proof of revocation status for each certificate in the AC issuer        certification path;      - Proof of revocation status for the attribute certificate; and      - Status indication.   For these purposes, the following OIDs are defined:      id-swb OBJECT IDENTIFIER ::= { id-pkix 18 }  -- SCVP want back      id-swb-pkc-cert-path         OBJECT IDENTIFIER ::= { id-swb 1 }      id-swb-pkc-revocation-info   OBJECT IDENTIFIER ::= { id-swb 2 }      id-swb-pkc-cert-status       OBJECT IDENTIFIER ::= { id-swb 3 }      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-ac-cert-status        OBJECT IDENTIFIER ::= { id-swb 8 }3.2.4 serverContextInfo   The serverContextInfo item, if present, contains context from a   previous request-response transaction 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 be   essentially identical to the previous query. The client MUST NOTMalpani, Housley, & Freeman                                    [Page 12]INTERNET DRAFT                    SCVP                     December 2002