tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5055

 
 
 

Server-Based Certificate Validation Protocol (SCVP)

Part 3 of 4, p. 36 to 57
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 36 
3.3.  requestorRef

   The optional requestorRef item contains a list of names identifying
   SCVP servers, and it is intended for use in environments where SCVP
   relay is employed.  Although requestorRef is encoded as a SEQUENCE,
   no order is implied.  The requestorRef item is used to detect looping
   in some configurations.  The value and use of requestorRef are
   described in Section 7.

   Conforming SCVP clients MAY support specification of the requestorRef
   value.  Conforming SCVP server implementations MUST process the
   requestorRef value if present.  If the SCVP client includes a
   requestorRef value in the request, then the SCVP server MUST return
   the same value in a non-cached response.  The SCVP server MAY omit
   the requestorRef value from cached SCVP responses.

   The requestorRef item MUST be a sequence of GeneralName.  No
   provisions are made to ensure uniqueness of the requestorRef
   GeneralName values.

3.4.  requestNonce

   The optional requestNonce item contains a request identifier
   generated by the SCVP client.  If the client includes a requestNonce
   value in the request, it is expressing a preference that the SCVP
   server SHOULD return a non-cached response.  If the server returns a
   non-cached response, it MUST include the value of requestNonce from
   the request in the response as the respNonce item; however, the
   server MAY return a cached response which MUST NOT have a respNonce.

   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.  Conforming SCVP server implementations
   MUST process the requestNonce value if present.

   If the client includes a requestNonce and also sets the
   cachedResponse flag to FALSE as described in Section 3.2.5.4, the
   client is indicating that the SCVP server MUST return either a non-
   cached response including the respNonce or an error response.  The
   client SHOULD include a requestNonce item in every request to prevent

Top      Up      ToC       Page 37 
   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 client MUST NOT set the cachedResponse flag to FALSE without also
   including a requestNonce.  A server receiving such a request SHOULD
   return an invalidRequest error response.

   The requestNonce item, if present, MUST be an OCTET STRING that was
   generated exclusively for this request.

3.5.  requestorName

   The optional requestorName item is used by the client to include an
   identifier in the request.  The client MAY include this information
   for the DPV server to copy into the response.

   Conforming SCVP clients MAY support specification of this item in
   requests.  SCVP servers MUST be able to process requests that include
   this item.

3.6.  responderName

   The optional responderName item is used by the client to indicate the
   identity of the SCVP server that the client expects to sign the SCVP
   response if the response is digitally signed.  The responderName item
   SHOULD only be included if:

   1. the request is either unprotected or digitally signed (i.e., is
      not protected using a MAC), and

   2. the responseFlags item is either absent or present with the
      protectResponse set to TRUE.

   Conforming SCVP clients MAY support specification of this item in
   requests.  SCVP servers MUST be able to process requests that include
   this item.  SCVP servers that maintain a single private key for
   signing SCVP responses or that are unable to return digitally signed
   responses MAY ignore the value in this item.  SCVP servers that
   maintain more than one private key for signing SCVP responses SHOULD
   either (a) digitally sign the response using a private key that
   corresponds to a certificate that includes the name specified in
   responderName in either subject field or subjectAltName extension or
   (b) return a error indicating that the server does not possess a
   certificate that asserts the specified name.

Top      Up      ToC       Page 38 
3.7.  requestExtensions

   The OPTIONAL requestExtensions 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 SCVP.  The syntax
   for Extensions is imported from [PKIX-1].  The requestExtensions
   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.7.1.  extnID

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

3.7.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 it
   does not recognize.  A non-critical extension MAY be ignored if it is
   not recognized, but MUST be processed if it is recognized.

3.7.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.

3.8.  signatureAlg

   The signatureAlg item contains an AlgorithmIdentifier indicating
   which algorithm the server should use to sign the response message.
   The signatureAlg item SHOULD only be included if:

   1. the request is either unprotected or digitally signed (i.e., is
      not protected using a MAC), and

   2. the responseFlags item is either absent or present with the
      protectResponse set to TRUE.

   If included, the signatureAlg item SHOULD specify one of the
   signature algorithms specified in the signatureGeneration item of the
   server's validation policy response message.

