draft-ietf-pkix-scvp-11.txt

PKIX的RFC英文文档

   The unsigned request consists of a certValRequest encapsulated in a
   ContentInfo.  An overview of this structure 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-certValRequest,
                                    -- (1.2.840.113549.1.9.16.1.10)
        content            CVRequest }

   The signed request consists of a certValRequest encapsulated in a
   SignedData which is in turn encapsulated in a ContentInfo.  An
   overview of this structure 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, -- (Optional)
        crls               CertificateRevocationLists, -- (Optional)
        signerInfos        SET OF SignerInfos } -- (only one in SCVP)

      SignerInfo {
        version            CMSVersion,
        sid                SignerIdentifier,
        digestAlgorithm    DigestAlgorithmIdentifier,
        signedAttrs        SignedAttributes, -- (Required)
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature          SignatureValue,
        unsignedAttrs      UnsignedAttributes } -- (not used in SCVP)

      EncapsulatedContentInfo {
        eContentType       id-ct-scvp-certValRequest,
                                    -- (1.2.840.113549.1.9.16.1.10)
        eContent           OCTET STRING } -- Contains CVRequest

   The syntaxes for SignedData and ContentInfo are defined in [CMS]. The
   syntax for CVRequest is defined below. The CVRequest item contains
   the client request. The CVRequest item contains the scvpVersion and
   query items; and the CVRequest item MAY also contain the requestor,
   requestNonce, and reqExtensions items.




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


   The CVRequest MUST have the following syntax:

      CVRequest ::= SEQUENCE {
        scvpVersion           INTEGER,
        query                 Query,
        requestor         [0] OCTET STRING OPTIONAL,
        requestNonce      [1] OCTET STRING OPTIONAL,
        reqExtensions     [2] Extensions OPTIONAL }

   Each of the items within the CVRequest are described in the following
   sections.

3.1 scvpVersion

   The scvpVersion item tells the version of SCVP used in a request or a
   response. The value of the scvpVersion item MUST be one (1). Future
   updates to this specification ought to specify other integer values.

3.2 query

   The query specifies one or more certificates that are the object of
   the request; the certificates can be either public key certificates
   [PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain a
   sequence of one or more certificate references, checks, and wantBack
   items; and a query MAY also contain valPolicy, validityTime,
   trustAnchors, intermediateCerts, revInfos, and queryExtensions items.

   Query MUST have the following syntax:

      Query ::= SEQUENCE {
        queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference,
        checks                CertChecks,
        wantBack              WantBack,
        serverContextInfo [0] OCTET STRING OPTIONAL,
        valPolicy         [1] ValidationPolicy OPTIONAL,
        validityTime      [2] GeneralizedTime OPTIONAL,
        trustAnchors      [3] TrustAnchors OPTIONAL,
        intermediateCerts [4] CertBundle OPTIONAL,
        revInfos          [5] RevocationInfos OPTIONAL,
        queryExtensions   [6] Extensions OPTIONAL }

   The list of certificate references in the Query item tells the server
   the certificate(s) for which the client wants information. The
   OPTIONAL serverContextInfo item tells the server that additional
   information from a previous request-response in desired. The OPTIONAL
   validityTime item tells the date and time relative to which the
   client wants the server to perform the checks. The OPTIONAL
   valPolicy, trustAnchors, intermediateCerts, and revInfos items



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


   provide context for the client request. The OPTIONAL queryExtensions
   item provides for future expansion of the query syntax.

3.2.1 queriedCerts

   The queriedCerts item, using the CertReference type, identifies the
   certificate that is the object of the request. The certificate is
   either a public key certificate or an attribute certificate. The
   certificate is either directly included or it is referenced. When
   referenced, a SHA-1 hash value of the referenced item is included to
   ensure that the SCVP client and the SCVP server both obtain the same
   certificate when the referenced certificate is fetched. Certificate
   references use the ESSCertID type defined in [ESS]. CertReference has
   the following syntax:

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

      PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

      ACReference ::= CHOICE {
        attrCert          [3] AttributeCertificate,
        acRef             [4] ESSCertID }

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

3.2.2 checks

   The checks item describes the checking that the SCVP client wants the
   SCVP server to perform on the certificate(s) in the queriedCerts
   item. The checks item MUST contain a sequence of object identifiers.
   Each object identifier tells the SCVP server what checking the client
   expects the server to perform. For each check specified in the
   request, the SCVP server MUST perform all of the requested checks, or
   return an error.

   Revocation status checking inherently includes path construction.
   Also, building a validated certification path does not imply
   revocation status checks (although a server may still choose to
   perform revocation status checks).






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


   The checks item uses the CertChecks type, which has the following
   syntax:

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

   A list of object identifiers (OIDs) indicates the checking that the
   client wants the SCVP server to perform on the certificate(s) in the
   queriedCerts item.

   For public key certificates, OIDs are defined for the following
   checks:

      - Build a certification path to a trusted root;

      - Build a validated certification path to a trusted root; and

      - Do revocation status checks on the certification path.

   For attribute certificates, OIDs are defined for the following
   checks:

      - Build a certification path to a trusted root for the AC issuer;

      - Build a validated certification path to a trusted root for the
        AC issuer;

      - Do revocation status checks on the certification path for the
        AC issuer; and

      - Do revocation status checks on the AC as well as the
        certification path for the AC issuer.

   For these purposes, the following OIDs are defined:

      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 }




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


