draft-ietf-pkix-scvp-11.txt

PKIX的RFC英文文档

   change any items other than:

      - requestNonce;

      - serverContextInfo; and

      - the client's signature on the request

3.2.5 valPolicy

   The valPolicy item, when present, defines the validation policy to be
   used by the SCVP server during certificate validation. The client can
   use this option instead of specifying other SCVP configuration items
   such as trustAnchors. The value of this item is determined by private
   agreement between the client and the server, but it MUST be
   represented as an object identifier. The server might want to assign
   identifiers that indicate that some settings are used in addition to
   others given in the request. In this way, the validation policy
   object identifier can be a shorthand for some SCVP options, but not
   others.

   The valPolicy item uses the ValidationPolicy type, which has the
   following syntax:

      ValidationPolicy ::= SEQUENCE {
        valPolicyId           OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valPolicyId OPTIONAL }

   If no validation policy is specified in the request, then the SCVP
   server's default validation policy is used. The default validation
   policy may also be explicitly specified. The object identifier to
   identify the default validation policy is:

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

      id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }













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


   The meaning of the default validation policy is:

      - Trust anchors will come from the trustAnchors item. If no
        certificates are specified in the trustAnchors item, then
        the SCVP server will use trust anchors of its own choosing.

      - The acceptable policy set will come from the certPolicies
        item associated with the selected trust anchor. If no
        certificate policies are specified in the certPolicies item,
        then the SCVP server will use any-policy.

      - The SCVP server will check for certificate revocation using
        CRLs, delta CRLs, OCSP responses, or any other source of
        revocation information that is available.

3.2.6 validityTime

   The OPTIONAL validityTime item tells the date and time relative to
   which the SCVP client wants the server to perform the checks. If the
   validityTime is present, it MUST be encoded as GeneralizedTime. If
   the validityTime is not present, the server MUST respond as if the
   client provided the date and time at which the server processes the
   request.

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

   The information in the corresponding CertReply item in the response
   MUST be formatted as if the server created the response at the time
   indicated in the validityTime. However, if the server does not have
   appropriate historical information, the server MUST return an error.

3.2.7 trustAnchors

   The OPTIONAL trustAnchors item specifies the trust anchors to be used
   by the SCVP server. One or more certificate policy MAY be associated
   with each trust anchor. If a trustAnchors item is present, the server
   MUST NOT use any certification path trust anchors other than those
   provided.

   The TrustAnchors type contains one or more trust anchor
   specification. A certificate reference can be used to identify the
   trust anchor distinguished name, public key algorithm, associated
   public key parameters, if needed, and the trusted public key.
   Alternatively, these items can be provided directly. The order of
   trust anchor specifications within the sequence is not important.



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


   The OPTIONAL certPolicies item specifies a list of policy identifiers
   that the SCVP server MUST use when forming and validating a
   certification path that terminates at the associated trust anchor. If
   certPolicies is not specified, then any-policy MUST be used.

   The trust anchor itself, regardless of its form, MUST NOT be included
   in any certification path constructed by the SCVP server.

   TrustAnchors has the following syntax:

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

      TrustAnchor ::= SEQUENCE {
        anchor                  TrustAnchorInfo,
        certPolicies        [1] SEQUENCE SIZE (1..MAX) OF
                                OBJECT IDENTIFIER OPTIONAL }
                                -- if absent, use any-policy

      TrustAnchorInfo ::= CHOICE {
        certRef                 PKCReference,
        rawInfo             [3] RawTrustAnchorInfo }

      RawTrustAnchorInfo ::= SEQUENCE {
        name                    Name,
        algorithm               AlgorithmIdentifier,
        pubKey                  BIT STRING }

3.2.8 intermediateCerts

   The OPTIONAL intermediateCerts item helps the SCVP server create
   valid certification paths. The intermediateCerts item, when present,
   provides certificates that the server MAY use when forming a
   certification path. The certificates in the intermediateCerts item
   MAY be used by the server in addition to any other certificates that
   the server can access when building certification paths. The
   intermediateCerts item, when present, MUST contain at least one
   certificate. The intermediateCerts item MUST be structured as a
   CertBundle. The certificates in the intermediateCerts MUST NOT be
   trusted by the server just because they are present in this item.

   The CertBundle type contains one or more certificate references. The
   order of the entries in the bundle is not important. CertBundle has
   the following syntax:

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






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