Top      Up      ToC       Page 39 
   SCVP servers MUST be able to process requests that include this item.
   If the server is returning a digitally signed response to this
   message, then:

   1. If the signatureAlg item is present and specifies an algorithm
      that is included in the signatureGeneration item of the server's
      validation policy response message, the server MUST sign the
      response using the signature algorithm specified in signatureAlg.

   2. Otherwise, if the signatureAlg item is absent or is present but
      specifies an algorithm that is not supported by the server, the
      server MUST sign the response using the server's default signature
      algorithm as specified in the signatureGeneration item of the
      server's validation policy response message.

3.9.  hashAlg

   The hashAlg item contains an object identifier indicating which hash
   algorithm the server should use to compute the hash value for the
   requestHash item in the response.  SCVP clients SHOULD NOT include
   this item if fullRequestInResponse is set to TRUE.  If included, the
   hashAlg item SHOULD specify one of the hash algorithms specified in
   the hashAlgorithms item of the server's validation policy response
   message.

   SCVP servers MUST be able to process requests that include this item.
   If the server is returning a response to this message that includes a
   requestHash, then:

   1. If the hashAlg item is present and specifies an algorithm that is
      included in the hashAlgorithms item of the server's validation
      policy response message, the server MUST use the algorithm
      specified in hashAlg to compute the requestHash.

   2. Otherwise, if the hashAlg item is absent or is present but
      specifies an algorithm that is not supported by the server, the
      server MUST compute the requestHash using the server's default
      hash algorithm as specified in the hashAlgorithms item of the
      server's validation policy response message.

3.10.  requestorText

   SCVP clients MAY use the requestorText item to provide text for
   inclusion in the corresponding response.  For example, this field may
   describe the nature or reason for the request.

Top      Up      ToC       Page 40 
   Conforming SCVP client implementations MAY support inclusion of this
   item in requests.  Conforming SCVP server implementations MUST accept
   requests that include this item.  When generating non-cached
   responses, conforming SCVP server implementations MUST copy the
   contents of this item into the requestorText item in the
   corresponding response (see Section 4.13).

3.11.  SCVP Request Authentication

   It is a matter of local policy what validation policy the server uses
   when authenticating requests.  When authenticating protected SCVP
   requests, the SCVP servers SHOULD use the validation algorithm
   defined in Section 6 of [PKIX-1].

   If the certificate used to validate a SignedData validation request
   includes 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 used to validate an AuthenticatedData validation
   request includes the key usage extension, it MUST have the key
   agreement bit set.

   If the certificate used on a validation request contains the extended
   key usage extension ([PKIX-1], Section 4.2.1.13), the server SHALL
   verify that it contains the SCVP client OID, the anyExtendedKeyUsage
   OID, or another OID acceptable to the server.  The SCVP client OID is
   defined as follows:

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

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

   If a protected request fails to meet the validation policy of the
   server, it MUST be treated as an unauthenticated request.

4.  Validation Response

   An SCVP server response to the client MUST be a single CVResponse
   item.  When a CVResponse is encapsulated in a MIME body part,
   application/scvp-cv-response MUST be used.

   There are a number of forms of an SCVP response:

   1. A success response to a request that has protectResponse set to
      FALSE.  These responses SHOULD NOT be protected by the server.

Top      Up      ToC       Page 41 
   2. The server MUST protect all other success responses.  If the
      server is unable to return a protected success response due to
      local policy, then it MUST return an error response.

   3. An error response to a request made over a protected transport
      such as TLS.  These responses SHOULD NOT be protected by the
      server.

   4. An error response to a request that has protectResponse set to
      FALSE.  These responses SHOULD NOT be protected by the server.

   5. An error response to an authenticated request.  The server SHOULD
      protect these responses.

   6. An error response to an AuthenticatedData request where MAC is
      valid.  The server MUST protect these responses.

   7. All other error responses MUST NOT be protected by the server.

   Successful responses are made when the server has fully complied with
   the request.  That is, the server was able to attempt to build a
   certification path using the referenced or supplied validation
   policy, and it was able to comply with all the requested parameters.
   If the server is unable to perform validations using the required
   validation policy or the request contains an unsupported option, then
   the server MUST return an error response.

   For protected requests and responses, SCVP servers MUST support
   SignedData and SHOULD support AuthenticatedData.  It is a matter of
   local policy which types are used.  Where a protected response is
   required, SCVP servers MUST use SignedData or AuthenticatedData, even
   if the transaction is performed using a protected transport (e.g.,
   TLS).

   If the server is making a protected response to a protected request,
   then the server MUST use the same protection mechanism (SignedData or
   AuthenticatedData) as in the request.

   An overview of the structure used for an unprotected 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 }

