draft-ietf-pkix-scvp-11.txt

PKIX的RFC英文文档

        sid                SignerIdentifier,
        digestAlgorithm    DigestAlgorithmIdentifier,
        signedAttrs        SignedAttributes, -- (Required)
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature          SignatureValue,
        unsignedAttrs      UnsignedAttributes } -- Not used in SCVP

      EncapsulatedContentInfo {
        eContentType       id-ct-scvp-psResponse,
                                    -- (1.2.840.113549.1.9.16.1.11)
        eContent           OCTET STRING } -- Contains CVResponse

   The SCVP server MUST include its own certificate in the certificates
   field within SignedData. Other certificates can also be included. The
   SCVP server MAY also provide one or more CRLs in the crls field
   within SignedData.

   The signedAttrs within SignerInfo MUST include the content-type and
   message-digest attributes defined in [CMS] as well as the
   SigningCertificate attribute as defined in [ESS]. Within the
   SigningCertificate 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
   SigningCertificate attribute is OPTIONAL. The inclusion of policies
   in the SigningCertificate attribute is also OPTIONAL.

   The value of the message-digest attribute in the signedAttrs within
   SignerInfo MAY be used as an identifier of the reponse generated by
   the SCVP server.

   The CVResponse item contains the server response. The CVResponse MUST
   contain the scvpVersion, producedAt, responseStatus, and requestRef
   items. The CVResponse MAY also contain the requestor, responder,
   replyObjects, requestNonce, serverContextInfo, and respExtensions
   optional items. The replyObjects item MUST contain exactly one
   CertReply item for each certificate requested. The requestor and the
   responder items MUST be included if the request included a requestor
   item. The requestNonce item MUST be included if the request included
   a requestNonce item.










Malpani, Housley, & Freeman                                    [Page 19]

INTERNET DRAFT                    SCVP                     December 2002


   The CVResponse MUST have the following syntax:

      CVResponse ::= SEQUENCE {
        scvpVersion           INTEGER,
        producedAt            GeneralizedTime,
        responseStatus        ResponseStatus,
        requestRef            RequestReference,
        requestor         [1] OCTET STRING OPTIONAL,
        responder         [2] OCTET STRING OPTIONAL,
        replyObjects      [3] ReplyObjects OPTIONAL,
        requestNonce      [4] OCTET STRING OPTIONAL,
        serverContextInfo [5] OCTET STRING OPTIONAL,
        respExtensions    [6] Extensions OPTIONAL }

4.1 scvpVersion

   The syntax and semantics of the scvpVersion item is described in
   section 3.1.

4.2 producedAt

   The producedAt item tells the date and time at which the SCVP server
   generated the response. The producedAt item represents the date and
   time in UTC, using the GeneralizedTime type.

   GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu)
   and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even
   where the number of seconds is zero. GeneralizedTime values MUST NOT
   include fractional seconds.

4.3 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 optionally be used to transmit status information. The
   client MAY choose to display the string to the human user. However,
   because there is no way to know the languages understood by the human
   user, the string may be of little or no assistance.









Malpani, Housley, & Freeman                                    [Page 20]

INTERNET DRAFT                    SCVP                     December 2002


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

      ResponseStatus ::= SEQUENCE {
        statusCode            SCVPStatusCode,
        errorMessage      [0] UTF8String OPTIONAL }

      SCVPStatusCode ::= ENUMERATED {
        okay                    (0),
        skipUnrecognizedItems   (1),
        tooBusy                (10),
        badStructure           (20),
        unsupportedVersion     (21),
        abortUnrecognizedItems (22),
        unrecognizedSigKey     (23),
        badSignature           (24),
        unableToDecode         (25),
        notAuthorized          (26),
        unsupportedChecks      (27),
        unsupportedWantBacks   (28),
        unsupportedSignature   (29),
        invalidSignature       (30),
        relayingLoop           (40) }

   The SCVPStatusCode values have the following meaning:

       0  The request was fully processed
       1  The request included some unrecognized items; however,
            processing was able to continue ignoring them
      10  Too busy; try again later
      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 key given in the RequestSignature is not recognized
      24  The signature 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 want back items, and
            the server was not able to continue processing
      29  The server does not support the signature algorithm
            used by the client to sign the request
      30  The server could not validate the client's signature
            on the request
      40  The request was previously relayed by the same server




Malpani, Housley, & Freeman                                    [Page 21]

INTERNET DRAFT                    SCVP                     December 2002


4.4 requestReference

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

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

   When using connectionless protocols, the requestRef item allows the
   client to associate a response with a request. However, the
   requestNonce provides a better 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       [1] HashValue, -- hash of CVRequest
        fullRequest       [2] CVRequest }

4.4.1 requestHash

   The requestHash item is the hash of the CVRequest. By default, SHA-1
   is used as the one-way hash function, but others can be used.  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. However, the requestNonce provides a better
   mechanism for matching requests and responses.

   The requestHash item uses the HashValue type, which has the following
   syntax:

      HashValue ::= SEQUENCE {
        algorithm             AlgorithmIdentifier DEFAULT { 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.




Malpani, Housley, & Freeman                                    [Page 22]

INTERNET DRAFT                    SCVP                     December 2002


4.4.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 PSRequest type are described in section 3.

4.5 requestor

   The OPTIONAL requestor item is used to identify the requestor. The
   value is only of local significance to the requestor. If the SCVP
   client includes a requestor value in the request, then the SCVP
   server MUST return the same value in the response.

   The requestor item MUST be an octet string. No provisions are made to
   ensure uniqueness of the requestor octet string; however, all of the
   octets MUST have values other than zero.

4.6 responder

   The OPTIONAL responder item is used to identify the server. The value
   chosen is only of local significance to the SCVP server. The
   responder items MUST be included if the request included a requestor
   item.

   The responder item MUST be an octet string. No provisions are made to
   ensure uniqueness of the requestor octet string; however, all of the
   octets MUST have values other than zero.

4.7 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, replyWantBack,
   and valPolicy items; and the CertReply item MAY contain the
   nextUpdate and certReplyExtensions optional items.

   A non-error response MUST contain one CertReply for each Query item
   in the request. The order is important. The first CertReply in the
   sequence MUST correspond to the first Query item in the request; the
   second CertReply in the sequence MUST correspond to the second Query
   item in the request; and so on.




Malpani, Housley, & Freeman                                    [Page 23]

INTERNET DRAFT                    SCVP                     December 2002


   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                       ReplyCertificate,
        replyStatus                ReplyStatus,
        replyValTime               GeneralizedTime,
        replyChecks                ReplyChecks,
        replyWantBacks             ReplyWantBacks,
        valPolicy                  ValidationPolicy,
        nextUpdate             [1] GeneralizedTime OPTIONAL,
        certReplyExtensions    [2] Extensions OPTIONAL }

4.7.1 cert

   The cert item contains either the public key certificate or the
   attribute certificate about which the client is requesting
   information.

      ReplyCertificate ::= CHOICE {
        pkc               [1] Certificate,
        ac                [2] AttributeCertificate }

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

4.7.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 than 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.










Malpani, Housley, & Freeman                                    [Page 24]

INTERNET DRAFT                    SCVP                     December 2002


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

      ReplyStatus ::= ENUMERATED {