4.10.  respNonce

   The respNonce item contains an identifier to bind the request to the
   response.

   If the client includes a requestNonce value in the request and the
   server is generating a specific non-cached response to the request
   then the server MUST return the same value in the response.

   If the server is using a cached response to the request then it MUST
   omit the respNonce item.

   If the server is returning a specific non-cached response to a
   request without a nonce, then the server MAY include a message-
   specific nonce.  For digitally signed messages, the server MAY use
   the value of the message-digest attribute in the signedAttrs within
   SignerInfo of the request as the value in the respNonce item.

   The requestNonce item uses the OCTET STRING type.

   Conforming client implementations MUST be able to process a response
   that includes this item.  Conforming servers MUST support respNonce.

4.11.  serverContextInfo

   The serverContextInfo item in a response is a mechanism for the
   server to pass some opaque context information to the client.  If the
   client does not like the certification path returned, it can make a
   new query and pass along this context information.

   Section 3.2.6 contains information about the client's usage of this
   item.

   The context information is opaque to the client, but it provides
   information to the server that ensures that a different certification
   path will be returned (if another one can be found).  The context
   information could indicate the state of the server, or it could
   contain a sequence of hashes of certification paths that have already
   been returned to the client.  The protocol does not dictate any
   structure or requirements for this item.  However, implementers
   should review the Security Considerations section of this document
   before selecting a structure.

   Servers that are incapable of returning additional paths MUST NOT
   include the serverContextInfo item in the response.

4.12.  cvResponseExtensions

   If present, the cvResponseExtensions item contains a sequence of
   extensions that extend the response.  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 cvResponseExtensions item, when present, contains
   a sequence of Extension items, each of which contains an extnID item,
   a critical item, and an extnValue item.

   The extnID item is an identifier for the extension.  It contains the
   object identifier (OID) 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 client MUST reject the response 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.13.  requestorText

   The requestorText item contains a text field supplied by the client.

   If the client includes a requestorText value in the request and the
   server is generating a specific non-cached response to the request,
   then the server MUST return the same value in the response.

   If the server is using a cached response to the request, then it MUST
   omit the requestorText item.

   The requestNonce item uses the UTF8 string type.

   Conforming client implementations that support the requestorText item
   in requests (see Section 3.10) MUST be able to process a response
   that includes this item.  Conforming servers MUST support
   requestorText in responses.

4.14.  SCVP Response Validation

   There are two mechanisms for validation of SCVP responses, one based
   on the client's knowledge of a specific SCVP server key and the other
   based on validation of the certificate corresponding to the private
   key used to protect the SCVP response.

4.14.1.  Simple Key Validation

   The simple key validation method is where the SCVP client has a local
   policy of one or more SCVP server keys that directly identify the set
   of valid SCVP servers.  Mechanisms for storage of server keys or
   identifiers are a local matter.  For example, a client could store
   cryptographic hashes of public keys used to verify SignedData
   responses.  Alternatively, a client could store shared symmetric keys
   used to verify MACs in AuthenticatedData responses.

   Simple key validation MUST be used by SCVP clients that cannot
   validate PKIX-1 certificates and are therefore making delegated path
   validation requests to the SCVP server [RQMTS].  It is a matter of
   local policy with these clients whether to use SignedData or
   AuthenticatedData.  Simple key validation MAY be used by other SCVP
   clients for other reasons.

4.14.2.  SCVP Server Certificate Validation

   It is a matter of local policy what validation policy the client uses
   when validating responses.  When validating protected SCVP responses,
   SCVP clients SHOULD use the validation algorithm defined in Section 6
   of [PKIX-1].  SCVP clients may impose additional limitations on the
   algorithm, such as limiting the number of certificates in the path or
   establishing initial name constraints, as specified in Section 6.2 of
   [PKIX-1].

   If the certificate used to sign the validation policy responses and
   SignedData validation responses contains the key usage extension
   ([PKIX-1], Section 4.2.1.3), it MUST have either the digital
   signature bit set, the non-repudiation bit set, or both bits set.

   If the certificate for AuthenticatedData validation responses
   contains the key usage extension, it MUST have the key agreement bit
   set.

   If the certificate used on a validation policy response or a
   validation response contains the extended key usage extension
   ([PKIX-1], Section 4.2.1.13), it MUST contain either the
   anyExtendedKeyUsage OID or the following OID:

      id-kp-scvpServer             OBJECT IDENTIFIER ::= { id-kp 15 }

5.  Server Policy Request

   An SCVP client uses the ValPolRequest item to request information
   about an SCVP server's policies and configuration information,
   including the list of validation policies supported by the SCVP
   server.  When a ValPolRequest is encapsulated in a MIME body part, it
   MUST be carried in an application/scvp-vp-request MIME body part.

   The request consists of a ValPolRequest encapsulated in a
   ContentInfo.  The client does not sign the request.

      ContentInfo {
        contentType        id-ct-scvp-valPolRequest,
                                      -- (1.2.840.113549.1.9.16.1.12)
        content            ValPolRequest }

   The ValPolRequest type has the following syntax:

      ValPolRequest ::= SEQUENCE {
        vpRequestVersion           INTEGER DEFAULT 1,
        requestNonce               OCTET STRING }

   Conforming SCVP server implementations MUST recognize and process the
   server policy request.  Conforming clients SHOULD support the server
   policy request.