Top      Up      ToC       Page 42 
   The protected response consists of a CVResponse encapsulated in
   either a SignedData or an 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-certValResponse and an
   eContent field that contains a DER-encoded CVResponse.

   The SCVP server MUST include its own certificate in the certificates
   field within SignedData.  Other certificates MAY also be included.

   The SCVP server MAY also provide one or more CRLs in the crls field
   within SignedData.  The signerInfos field of SignedData MUST include
   exactly one SignerInfo.  The SignedData MUST NOT include the
   unsignedAttrs field.

   The signedAttrs field within SignerInfo MUST include the content-type
   and message-digest attributes defined in [CMS], and it SHOULD include
   the signing-certificate attribute as defined in [ESS].  Within the
   signing-certificate attribute, the first certificate identified in
   the sequence of certificate identifiers MUST be the certificate of
   the SCVP server.  The inclusion of other certificate identifiers in
   the signing-certificate attribute is OPTIONAL.  The inclusion of
   policies in the signing-certificate is OPTIONAL.

   The recipientInfos field of AuthenticatedData MUST include exactly
   one RecipientInfo, which contains information for the client that
   sent the request.  The AuthenticatedData MUST NOT include the
   unauthAttrs field.

   The CVResponse item contains the server's response.  The CVResponse
   MUST contain the cvResponseVersion, serverConfigurationID,
   producedAt, and responseStatus items.  The CVResponse MAY also
   contain the respValidationPolicy, requestRef, requestorRef,
   requestorName, replyObjects, respNonce, serverContextInfo, and
   cvResponseExtensions items.  The replyObjects item MUST contain
   exactly one CertReply item for each certificate requested.  The
   requestorRef item MUST be included if the request included a
   requestorRef item and a non-cached response is provided.  The
   respNonce item MUST be included if the request included a
   requestNonce item and a non-cached response is provided.

Top      Up      ToC       Page 43 
   The CVResponse MUST have the following syntax:

      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 }

   Conforming SCVP servers MAY be capable of constructing a CVResponse
   that includes the serverContextInfo or cvResponseExtensions items.
   Conforming SCVP servers MUST be capable of constructing a CVResponse
   with any of the remaining optional items.  Conforming SCVP clients
   MUST be capable of processing a CVResponse with the following
   optional items: respValidationPolicy, requestRef, requestorName,
   replyObjects, and respNonce.

   Conforming SCVP clients that are capable of including requestorRef in
   a request MUST be capable of processing a CVResponse that includes
   the requestorRef item.  Conforming SCVP clients MUST be capable of
   processing a CVResponse that includes the serverContextInfo or
   cvResponseExtensions items.  Conforming clients MUST be able to
   determine if critical extensions are present in the
   cvResponseExtensions item.

4.1.  cvResponseVersion

   The syntax and semantics of cvResponseVersion are the same as
   cvRequestVersion as described in Section 3.1.  The cvResponseVersion
   MUST match the cvRequestVersion in the request.  If the server cannot
   generate a response with a matching version number, then the server
   MUST return an error response that indicates the highest version
   number that the server supports as the version number.

4.2.  serverConfigurationID

   The server configuration ID item represents the version of the SCVP
   server configuration when it processed the request.  See Section 6.4
   for details.

Top      Up      ToC       Page 44 
4.3.  producedAt

   The producedAt item tells the date and time at which the SCVP server
   generated the response.  The producedAt item MUST be expressed in
   UTC, and it MUST be interpreted as defined in Section 3.2.7.  This
   value is independent of the validation time.