3.2.3 wantBack

   The wantBack item describes the kind of information the SCVP client
   wants from the SCVP server for the certificate(s) in the queriedCerts
   item. The wantBack item MUST contain a sequence of object
   identifiers. Each object identifier tells the SCVP server what the
   client wants to know about the queriedCerts item. For each type of
   information specified in the request, the server MUST return
   information regarding its finding (in a successful response).

   For example, a request might include a checks item that only
   specifies certification path building and include a wantBack item
   that requests the return of the certification path built by the
   server. In this case, the response would not include a status for the
   validation of the certification path, but it would include a
   certification path that the server considers to be valid. A client
   that wants to perform its own certification path validation might use
   a request of this form.

   Alternatively, a request might include a checks item that requests
   the server to build a certification path and validate it, including
   revocation checking, and include a wantBack item that requests the
   return of the status. In this case, the response would include only a
   status for the validation of the certification path. A client that
   completely delegates certification path validation might use a
   request of this form.

   The wantBack item uses the WantBack type, which has the following
   syntax:

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

   For public key certificates, the types of information that can be
   requested are:

      - Certification path built for the certificate;

      - Proof of revocation status for each certificate in the
        certification path;

      - Status indication; and

      - Public key from the certificate.








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


   For attribute certificates, the types of information that can be
   requested are:

      - Certification path built for the AC issuer certificate;

      - Proof of revocation status for each certificate in the AC issuer
        certification path;

      - Proof of revocation status for the attribute certificate; and

      - Status indication.

   For these purposes, the following OIDs are defined:

      id-swb OBJECT IDENTIFIER ::= { id-pkix 18 }  -- SCVP want back

      id-swb-pkc-cert-path         OBJECT IDENTIFIER ::= { id-swb 1 }
      id-swb-pkc-revocation-info   OBJECT IDENTIFIER ::= { id-swb 2 }
      id-swb-pkc-cert-status       OBJECT IDENTIFIER ::= { id-swb 3 }
      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-ac-cert-status        OBJECT IDENTIFIER ::= { id-swb 8 }

3.2.4 serverContextInfo

   The serverContextInfo item, if present, contains context from a
   previous request-response transaction with the same SCVP server. It
   allows the server to return more than one certification path for the
   same certificate to the client. For example, if a server constructs a
   particular certification path for a certificate, but the client finds
   it unacceptable, the client can then send the same query back to the
   server with the serverContextInfo from the first response, and the
   server will be able to provide a different certification path (if
   another one can be found).

   Contents of the serverContextInfo are opaque to the SCVP client. That
   is, the client only knows that it needs to return the value provided
   by the server with the subsequent request to get a different
   certification path. Note that the subsequent query needs be
   essentially identical to the previous query. The client MUST NOT









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