5.1.  vpRequestVersion

   The syntax and semantics of vpRequestVersion are the same as
   cvRequestVersion as described in Section 3.1.

5.2.  requestNonce

   The requestNonce item contains a request identifier generated by the
   SCVP client.  If the server returns a specific response, it MUST
   include the requestNonce from the request in the response, but the
   server MAY return a cached response, which MUST NOT include a
   requestNonce.

6.  Validation Policy Response

   In response to a ValPolRequest, the SCVP server provides a
   ValPolResponse.  The ValPolResponse may not be unique to any
   ValPolRequest, so may be reused by the server in response to multiple
   ValPolRequests.  The ValPolResponse also has an indication of how
   frequently the ValPolResponse may be reissued.  The server MUST sign
   the response using its digital signature certificate.  When a
   ValPolResponse is encapsulated in a MIME body part, it MUST be
   carried in an application/scvp-vp-response MIME body part.

   The response consists of a ValPolResponse encapsulated in a
   SignedData, which is in turn encapsulated in a ContentInfo.  That is,
   the EncapsulatedContentInfo field of SignedData consists of an
   eContentType field with a value of id-ct-scvp-valPolResponse
   (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a
   DER-encoded ValPolResponse.  The SCVP server MUST include its own
   certificate in the certificates field within SignedData, and the
   signerInfos field of SignedData MUST include exactly one SignerInfo.
   The SignedData MUST NOT include the unsignedAttrs field.

   The ValPolResponse type has the following syntax:

      ValPolResponse ::= SEQUENCE {
        vpResponseVersion               INTEGER,
        maxCVRequestVersion             INTEGER,
        maxVPRequestVersion             INTEGER,
        serverConfigurationID           INTEGER,
        thisUpdate                      GeneralizedTime,
        nextUpdate                      GeneralizedTime OPTIONAL,
        supportedChecks                 CertChecks,
        supportedWantBacks              WantBack,
        validationPolicies              SEQUENCE OF OBJECT IDENTIFIER,
        validationAlgs                  SEQUENCE OF OBJECT IDENTIFIER,
        authPolicies                    SEQUENCE OF AuthPolicy,
        responseTypes                   ResponseTypes,
        defaultPolicyValues             RespValidationPolicy,
        revocationInfoTypes             RevocationInfoTypes,
        signatureGeneration             SEQUENCE OF AlgorithmIdentifier,
        signatureVerification           SEQUENCE OF AlgorithmIdentifier,
        hashAlgorithms                  SEQUENCE SIZE (1..MAX) OF
                                           OBJECT IDENTIFIER,
        serverPublicKeys                SEQUENCE OF KeyAgreePublicKey
                                           OPTIONAL,
        clockSkew                       INTEGER DEFAULT 10,
        requestNonce                    OCTET STRING OPTIONAL }

      ResponseTypes  ::= ENUMERATED {
        cached-only                (0),
        non-cached-only            (1),
        cached-and-non-cached      (2) }

      RevocationInfoTypes ::= BIT STRING {
        fullCRLs                   (0),
        deltaCRLs                  (1),
        indirectCRLs               (2),
        oCSPResponses              (3) }

   SCVP clients that support validation policy requests MUST support
   validation policy responses.  SCVP servers MUST support validation
   policy responses.

   SCVP servers MUST support cached policy responses and MAY support
   specific responses to policy requests.

6.1.  vpResponseVersion

   The syntax and semantics of the vpResponseVersion item are the same
   as cvRequestVersion as described in Section 3.1.  The
   vpResponseVersion used MUST be the same as the vpRequestVersion
   unless the client has used a value greater than the values the server
   supports.  If the client submits a vpRequestVersion greater than the
   version supported by the server, the server MUST return a
   vpResponseVersion using the highest version number the server
   supports as the version number.

6.2.  maxCVRequestVersion

   The maxCVRequestVersion item defines the maximum version number for
   CV requests that the server supports.

6.3.  maxVPRequestVersion

   The maxVPRequestVersion item defines the maximum version number for
   VP requests that the server supports.

6.4.  serverConfigurationID

   The serverConfigurationID item is an integer that uniquely represents
   the version of the server configuration as represented by the
   validationPolicies, validationAlgs, authPolicies,
   defaultPolicyValues, and clockSkew.  If any of these values change,
   the server MUST create a new ValPolResponse with a new
   serverConfigurationID.  If the configuration has not changed, then
   the server may reuse serverConfigurationID across multiple

   ValPolResponse messages.  However, if the server reverts to an
   earlier configuration, the server MUST NOT revert the configuration
   ID as well, but MUST select another unique value.

6.5.  thisUpdate

   This item indicates the signing date and time of this policy
   response.

   GeneralizedTime values MUST be expressed in Greenwich Mean Time
   (Zulu) and interpreted as defined in Section 3.2.7.

6.6.  nextUpdate and requestNonce

   These items are used to indicate whether policy responses are
   specific to policy requests.  Where policy responses are cached,
   these items indicate when the information will be updated.  The
   optional nextUpdate item indicates the time by which the next policy
   response will be published.  The optional requestNonce item links the
   response to a specific request by returning the nonce provided in the
   request.

   If the nextUpdate item is omitted, it indicates a non-cached response
   generated in response to a specific request (i.e., the ValPolResponse
   is bound to a specific request).  If this item is omitted, the
   requestNonce item MUST be present and MUST include the requestNonce
   value from the request.

   If the nextUpdate item is present, it indicates a cached response
   that is not bound to a specific request.  An SCVP server MUST
   periodically generate a new response as defined by the next update
   time, but MAY use the same ValPolResponse to respond to multiple
   requests.  The requestNonce is omitted if the nextUpdate item is
   present.

   It is a matter of local server policy to return a cached or non-
   cached specific response.

   GeneralizedTime values in nextUpdate MUST be expressed in Greenwich
   Mean Time (Zulu) as specified in Section 3.2.7.

6.7.  supportedChecks

   The supportedChecks item contains a sequence of object identifiers
   representing the checks supported by the server.

6.8.  supportedWantBacks

   The supportedWantBacks item contains a sequence of object identifiers
   representing the wantBacks supported by the server.

6.9.  validationPolicies

   The validationPolicies item contains a sequence of object identifiers
   representing the validation policies supported by the server.  It is
   a matter of local policy if the server wishes to process requests
   using the default validation policy, and if it does not, then it MUST
   NOT include the id-svp-defaultValPolicy in this list.

6.10.  validationAlgs

   The validationAlgs item contains a sequence of OIDs.  Each OID
   identifies a validation algorithm supported by the server.

6.11.  authPolicies

   The authPolicies item contains a sequence of policy references for
   authenticating to the SCVP server.

   The reference to the authentication policy is an OID that the client
   and server have agreed represents an authentication policy.  The list
   of policies is intended to document to the client if authentication
   is required for some requests and if so how.

      AuthPolicy ::=  OBJECT IDENTIFIER

6.12.  responseTypes

   The responseTypes item allows the server to publish the range of
   response types it supports.  Cached only means the server will only
   return cached responses to requests.  Non-cached only means the
   server will return a specific response to the request, i.e.,
   containing the requestor's nonce.  Both means that the server
   supports both cached and non-cached response types and will return
   either a cached or non- cached response, depending on the request.

6.13.  revocationInfoTypes

   The revocationInfoTypes item allows the server to indicate the
   sources of revocation information that it is capable of processing.
   For each bit in the RevocationInfoTypes BIT STRING, the server MUST
   set the bit to one if it is capable of processing the corresponding
   revocation information type and to zero if it cannot.

6.14.  defaultPolicyValues

   This is the default validation policy used by the server.  It
   contains a RespValidationPolicy, which is defined in Section 4.5.
   All OPTIONAL items in the validationPolicy item MUST be populated.  A
   server will use these default values when the request references the
   default validation policy and the client does not override the
   default values by supplying other values in the request.

   This allows the client to optimize the request by omitting parameters
   that match the server default values.

6.15.  signatureGeneration

   This sequence specifies the set of digital signature algorithms
   supported by an SCVP server for signing CVResponse messages.  Each
   digital signature algorithm is specified as an AlgorithmIdentifier,
   using the encoding rules associated with the signatureAlgorithm field
   in a public key certificate [PKIX-1].  Supported algorithms are
   defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms
   may also be supported.

   By including an algorithm (e.g., RSA with SHA-1) in this list, the
   server states that it has a private key and corresponding certified
   public key for that asymmetric algorithm, and supports the specified
   hash algorithm.  The list is ordered; the first digital signature
   algorithm is the server's default algorithm.  The default algorithm
   will be used by the server to protect signed messages unless the
   client specifies another algorithm.

   For servers that do not have an on-line private key, and cannot sign
   CVResponse messages, the signatureGeneration item is encoded as an
   empty sequence.

6.16.  signatureVerification

   This sequence specifies the set of digital signature algorithms that
   can be verified by this SCVP server.  Each digital signature
   algorithm is specified as an AlgorithmIdentifier, using the encoding
   rules associated with the signatureAlgorithm field in a public key
   certificate [PKIX-1].  Supported algorithms are defined in [PKIX-ALG]
   and [PKIX-ALG2], but other signature algorithms may also be
   supported.

   For servers that do not verify signatures on CVRequest messages, the
   signatureVerification item is encoded as an empty sequence.

6.17.  hashAlgorithms

   This sequence specifies the set of hash algorithms that the server
   can use to hash certificates and requests.  The list is ordered; the
   first hash algorithm is the server's default algorithm.  The default
   algorithm will be used by the server to compute hashes included in
   responses unless the client specifies another algorithm.  Each hash
   algorithm is specified as an object identifier.  [PKIX-ALG2]
   specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384,
   and SHA-512.  Other hash algorithms may also be supported.

6.18.  serverPublicKeys

   The serverPublicKeys item is a sequence of one or more key agreement
   public keys and associated parameters.  It is used by clients making
   AuthenticatedData requests to the server.  Each item in the
   serverPublicKeys sequence is of the KeyAgreePublicKey type:

      KeyAgreePublicKey ::= SEQUENCE {
        algorithm            AlgorithmIdentifier,
        publicKey            BIT STRING,
        macAlgorithm         AlgorithmIdentifier,
        kDF                  AlgorithmIdentifier OPTIONAL }

   The KeyAgreePublicKey includes the algorithm identifier and the
   server's public key.  SCVP servers that support the key agreement
   mode of AuthenticatedData for SCVP requests MUST support
   serverPublicKeys and the Diffie-Hellman key agreement algorithm as
   specified in [PKIX-ALG].  SCVP servers that support serverPublicKeys
   MUST support the 1024-bit Modular Exponential (MODP) group key (group
   2) as defined in [IKE].  SCVP servers that support serverPublicKeys
   MAY support other Diffie-Hellman groups [IKE-GROUPS], as well as
   other key agreement algorithms.

   The macAlgorithm item specifies the symmetric algorithm the server
   expects the client to use with the result of the key agreement
   algorithm.  A key derivation function (KDF), which derives symmetric
   key material from the key agreement result, may be implied by the
   macAlgorithm.  Alternatively, the KDF may be explicitly specified
   using the optional kDF item.

6.19.  clockSkew

   The clockSkew item is the number of minutes the server will allow for
   clock skew.  The default value is 10 minutes.

7.  SCVP Server Relay

   In some network environments, especially ones that include firewalls,
   an SCVP server might not be able to obtain all of the information
   that it needs to process a request.  However, the server might be
   configured to use the services of one or more other SCVP servers to
   fulfill all requests.  In such cases, the SCVP client is unaware that
   the initial SCVP server is using the services of other SCVP servers.
   The initial SCVP server acts as a client to another SCVP server.
   Unlike the original client, the SCVP server is expected to have
   moderate computing and memory resources.   This section describes
   SCVP server-to-SCVP server exchanges.  This section does not impose
   any requirements on SCVP clients that are not also SCVP servers.
   Further, this section does not impose any requirements on SCVP
   servers that do not relay requests to other SCVP servers.

   When one SCVP server relays a request to another server, in an
   incorrectly configured system of servers, it is possible that the
   same request will be relayed back again.  Any SCVP server that relays
   requests MUST implement the conventions described in this section to
   detect and break loops.

   When an SCVP server relays a request, the request MUST include the
   requestorRef item.  If the request to be relayed already contains a
   requestorRef item, then the server-generated request MUST contain a
   requestorRef item constructed from this value and an additional
   GeneralName that contains an identifier of the SCVP server.  If the
   request to be relayed does not contain a requestorRef item, then the
   server-generated request MUST contain a requestorRef item that
   includes a GeneralName that contains an identifier of the SCVP
   server.

   To prevent false loop detection, servers should use identifiers that
   are unique within their network of cooperating SCVP servers.  SCVP
   servers that support relay SHOULD populate this item with the DNS
   name of the server or the distinguished name in the server's
   certificate.  SCVP servers MAY choose other procedures for generating
   identifiers that are unique within their community.

   When an SCVP server receives a request that contains a requestorRef
   item, the server MUST check the sequence of names in the requestorRef
   item for its own identifier.  If the server discovers its own
   identifier in the requestorRef item, it MUST respond with an error,
   setting the statusCode in the responseStatus item to 40.

   When an SCVP server generates a non-cached response to a relayed
   request, the server MUST include the requestorRef item from the
   request in the response.

8.  SCVP ASN.1 Module

   This section defines the syntax for SCVP request-response pairs.  The
   semantics for the messages are defined in Sections 3, 4, 5, and 6.
   The SCVP ASN.1 module follows.

   SCVP

     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) 21 }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS

   AlgorithmIdentifier, Attribute, Certificate, Extensions,
   -- Import UTF8String if required by compiler
   -- UTF8String, -- CertificateList, CertificateSerialNumber
     FROM PKIX1Explicit88 -- RFC 3280
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) 18 }

   GeneralNames, GeneralName, KeyUsage, KeyPurposeId
     FROM PKIX1Implicit88 -- RFC 3280
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) 19 }

   AttributeCertificate
     FROM PKIXAttributeCertificate -- RFC 3281
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) 12 }

   OCSPResponse
     FROM OCSP -- RFC 2560
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) 14 }

   ContentInfo
     FROM CryptographicMessageSyntax2004 -- RFC 3852
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } ;


   -- SCVP Certificate Validation Request

   id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9)
             id-smime(16) 1 }

   id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 }

   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 }

   Query ::= SEQUENCE {
     queriedCerts             CertReferences,
     checks                   CertChecks,
     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 }

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

   CertReference::= CHOICE {
     pkc               PKCReference,
     ac                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 } }

   SCVPIssuerSerial ::= SEQUENCE {
        issuer         GeneralNames,
        serialNumber   CertificateSerialNumber
   }

   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 }


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

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

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

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

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

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

   KeyAgreePublicKey ::= SEQUENCE {
     algorithm           AlgorithmIdentifier,
     publicKey           BIT STRING,
     macAlgorithm        AlgorithmIdentifier,
     kDF                 AlgorithmIdentifier OPTIONAL }

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

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

   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 }

   -- SCVP Certificate Validation Response

   id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }

   CVResponse ::= SEQUENCE {
     cvResponseVersion          INTEGER,
     serverConfigurationID      INTEGER,
     producedAt                 GeneralizedTime,
     responseStatus             ResponseStatus,
     respValidationPolicy   [0] RespValidationPolicy OPTIONAL,
     requestRef             [1] RequestReference OPTIONAL,
     requestorRef           [2] GeneralNames OPTIONAL,
     requestorName          [3] GeneralNames OPTIONAL,
     replyObjects           [4] ReplyObjects OPTIONAL,
     respNonce              [5] OCTET STRING OPTIONAL,
     serverContextInfo      [6] OCTET STRING OPTIONAL,
     cvResponseExtensions   [7] Extensions OPTIONAL,
     requestorText          [8] UTF8String (SIZE (1..256)) OPTIONAL }

   ResponseStatus ::= SEQUENCE {
       statusCode               CVStatusCode DEFAULT  okay,
       errorMessage             UTF8String OPTIONAL }

   CVStatusCode ::= ENUMERATED {
       okay                               (0),
       skipUnrecognizedItems              (1),
       tooBusy                           (10),
       invalidRequest                    (11),
       internalError                     (12),
       badStructure                      (20),
       unsupportedVersion                (21),
       abortUnrecognizedItems            (22),
       unrecognizedSigKey                (23),
       badSignatureOrMAC                 (24),

       unableToDecode                    (25),
       notAuthorized                     (26),
       unsupportedChecks                 (27),
       unsupportedWantBacks              (28),
       unsupportedSignatureOrMAC         (29),
       invalidSignatureOrMAC             (30),
       protectedResponseUnsupported      (31),
       unrecognizedResponderName         (32),
       relayingLoop                      (40),
       unrecognizedValPol                (50),
       unrecognizedValAlg                (51),
       fullRequestInResponseUnsupported  (52),
       fullPolResponseUnsupported        (53),
       inhibitPolicyMappingUnsupported   (54),
       requireExplicitPolicyUnsupported  (55),
       inhibitAnyPolicyUnsupported       (56),
       validationTimeUnsupported         (57),
       unrecognizedCritQueryExt          (63),
       unrecognizedCritRequestExt        (64) }

   RespValidationPolicy ::= ValidationPolicy

   RequestReference ::= CHOICE {
     requestHash   [0] HashValue, -- hash of CVRequest
     fullRequest   [1] CVRequest }

   HashValue ::= SEQUENCE {
     algorithm         AlgorithmIdentifier DEFAULT { algorithm sha-1 },
     value             OCTET STRING }

   sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             oiw(14) secsig(3) algorithm(2) 26 }

   ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply

   CertReply ::= SEQUENCE {
     cert                       CertReference,
     replyStatus                ReplyStatus DEFAULT success,
     replyValTime               GeneralizedTime,
     replyChecks                ReplyChecks,
     replyWantBacks             ReplyWantBacks,
     validationErrors       [0] SEQUENCE SIZE (1..MAX) OF
                                  OBJECT IDENTIFIER OPTIONAL,
     nextUpdate             [1] GeneralizedTime OPTIONAL,
     certReplyExtensions    [2] Extensions OPTIONAL }

   ReplyStatus ::= ENUMERATED {
     success                    (0),
     malformedPKC               (1),
     malformedAC                (2),
     unavailableValidationTime  (3),
     referenceCertHashFail      (4),
     certPathConstructFail      (5),
     certPathNotValid           (6),
     certPathNotValidNow        (7),
     wantBackUnsatisfied        (8) }

   ReplyChecks ::= SEQUENCE OF ReplyCheck

   ReplyCheck ::= SEQUENCE {
     check                      OBJECT IDENTIFIER,
     status                     INTEGER DEFAULT 0 }

   ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

   ReplyWantBack::= SEQUENCE {
     wb                         OBJECT IDENTIFIER,
     value                      OCTET STRING }

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

   RevInfoWantBack ::= SEQUENCE {
     revocationInfo             RevocationInfos,
     extraCerts                 CertBundle OPTIONAL }

   SCVPResponses ::= SEQUENCE OF ContentInfo

   -- SCVP Validation Policies Request

   id-ct-scvp-valPolRequest     OBJECT IDENTIFIER ::= { id-ct 12 }

   ValPolRequest ::= SEQUENCE {
     vpRequestVersion           INTEGER DEFAULT 1,
     requestNonce               OCTET STRING }

   -- SCVP Validation Policies Response

   id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }

   ValPolResponse ::= SEQUENCE {
     vpResponseVersion                INTEGER,
     maxCVRequestVersion              INTEGER,
     maxVPRequestVersion              INTEGER,
     serverConfigurationID            INTEGER,

     thisUpdate                       GeneralizedTime,
     nextUpdate                       GeneralizedTime OPTIONAL,
     supportedChecks                  CertChecks,
     supportedWantBacks               WantBack,
     validationPolicies               SEQUENCE OF OBJECT IDENTIFIER,
     validationAlgs                   SEQUENCE OF OBJECT IDENTIFIER,
     authPolicies                     SEQUENCE OF AuthPolicy,
     responseTypes                    ResponseTypes,
     defaultPolicyValues              RespValidationPolicy,
     revocationInfoTypes              RevocationInfoTypes,
     signatureGeneration              SEQUENCE OF AlgorithmIdentifier,
     signatureVerification            SEQUENCE OF AlgorithmIdentifier,
     hashAlgorithms                   SEQUENCE SIZE (1..MAX) OF
                                        OBJECT IDENTIFIER,
     serverPublicKeys                 SEQUENCE OF KeyAgreePublicKey
                                        OPTIONAL,
     clockSkew                        INTEGER DEFAULT 10,
     requestNonce                     OCTET STRING OPTIONAL }

   ResponseTypes  ::= ENUMERATED {
     cached-only                (0),
     non-cached-only            (1),
     cached-and-non-cached      (2) }

   RevocationInfoTypes ::= BIT STRING {
     fullCRLs                   (0),
     deltaCRLs                  (1),
     indirectCRLs               (2),
     oCSPResponses              (3) }

   AuthPolicy ::= OBJECT IDENTIFIER

   -- SCVP Check Identifiers

   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 }

   -- SCVP WantBack Identifiers

   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}

   -- SCVP Validation Policy and Algorithm Identifiers

   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 }

   -- SCVP Basic Validation Algorithm Identifier

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

   -- SCVP Basic Validation Algorithm Errors

   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 }

   -- SCVP Name Validation Algorithm Identifier

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

   -- SCVP Name Validation Algorithm DN comparison algorithm

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

   -- SCVP Name Validation Algorithm Errors

   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 }

   -- SCVP Extended Key Usage Key Purpose Identifiers

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

   id-kp-scvpServer               OBJECT IDENTIFIER ::= { id-kp 15 }

   id-kp-scvpClient               OBJECT IDENTIFIER ::= { id-kp 16 }

   END