4.4.  responseStatus

   The responseStatus item gives status information to the SCVP client
   about its request.  The responseStatus item has a numeric status code
   and an optional string that is a sequence of characters from the
   ISO/IEC 10646-1 character set encoded with the UTF-8 transformation
   format defined in [UTF8].

   The string MAY be used to transmit status information.  The client
   MAY choose to display the string to a human user.  However, because
   there is often no way to know the languages understood by a human
   user, the string may be of little or no assistance.

   The responseStatus item uses the ResponseStatus type, which has the
   following syntax:

      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),

Top      Up      ToC       Page 45 
        unrecognizedValAlg                (51),
        fullRequestInResponseUnsupported  (52),
        fullPolResponseUnsupported        (53),
        inhibitPolicyMappingUnsupported   (54),
        requireExplicitPolicyUnsupported  (55),
        inhibitAnyPolicyUnsupported       (56),
        validationTimeUnsupported         (57),
        unrecognizedCritQueryExt          (63),
        unrecognizedCritRequestExt        (64) }

   The CVStatusCode values have the following meaning:

    0 The request was fully processed.
    1 The request included some unrecognized non-critical extensions;
      however, processing was able to continue ignoring them.
   10 Too busy; try again later.
   11 The server was able to decode the request, but there was some
      other problem with the request.
   12 An internal server error occurred.
   20 The structure of the request was wrong.
   21 The version of request is not supported by this server.
   22 The request included unrecognized items, and the server was not
      able to continue processing.
   23 The server could not validate the key used to protect the
      request.
   24 The signature or message authentication code did not match the
      body of the request.
   25 The encoding was not understood.
   26 The request was not authorized.
   27 The request included unsupported checks items, and the server was
      not able to continue processing.
   28 The request included unsupported wantBack items, and the server
      was not able to continue processing.
   29 The server does not support the signature or message
      authentication code algorithm used by the client to protect the
      request.
   30 The server could not validate the client's signature or message
      authentication code on the request.
   31 The server could not generate a protected response as requested
      by the client.
   32 The server does not have a certificate matching the requested
      responder name.
   40 The request was previously relayed by the same server.
   50 The request contained an unrecognized validation policy
      reference.
   51 The request contained an unrecognized validation algorithm OID.
   52 The server does not support returning the full request in the
      response.

Top      Up      ToC       Page 46 
   53 The server does not support returning the full validation policy
      by value in the response.
   54 The server does not support the requested value for inhibit
      policy mapping.
   55 The server does not support the requested value for require
      explicit policy.
   56 The server does not support the requested value for inhibit
      anyPolicy.
   57 The server only validates requests using current time.
   63 The query item in the request contains a critical extension whose
      OID is not recognized.
   64 The request contains a critical request extension whose OID is
      not recognized.

   Status codes 0-9 are reserved for codes that indicate the request was
   processed by the server and therefore MUST be sent in a success
   response.  Status codes 10 and above indicate an error and MUST
   therefore be sent in an error response.

4.5.  respValidationPolicy

   The respValidationPolicy item contains either a reference to the full
   validation policy or the full policy by value used by the server to
   validate the request.  It MUST be present in success responses and
   MUST NOT be present in error responses.  The choice between returning
   the policy by reference or by value is controlled by the
   responseValidationPolByRef item in the request.  The resultant
   validation policy is the union of the following:

   1. Values from the request.

   2. For values that are not explicitly included in the request, values
      from the validation policy specified by reference in the request.

   The RespValidationPolicy syntax is:

      RespValidationPolicy ::= ValidationPolicy

   The validationPolicy item is defined in Section 3.2.4.  When
   responseValidationPolByRef is set to FALSE in the request, all items
   in the validationPolicy item MUST be populated.  When
   responseValidationPolByRef is set to TRUE, OPTIONAL items in the
   validationPolicy item only need to be populated for items for which
   the value in the request differs from the value from the referenced
   validation policy.