3.2.9 revInfos

   The OPTIONAL revInfo item specifies revocation information such as
   CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP
   server MAY use when validating certification paths. The purpose of
   the revInfos item is to provide revocation information to which the
   server might not otherwise have access (for example, an OCSP response
   that the client received along with the certificate). Note that the
   information in the revInfos item might not be used by the server. For
   example, the revocation information might be associated with
   certificates that the server does not use in certification path
   building.

   It is courteous to the SCVP server to separate CRLs and delta CRLs.
   However, since the two share a common syntax, SCVP servers SHOULD
   accept delta CRLs even if they are identified as regular CRLs by the
   SCVP client.

   CRLs, delta CRLs, and OCSP responses can be provided as revocation
   information. If needed, additional object identifiers can be assigned
   for additional revocation information types in the future.

   The revInfos item uses the RevocationInfos type, which has the
   following syntax:

      RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo

      RevocationInfo ::= SEQUENCE {
        riType                OBJECT IDENTIFIER,
        riValue               ANY DEFINED BY riType }

   The riType object identifiers are as follows:

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

      id-ri-crl                    OBJECT IDENTIFIER ::= { id-ri 1 }
      id-ri-ocsp-response          OBJECT IDENTIFIER ::= { id-ri 2 }
      id-ri-delta-crl              OBJECT IDENTIFIER ::= { id-ri 3 }

3.2.10 queryExtensions

   The OPTIONAL queryExtensions item contains Extensions. If present,
   each extension in the sequence extends the query. This specification
   does not define any extensions, the facility is provided to allow
   future specifications to extend SCVP. The syntax for extensions is
   imported from [PKIX-1]. The queryExtensions item, when present, MUST
   contain a sequence of extension items, and each of extension MUST



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


   contain extnID, critical, and extnValue items.

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

   The critical item is a BOOLEAN. Each extension is designated as
   either critical (with a value of TRUE) or non-critical (with a value
   of FALSE). An SCVP server MUST reject the query if it encounters a
   critical extension it does not recognize; however, a non-critical
   extension MAY be ignored if it is not recognized.

   The extnValue item contains an octet string. Within the octet string
   is the extension value. An ASN.1 type is specified for each
   extension, identified by the associated extnID object identifier.

3.3 requestor

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

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

3.4 requestNonce

   The OPTIONAL requestNonce item contains an identifier generated by
   the SCVP client for the request. If the client includes a
   requestNonce value in the request, then the server MUST return the
   same value in the response. The client SHOULD include a requestNonce
   item in every request to prevent an attacker from acting as a man-in-
   the-middle by replaying old responses from the server. The
   requestNonce value SHOULD change with every request sent by the
   client.

   The requestNonce item MUST be an octet string.

3.5 reqExtensions

   The OPTIONAL reqExtensions item contains Extensions. If present, each
   Extension in the sequence extends the request. This specification
   does not define any extensions, the facility is provided to allow
   future specifications to extend the SCVP. The syntax for Extensions
   is imported from [PKIX-1]. The reqExtensions item, when present, MUST
   contain a sequence of extension items, and each of extension MUST
   contain extnID, critical, and extnValue items.



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


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

   The critical item is a BOOLEAN. Each extension is designated as
   either critical (with a value of TRUE) or non-critical (with a value
   of FALSE). An SCVP server MUST reject the query if it encounters a
   critical extension it does not recognize; however, a non-critical
   extension MAY be ignored if it is not recognized.

   The extnValue item contains an octet string. Within the octet string
   is the extension value. An ASN.1 type is specified for each
   extension, identified by the associated extnID object identifier.

4 Validation Response

   A SCVP server response to the client MUST be a single SCVPResponse
   item. A SCVPRequest item is carried in an application/scvp-response
   MIME body part.

   There are two forms of an SCVP response: unsigned and signed. An
   unsigned response MUST only be generated for an error status. An
   overview of the structure used for an unsigned response is provided
   below. Many details are not shown, but the way that SCVP makes use of
   CMS is clearly illustrated.

      ContentInfo {
        contentType        id-ct-scvp-certValResponse,
                                    -- (1.2.840.113549.1.9.16.1.11)
        content            CVResponse }

   The signed response consists of a CVResponse encapsulated in a
   SignedData which is in turn encapsulated in a ContentInfo. An
   overview of the structure used for a signed response is provided
   below. Again, many details are not shown, but the way that SCVP makes
   use of CMS is clearly illustrated.

      ContentInfo {
        contentType        id-signedData, -- (1.2.840.113549.1.7.2)
        content            SignedData }

      SignedData {
        version            CMSVersion,
        digestAlgorithms   DigestAlgorithmIdentifiers,
        encapContentInfo   EncapsulatedContentInfo,
        certificates       CertificateSet, -- (MUST include server cert)
        crls               CertificateRevocationLists, -- (Optional)
        signerInfos        SET OF SignerInfos } -- Only 1 in SCVP




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


      SignerInfo {
        version            CMSVersion,