9.  Security Considerations

   For security considerations specific to the Cryptographic Message
   Syntax message formats, see [CMS].  For security considerations
   specific to the process of PKI certification path validation, see
   [PKIX-1].

   A client that trusts a server's response for validation of a
   certificate inherently trusts that server as much as it would trust
   its own validation software.  This means that if an attacker
   compromises a trusted SCVP server, the attacker can change the
   validation processing for every client that relies on that server.
   Thus, an SCVP server must be protected at least as well as the trust
   anchors that the SCVP server trusts.

   Clients MUST verify that the response matches their original request.
   Clients need to ensure that the server has performed the appropriate
   checks for the correct certificates under the requested validation
   policy for the specified validation time, and that the response
   includes the requested wantBacks and meets the client's freshness
   requirements.

   When the SCVP response is used to determine the validity of a
   certificate, the client MUST validate the digital signature or MAC on
   the response to ensure that the expected SCVP server generated it.
   If the client does not check the digital signature or MAC on the
   response, a man-in-the-middle attack could fool the client into
   believing modified responses from the server or responses to
   questions the client did not ask.

   If the client does not include a requestNonce item, or if the client
   does not check that the requestNonce in the response matches the
   value in the request, an attacker can replay previous responses from
   the SCVP server.

   If the server does not require some sort of authorization (such as
   signed requests), an attacker can get the server to respond to
   arbitrary requests.  Such responses may give the attacker information
   about weaknesses in the server or about the timeliness of the
   server's checking.  This information may be valuable for a future
   attack.

   If the server uses the serverContextInfo item to indicate some server
   state associated with a requestor, implementers must take appropriate
   measures against denial-of-service attacks where an attacker sends in
   a lot of requests at one time to force the server to keep a lot of
   state information.

   SCVP does not include any confidentiality mechanisms.  If
   confidentiality is needed, it can be achieved with a lower-layer
   security protocol such as TLS [TLS].

   If an SCVP client is not operating on a network with good physical
   protection, it must ensure that there is integrity over the SCVP
   request-response pair.  The client can ensure integrity by using a
   protected transport such as TLS.  It can ensure integrity by using
   MACs or digital signatures to individually protect the request and
   response messages.

   If an SCVP client populates the userPolicySet in a request with a
   value other than anyPolicy, but does not set the
   requireExplicitPolicy flag, the server may return an affirmative
   answer for paths that do not satisfy any of the specified policies.
   In general, when a client populates the userPolicySet in a request
   with a value other than anyPolicy, the requireExplicitPolicy flag
   should also be set.  This guarantees that all valid paths satisfy at
   least one of the requested policies.

   In SCVP, historical validation of a certificate returns the known
   status of the certificate at the time specified in validationTime.
   This may be used to demonstrate due diligence, but does not
   necessarily provide the most complete information.  A certificate may
   have been revoked after the time specified in validationTime, but the
   revocation notice may specify an invalidity date that precedes the
   validationTime.  The SCVP server would provide an affirmative
   response even though the most current information available indicates
   the certificate should not be trusted at that time.  SCVP clients may
   wish to specify a validationTime later than the actual time of
   interest to mitigate this risk.