Top      Up      ToC       Page 47 
   Conforming SCVP clients MUST be capable of processing the validation
   policy by reference.  SCVP clients MAY be capable of processing the
   optional items in the validation policy.

   Conforming SCVP server implementations MUST be capable of asserting
   the policy by reference, and MUST be capable of including the
   optional items.

4.6.  requestRef

   The requestRef item allows the SCVP client to identify the request
   that corresponds to this response from the server.  It associates the
   response to a particular request using either a hash of the request
   or a copy of CVRequest from the request.

   The requestRef item does not provide authentication, but does allow
   the client to determine that the request was not maliciously
   modified.

   The requestRef item allows the client to associate a response with a
   request.  The requestNonce provides an alternative mechanism for
   matching requests and responses.  When the fullRequest alternative is
   used, the response provides a single data structure that is suitable
   for archive of the transaction.

   The requestRef item uses the RequestReference type, which has the
   following syntax:

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

   SCVP clients MUST support requestHash, and they MAY support
   fullRequest.  SCVP servers MUST support using requestHash, and they
   SHOULD support using fullRequest.

4.6.1.  requestHash

   The requestHash item is the hash of the CVRequest.  The one-way hash
   function used to compute the hash of the CVRequest is as specified in
   Section 3.9.  The requestHash item serves two purposes.  First, it
   allows a client to determine that the request was not maliciously
   modified.  Second, it allows the client to associate a response with
   a request when using connectionless protocols.  The requestNonce
   provides an alternative mechanism for matching requests and
   responses.

Top      Up      ToC       Page 48 
   The requestHash item uses the HashValue type, which has the following
   syntax:

      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 }

   The algorithm identifier for SHA-1 is imported from [PKIX-ALG].  It
   is repeated here for convenience.

4.6.2.  fullRequest

   Like requestHash, the fullRequest alternative allows a client to
   determine that the request was not maliciously modified.  It also
   provides a single data structure that is suitable for archive of the
   transaction.

   The fullRequest item uses the CVRequest type.  The syntax and
   semantics of the CVRequest type are described in Section 3.

4.7.  requestorRef

   The optional requestorRef item is used by the client to identify the
   original requestor in cases where SCVP relay is used.  The value is
   only of local significance to the client.  If the SCVP client
   includes a requestorRef value in the request, then the SCVP server
   MUST return the same value if the server is generating a non-cached
   response.

4.8.  requestorName

   The optional requestorName item is used by the server to return one
   or more identities associated with the client in the response.

   The SCVP server MAY choose to include any or all of the following:

   (1) the identity asserted by the client in the requestorName item of
      the request,

   (2) an authenticated identity for the client from a certificate or
      other credential used to authenticate the request, or

   (3) a client identifier from an out-of-band mechanism.

   Alternatively, the SCVP server MAY omit this item.

Top      Up      ToC       Page 49 
   In the case of non-cached responses to authenticated requests, the
   SCVP server SHOULD return a requestor name.

   SCVP servers that support authenticated requests SHOULD support this
   item.

   SCVP clients MUST be able to process responses that include this
   item, although the item value might not impact the processing in any
   manner.

4.9.  replyObjects

   The replyObjects item returns requested objects to the SCVP client,
   each of which tells the client about a single certificate from the
   request.  The replyObjects item MUST be present in the response,
   unless the response is reporting an error.  The CertReply item MUST
   contain cert, replyStatus, replyValTime, replyChecks, and
   replyWantBacks items, and the CertReply item MAY contain the
   validationErrors, nextUpdate, and certReplyExtensions items.

   A success response MUST contain one CertReply for each certificate
   specified in the queriedCerts item in the request.  The order is
   important.  The first CertReply in the sequence MUST correspond to
   the first certificate in the request, the second CertReply in the
   sequence MUST correspond to the second certificate in the request,
   and so on.

   The checks item in the request determines the content of the
   replyChecks item in the response.  The wantBack item in the request
   determines the content of the replyWantBacks item in the response.
   The queryExtensions items in the request controls the absence or the
   presence and content of the certReplyExtensions item in the response.

   The replyObjects item uses the ReplyObjects type, which has the
   following syntax:

      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 }

