change any items other than:      - requestNonce;      - serverContextInfo; and      - the client's signature on the request3.2.5 valPolicy   The valPolicy item, when present, defines the validation policy to be   used by the SCVP server during certificate validation. The client can   use this option instead of specifying other SCVP configuration items   such as trustAnchors. The value of this item is determined by private   agreement between the client and the server, but it MUST be   represented as an object identifier. The server might want to assign   identifiers that indicate that some settings are used in addition to   others given in the request. In this way, the validation policy   object identifier can be a shorthand for some SCVP options, but not   others.   The valPolicy item uses the ValidationPolicy type, which has the   following syntax:      ValidationPolicy ::= SEQUENCE {        valPolicyId           OBJECT IDENTIFIER,        parameters            ANY DEFINED BY valPolicyId OPTIONAL }   If no validation policy is specified in the request, then the SCVP   server's default validation policy is used. The default validation   policy may also be explicitly specified. The object identifier to   identify 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 }Malpani, Housley, & Freeman                                    [Page 13]INTERNET DRAFT                    SCVP                     December 2002   The meaning of the default validation policy is:      - Trust anchors will come from the trustAnchors item. If no        certificates are specified in the trustAnchors item, then        the SCVP server will use trust anchors of its own choosing.      - The acceptable policy set will come from the certPolicies        item associated with the selected trust anchor. If no        certificate policies are specified in the certPolicies item,        then the SCVP server will use any-policy.      - The SCVP server will check for certificate revocation using        CRLs, delta CRLs, OCSP responses, or any other source of        revocation information that is available.3.2.6 validityTime   The OPTIONAL validityTime item tells the date and time relative to   which the SCVP client wants the server to perform the checks. If the   validityTime is present, it MUST be encoded as GeneralizedTime. If   the validityTime is not present, the server MUST respond as if the   client provided the date and time at which the server processes the   request.   GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu)   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 validityTime. However, if the server does not have   appropriate historical information, the server MUST return an error.3.2.7 trustAnchors   The OPTIONAL trustAnchors item specifies the trust anchors to be used   by the SCVP server. One or more certificate policy MAY be associated   with each trust anchor. If a trustAnchors item is present, the server   MUST NOT use any certification path trust anchors other than those   provided.   The TrustAnchors type contains one or more trust anchor   specification. A certificate reference can be used to identify the   trust anchor distinguished name, public key algorithm, associated   public key parameters, if needed, and the trusted public key.   Alternatively, these items can be provided directly. The order of   trust anchor specifications within the sequence is not important.Malpani, Housley, & Freeman                                    [Page 14]INTERNET DRAFT                    SCVP                     December 2002   The OPTIONAL certPolicies item specifies a list of policy identifiers   that the SCVP server MUST use when forming and validating a   certification path that terminates at the associated trust anchor. If   certPolicies is not specified, then any-policy MUST be used.   The trust anchor itself, regardless of its form, MUST NOT be included   in any certification path constructed by the SCVP server.   TrustAnchors has the following syntax:      TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor      TrustAnchor ::= SEQUENCE {        anchor                  TrustAnchorInfo,        certPolicies        [1] SEQUENCE SIZE (1..MAX) OF                                OBJECT IDENTIFIER OPTIONAL }                                -- if absent, use any-policy      TrustAnchorInfo ::= CHOICE {        certRef                 PKCReference,        rawInfo             [3] RawTrustAnchorInfo }      RawTrustAnchorInfo ::= SEQUENCE {        name                    Name,        algorithm               AlgorithmIdentifier,        pubKey                  BIT STRING }3.2.8 intermediateCerts   The OPTIONAL intermediateCerts item helps the SCVP server create   valid certification paths. The intermediateCerts item, when present,   provides certificates that the server MAY use when forming a   certification path. The certificates in the intermediateCerts item   MAY be used by the server in addition to any other certificates that   the server can access when building certification paths. The   intermediateCerts item, when present, MUST contain at least one   certificate. The intermediateCerts item MUST be structured as a   CertBundle. The certificates in the intermediateCerts MUST NOT be   trusted by the server just because they are present in this item.   The CertBundle type contains one or more certificate references. The   order of the entries in the bundle is not important. CertBundle has   the following syntax:      CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReferenceMalpani, Housley, & Freeman                                    [Page 15]INTERNET DRAFT                    SCVP                     December 20023.2.9 revInfos   The OPTIONAL revInfo 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 (for example, 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 certification path   building.   It is courteous to the SCVP server to separate 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 ::= SEQUENCE {        riType                OBJECT IDENTIFIER,        riValue               ANY DEFINED BY riType }   The riType object identifiers are as follows:      id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)            dod(6) internet(1) security(5) mechanisms(5) pkix(7) 16 }      id-ri-crl                    OBJECT IDENTIFIER ::= { id-ri 1 }      id-ri-ocsp-response          OBJECT IDENTIFIER ::= { id-ri 2 }      id-ri-delta-crl              OBJECT IDENTIFIER ::= { id-ri 3 }3.2.10 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 extension MUSTMalpani, Housley, & Freeman                                    [Page 16]INTERNET DRAFT                    SCVP                     December 2002   contain extnID, critical, and extnValue items.   The extnID item is an identifier for the extension. It contains the   object identifier that names the extension.   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). An SCVP server MUST reject the query if it encounters a   critical extension it does not recognize; however, a non-critical   extension MAY be ignored if it is not recognized.   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.3.3 requestor   The OPTIONAL requestor item is used to identify the requestor. The   value is only of local significance to the requestor. If the SCVP   client includes a requestor value in the request, then the SCVP   server MUST return the same value in the response.   The requestor item MUST be an octet string. No provisions are made to   ensure uniqueness of the requestor octet string; however, all of the   octets MUST have values other than zero.3.4 requestNonce   The OPTIONAL requestNonce item contains an identifier generated by   the SCVP client for the request. If the client includes a   requestNonce value in the request, then the server MUST return the   same value in the response. The client SHOULD include a requestNonce   item in every request to prevent an attacker from acting as a man-in-   the-middle by replaying old responses from the server. The   requestNonce value SHOULD change with every request sent by the   client.   The requestNonce item MUST be an octet string.3.5 reqExtensions   The OPTIONAL reqExtensions item contains Extensions. If present, each   Extension in the sequence extends the request. This specification   does not define any extensions, the facility is provided to allow   future specifications to extend the SCVP. The syntax for Extensions   is imported from [PKIX-1]. The reqExtensions item, when present, MUST   contain a sequence of extension items, and each of extension MUST   contain extnID, critical, and extnValue items.Malpani, Housley, & Freeman                                    [Page 17]INTERNET DRAFT                    SCVP                     December 2002   The extnID item is an identifier for the extension. It contains the   object identifier that names the extension.   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). An SCVP server MUST reject the query if it encounters a   critical extension it does not recognize; however, a non-critical   extension MAY be ignored if it is not recognized.   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.4 Validation Response   A SCVP server response to the client MUST be a single SCVPResponse   item. A SCVPRequest item is carried in an application/scvp-response   MIME body part.   There are two forms of an SCVP response: unsigned and signed. An   unsigned response MUST only be generated for an error status. An   overview of the structure used for an unsigned response 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-certValResponse,                                    -- (1.2.840.113549.1.9.16.1.11)        content            CVResponse }   The signed response consists of a CVResponse encapsulated in a   SignedData which is in turn encapsulated in a ContentInfo. An   overview of the structure used for a signed response 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, -- (MUST include server cert)        crls               CertificateRevocationLists, -- (Optional)        signerInfos        SET OF SignerInfos } -- Only 1 in SCVPMalpani, Housley, & Freeman                                    [Page 18]INTERNET DRAFT                    SCVP                     December 2002      SignerInfo {        version            CMSVersion,