10.  IANA Considerations

   The details of SCVP requests and responses are communicated using
   object identifiers (OIDs).  The objects are defined in an arc
   delegated by IANA to the PKIX Working Group.  This document also
   includes four MIME type registrations in Appendix A.  No further
   action by IANA is necessary for this document or any anticipated
   updates.

11.  References

11.1.  Normative References

   [STDWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [CMS]         Housley, R., "Cryptographic Message Syntax (CMS)", RFC
                 3852, July 2004.

   [OCSP]        Myers, M., Ankney, R., Malpani, A., Galperin, S., and
                 C. Adams, "X.509 Internet Public Key Infrastructure
                 Online Certificate Status Protocol - OCSP", RFC 2560,
                 June 1999.

   [PKIX-1]      Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
                 X.509 Public Key Infrastructure Certificate and
                 Certificate Revocation List (CRL) Profile", RFC 3280,
                 April 2002.

   [PKIX-AC]     Farrell, S. and R. Housley, "An Internet Attribute
                 Certificate Profile for Authorization", RFC 3281, April
                 2002.

   [PKIX-ALG]    Bassham, L., Polk, W., and R. Housley, "Algorithms and
                 Identifiers for the Internet X.509 Public Key
                 Infrastructure Certificate and Certificate Revocation
                 List (CRL) Profile", RFC 3279, April 2002.

   [PKIX-ALG2]   Schaad, J., Kaliski, B., and R. Housley, "Additional
                 Algorithms and Identifiers for RSA Cryptography for use
                 in the Internet X.509 Public Key Infrastructure
                 Certificate and Certificate Revocation List (CRL)
                 Profile", RFC 4055, June 2005.

   [UTF8]        Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

   [ESS]         Hoffman, P., Ed., "Enhanced Security Services for
                 S/MIME", RFC 2634, June 1999.

   [SMIME-CERT]  Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
                 Extensions (S/MIME) Version 3.1 Certificate Handling",
                 RFC 3850, July 2004.

   [IKE]         Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
                 Protocol", RFC 4306, December 2005.

   [HTTP]        Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

11.2.  Informative References

   [IKE-GROUPS]  Kivinen, T. and M. Kojo, "More Modular Exponential
                 (MODP) Diffie-Hellman groups for Internet Key Exchange
                 (IKE)", RFC 3526, May 2003.

   [RQMTS]       Pinkas, D. and R. Housley, "Delegated Path Validation
                 and Delegated Path Discovery Protocol Requirements",
                 RFC 3379, September 2002.

   [TLS]         Dierks, T. and E. Rescorla, "The Transport Layer
                 Security (TLS) Protocol Version 1.1", RFC 4346, April
                 2006.

12.  Acknowledgments

   The lively debate in the PKIX Working Group has made a significant
   impact on this protocol.  Special thanks to the following for their
   contributions to this document and diligence in greatly improving it.

   Paul Hoffman
   Phillip Hallam-Baker
   Mike Myers
   Frank Balluffi
   Ameya Talwalkar
   John Thielens
   Peter Sylvester
   Yuriy Dzambasow
   Sean P. Turner
   Wen-Cheng Wang
   Francis Dupont
   Dave Engberg
   Faisal Maqsood

   Thanks also to working group chair Steve Kent for his support and
   help.

Appendix A.  MIME Media Type Registrations

   Four MIME media type registrations are provided in this appendix.

A.1.  application/scvp-cv-request

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/scvp-cv-request

   MIME media type name: application

   MIME subtype name: scvp-cv-request

   Required parameters: None

   Optional parameters: None

   Encoding considerations: Binary

   Security considerations: Carries a request for information.  This
   request may optionally be cryptographically protected.

   Interoperability considerations: None

   Published specification: RFC 5055

   Applications that use this media type: SCVP clients sending
   certificate validation requests

   Additional information:

      Magic number(s): None
      File extension(s): .SCQ
      Macintosh File Type Code(s): None

   Person & email address to contact for further information:
   Ambarish Malpani <ambarish@yahoo.com>

   Intended usage: COMMON

   Restrictions on usage: This media type can be used with any protocol
   that can transport digitally signed objects.

   Author: Ambarish Malpani <ambarish@yahoo.com>

   Change controller: IESG

A.2.  application/scvp-cv-response

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/scvp-cv-response

   MIME media type name: application

   MIME subtype name: scvp-cv-response

   Required parameters: None

   Optional parameters: None

   Encoding considerations: Binary

   Security considerations: The client may require that this response be
   cryptographically protected, or may choose to use a secure transport
   mechanism.  DPD responses may be unprotected, but the client
   validates the information provided in the request.

   Interoperability considerations: None

   Published specification: RFC 5055

   Applications that use this media type: SCVP servers responding to
   certificate validation requests

   Additional information:

      Magic number(s): None
      File extension(s): .SCS
      Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <ambarish@yahoo.com>

   Intended usage: COMMON
   Restrictions on usage: This media type can be used with any protocol
   that can transport digitally signed objects.

   Author: Ambarish Malpani <ambarish@yahoo.com>

   Change controller: IESG

A.3.  application/scvp-vp-request

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/scvp-vp-request

   MIME media type name: application

   MIME subtype name: scvp-vp-request

   Required parameters: None

   Optional parameters: None

   Encoding considerations: Binary

   Security considerations: Carries a request for information.

   Interoperability considerations: None

   Published specification: RFC 5055

   Applications that use this media type: SCVP clients sending
   validation policy requests

   Additional information:

      Magic number(s): None
      File extension(s): .SPQ
      Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <ambarish@yahoo.com>

   Intended usage: COMMON

   Restrictions on usage: None

   Author: Ambarish Malpani <ambarish@yahoo.com>

   Change controller: IESG

A.4.  application/scvp-vp-response

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/scvp-vp-response

   MIME media type name: application

   MIME subtype name: scvp-vp-response

   Required parameters: None

   Optional parameters: None

   Encoding considerations: Binary

   Security considerations: None

   Interoperability considerations: None

   Published specification: RFC 5055

   Applications that use this media type: SCVP servers responding to
   validation policy requests

   Additional information:

      Magic number(s): None
      File extension(s): .SPP
      Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <ambarish@yahoo.com>

   Intended usage: COMMON

   Restrictions on usage: This media type can be used with any protocol
   that can transport digitally signed objects.

   Author: Ambarish Malpani <ambarish@yahoo.com>

   Change controller: IESG

Appendix B.  SCVP over HTTP

   This appendix describes the formatting and transportation conventions
   for the SCVP request and response when carried by HTTP.

   In order for SCVP clients and servers using HTTP to interoperate, the
   following rules apply.

   -  Clients MUST use the POST method to submit their requests.

   -  Servers MUST use the 200 response code for successful responses.

   -  Clients MAY attempt to send HTTPS requests using TLS 1.0 or later,
      although servers are not required to support TLS.

   -  Servers MUST NOT assume client support for any type of HTTP
      authentication such as cookies, Basic authentication, or Digest
      authentication.

   -  Clients and servers are expected to follow the other rules and
      restrictions in [HTTP].  Note that some of those rules are for
      HTTP methods other than POST; clearly, only the rules that apply
      to POST are relevant for this specification.

B.1.  SCVP Request

   An SCVP request using the POST method is constructed as follows:

   The Content-Type header MUST have the value "application/scvp-cv-
   request".

   The body of the message is the binary value of the DER encoding of
   the CVRequest, wrapped in a CMS body as described in Section 3.

B.2.  SCVP Response

   An HTTP-based SCVP response is composed of the appropriate HTTP
   headers, followed by the binary value of the BER encoding of the
   CVResponse, wrapped in a CMS body as described in Section 4.

   The Content-Type header MUST have the value "application/scvp-cv-
   response".

B.3.  SCVP Policy Request

   An SCVP request using the POST method is constructed as follows:

      The Content-Type header MUST have the value "application/scvp-vp-
      request".

   The body of the message is the binary value of the BER encoding of
   the ValPolRequest, wrapped in a CMS body as described in Section 5.

B.4.  SCVP Policy Response

   An HTTP-based SCVP policy response is composed of the appropriate
   HTTP headers, followed by the binary value of the DER encoding of the
   ValPolResponse, wrapped in a CMS body as described in Section 6.  The
   Content-Type header MUST have the value "application/scvp-vp-
   response".

Authors' Addresses

   Trevor Freeman
   Microsoft Corporation,
   One Microsoft Way
   Redmond, WA 98052
   USA.
   EMail: trevorf@microsoft.com

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: housley@vigilsec.com

   Ambarish Malpani
   Malpani Consulting Services
   EMail: ambarish@yahoo.com

   David Cooper
   National Institute of Standards and Technology
   100 Bureau Drive, Mail Stop 8930
   Gaithersburg, MD 20899-8930
   EMail: david.cooper@nist.gov

   Tim Polk
   National Institute of Standards and Technology
   100 Bureau Drive, Mail Stop 8930
   Gaithersburg, MD 20899-8930
   EMail: wpolk@nist.gov

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.