Top      Up      ToC       Page 50 
4.9.1.  cert

   The cert item contains either the certificate or a reference to the
   certificate about which the client is requesting information.  If the
   certificate was specified by reference in the request, the request
   included either the id-swb-pkc-cert or id-swb-aa-cert wantBack, and
   the server was able to obtain the referenced certificate, then this
   item MUST include the certificate.  Otherwise, this item MUST include
   the same value as was used in the queriedCerts item in the request.

   CertReference has the following syntax:

      CertReference ::= CHOICE {
        pkc                   PKCReference,
        ac                    ACReference }

4.9.2.  replyStatus

   The replyStatus item gives status information to the client about the
   request for the specific certificate.  Note that the responseStatus
   item is different from the replyStatus item.  The responseStatus item
   is the status of the whole request, while the replyStatus item is the
   status for the individual query item.

   The replyStatus item uses the ReplyStatus type, which has the
   following syntax:

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

   The meanings of the various ReplyStatus values are:

   0 Success: all checks were performed successfully.
   1 Failure: the public key certificate was malformed.
   2 Failure: the attribute certificate was malformed.
   3 Failure: historical data for the requested validation time is not
      available.
   4 Failure: the server could not locate the reference certificate or
      the referenced certificate did not match the hash value provided.
   5 Failure: no certification path could be constructed.

Top      Up      ToC       Page 51 
   6 Failure: the constructed certification path is not valid with
      respect to the validation policy.
   7 Failure: the constructed certification path is not valid with
      respect to the validation policy, but a query at a later time may
      be successful.
   8 Failure: all checks were performed successfully; however, one or
      more of the wantBacks could not be satisfied.

   Codes 1 and 2 are used to tell the client that the request was
   properly formed, but the certificate in question was not.  This is
   especially useful to clients that do not parse certificates.

   Code 7 is used to tell the client that a valid certification path was
   found with the exception that a certificate in the path is on hold,
   current revocation information is unavailable, or the validation time
   precedes the notBefore time in one or more certificates in the path.

   For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items
   are not populated (i.e., they MUST be an empty sequence).  For codes
   5, 6, 7, and 8, replyChecks MUST include an entry corresponding to
   each check in the request; the replyWantBacks item is not populated.

4.9.3.  replyValTime

   The replyValTime item tells the time at which the information in the
   CertReply was correct.  The replyValTime item represents the date and
   time in UTC, using GeneralizedTime type.  The encoding rules for
   GeneralizedTime in Section 3.2.7 MUST be used.

   Within the request, the optional validationTime item 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 respond as if the client provided the date and time at which the
   server processes the request.

   The information in the CertReply item MUST be formatted as if the
   server created this portion of the response at the time indicated in
   the validationTime item of the query.  However, if the server does
   not have appropriate historical information, the server MAY either
   return an error or return information for a later time.

4.9.4.  replyChecks

   The replyChecks item contains the responses to the checks item in the
   query.  The replyChecks item includes the object identifier (OID)
   from the query and an integer.  The value of the integer indicates
   whether the requested check was successful.  The OIDs in the checks
   item of the query are used to identify the corresponding replyChecks

Top      Up      ToC       Page 52 
   values.  Each OID specified in the checks item in the request MUST be
   matched by an OID in the replyChecks item of the response.  In the
   case of an error response, the server MAY include additional checks
   in the response to further explain the error.  Clients MUST ignore
   any unrecognized ReplyCheck included in the response.

   The replyChecks item uses the ReplyChecks type, which has the
   following syntax:

      ReplyChecks ::= SEQUENCE OF ReplyCheck

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

   The status value for public key certification path building to a
   trusted root, { id-stc 1 }, can be one of the following:

      0: Built a path
      1: Could not build a path

   The status value for public key certification path building to a
   trusted root along with simple validation processing, { id-stc 2 },
   can be one of the following:

      0: Valid
      1: Not valid

   The status value for public key certification path building to a
   trusted root along with complete status checking, { id-stc 3 }, can
   be one of the following:

      0: Valid
      1: Not valid
      2: Revocation off-line
      3: Revocation unavailable
      4: No known source for revocation information

   Revocation off-line means that the server or distribution point for
   the revocation information was connected to successfully without a
   network error but either no data was returned or if data was returned
   it was stale.  Revocation unavailable means that a network error was
   returned when an attempt was made to reach the server or distribution
   point.  No known source for revocation information means that the
   server was able to build a valid certification path but was unable to
   locate a source for revocation information for one or more
   certificates in the path.

Top      Up      ToC       Page 53 
   The status value for AC issuer certification path building to a
   trusted root, { id-stc 4 }, can be one of the following:

      0: Built a path
      1: Could not build a path

   The status value for AC issuer certification path building to a
   trusted root along with simple validation processing, { id-stc 5 },
   can be one of the following:

      0: Valid
      1: Not valid

   The status value for AC issuer certification path building to a
   trusted root along with complete status checking, { id-stc 6 }, can
   be one of the following:

      0: Valid
      1: Not valid
      2: Revocation off-line
      3: Revocation unavailable
      4: No known source for revocation information

   The status value for revocation status checking of an AC as well as
   AC issuer certification path building to a trusted root along with
   complete status checking, { id-stc 7 }, can be one of the following:

      0: Valid
      1: Not valid
      2: Revocation off-line
      3: Revocation unavailable
      4: No known source for revocation information

4.9.5.  replyWantBacks

   The replyWantBacks item contains the responses to the wantBack item
   in the request.  The replyWantBacks item includes the object
   identifier (OID) from the wantBack item in the request and an OCTET
   STRING.  Within the OCTET STRING is the requested value.  The OIDs in
   the wantBack item in the request are used to identify the
   corresponding reply value.  The OIDs in the replyWantBacks item MUST
   match the OIDs in the wantBack item in the request.  For a non-error
   response, replyWantBacks MUST include exactly one ReplyWantBack for
   each wantBack specified in the request (excluding id-swb-pkc-cert and
   id-swb-ac-cert, where the requested information is included in the
   cert item).

Top      Up      ToC       Page 54 
   The replyWantBacks item uses the ReplyWantBacks type, which has the
   following syntax:

      ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

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

   The OCTET STRING value for the certification path used to verify the
   certificate in the request, { id-swb 1 }, contains the CertBundle
   type.  The syntax and semantics of the CertBundle type are described
   in Section 3.2.8.  This CertBundle includes all the certificates in
   the path, starting with the end certificate and ending with the
   certificate issued by the trust anchor.

   The OCTET STRING value for the proof of revocation status,
   { id-swb 2 }, contains the RevInfoWantBack type.  The RevInfoWantBack
   type is a SEQUENCE of the RevocationInfos type and an optional
   CertBundle.  The syntax and semantics of the RevocationInfos type are
   described in Section 3.2.9.  The CertBundle MUST be included if any
   certificates required to validate the revocation information were not
   returned in the id-swb-pkc-best-cert-path or
   id-swb-pkc-all-cert-paths wantBack.  The CertBundle MUST include all
   such certificates, but there are no ordering requirements.

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

   The OCTET STRING value for the public key information, { id-swb 4 },
   contains the SubjectPublicKeyInfo type.  The syntax and semantics of
   the SubjectPublicKeyInfo type are described in [PKIX-1].

   The OCTET STRING value for the AC issuer certification path used to
   verify the certificate in the request, { id-swb 5 }, contains the
   CertBundle type.  The syntax and semantics of the CertBundle type are
   described in Section 3.2.8.  This CertBundle includes all the
   certificates in the path, beginning with the AC issuer certificate
   and ending with the certificate issued by the trust anchor.

   The OCTET STRING value for the proof of revocation status of the AC
   issuer certification path, { id-swb 6 }, contains the RevInfoWantBack
   type.  The RevInfoWantBack type is a SEQUENCE of the RevocationInfos
   type and an optional CertBundle.  The syntax and semantics of the
   RevocationInfos type are described in Section 3.2.9.  The CertBundle

Top      Up      ToC       Page 55 
   MUST be included if any certificates required to validate the
   revocation information were not returned in the id-aa-cert-path
   wantBack.  The CertBundle MUST include all such certificates, but
   there are no ordering requirements.

   The OCTET STRING value for the proof of revocation status of the
   attribute certificate, { id-swb 7 }, contains the RevInfoWantBack
   type.  The RevInfoWantBack type is a SEQUENCE of the RevocationInfos
   type and an optional CertBundle.  The syntax and semantics of the
   RevocationInfos type are described in Section 3.2.9.  The CertBundle
   MUST be included if any certificates required to validate the
   revocation information were not returned in the id-swb-aa-cert-path
   wantBack.  The CertBundle MUST include all such certificates, but
   there are no ordering requirements.

   The OCTET STRING value for returning all paths, { id-swb 12 },
   contains an ASN.1 type CertBundles, as defined below.  The syntax and
   semantics of the CertBundle type are described in Section 3.2.8.
   Each CertBundle includes all the certificates in one path, starting
   with the end certificate and ending with the certificate issued by
   the trust anchor.

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

   The OCTET STRING value for relayed responses, { id-swb 9 }, contains
   an ASN.1 type SCVPResponses, as defined below.  If the SCVP server
   used information obtained from other SCVP servers when generating
   this response, then SCVPResponses MUST include each of the SCVP
   responses received from those servers.  If the SCVP server did not
   use information obtained from other SCVP servers when generating the
   response, then SCVPResponses MUST be an empty sequence.

      SCVPResponses ::= SEQUENCE OF ContentInfo

   The OCTET STRING value for the proof of revocation status of the
   path's target certificate, { id-swb-13 }, contains the
   RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE of the
   RevocationInfos type and an optional CertBundle.  The syntax and
   semantics of the RevocationInfos type are described in Section 3.2.9.
   The CertBundle MUST be included if any certificates required to
   validate the revocation information were not returned in the id-swb-
   pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack.  The
   CertBundle MUST include all such certificates, but there are no
   ordering requirements.

   The OCTET STRING value for the proof of revocation status of the
   intermediate certificates in the path, { id-swb 14 }, contains the
   RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE of the

Top      Up      ToC       Page 56 
   RevocationInfos type and an optional CertBundle.  The syntax and
   semantics of the RevocationInfos type are described in Section 3.2.9.
   The CertBundle MUST be included if any certificates required to
   validate the revocation information were not returned in the id-swb-
   pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack.  The
   CertBundle MUST include all such certificates, but there are no
   ordering requirements.

4.9.6.  validationErrors

   The validationErrors item MUST only be present in failure responses.
   If present, it MUST contain one or more OIDs representing the reason
   the validation failed (validation errors for the basic validation
   algorithm and name validation algorithm are defined in Sections
   3.2.4.2.2 and 3.2.4.2.4).  The validationErrors item SHOULD only be
   included when the replyStatus is 3, 5, 6, 7, or 8.  SCVP servers are
   not required to specify all of the reasons that validation failed.
   SCVP clients MUST NOT assume that the OIDs included in
   validationErrors represent all of the validation errors for the
   certification path.

4.9.7.  nextUpdate

   The nextUpdate item tells the time at which the server expects a
   refresh of information regarding the validity of the certificate to
   become available.  The nextUpdate item is especially interesting if
   the certificate revocation status information is not available or the
   certificate is suspended.  The nextUpdate item represents the date
   and time in UTC, using the GeneralizedTime type.  The encoding rules
   for GeneralizedTime in Section 3.2.7 MUST be used.

4.9.8.  certReplyExtensions

   The certReplyExtensions item contains the responses to the
   queryExtensions item in the request.  The certReplyExtensions item
   uses the Extensions type defined in [PKIX-1].  The object identifiers
   (OIDs) in the queryExtensions item in the request are used to
   identify the corresponding reply values.  The certReplyExtensions
   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
   OID that names the extension, and it MUST match one of the OIDs in
   the queryExtensions item in the request.

   The critical item is a BOOLEAN, and it MUST be set to FALSE.

Top      Up      ToC       Page 57 
   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.



(page 57 continued on part 4)

Next RFC Part