rfc3029.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,647 行 · 第 1/5 页

Adams, et al.                 Experimental                      [Page 6]

RFC 3029                     DVCS Protocols                February 2001


4. Functional Requirements for DVCS

   The DVCS MUST

   1. provide a signed response in the form of a data validation
      certificate to the requester, as defined by policy, or an error
      response.  The DVCS service definition and the policy define how
      much information that has been used by the DVCS to generate the
      response will be included in a data validation certificate, e.g.,
      public key certificates, CRLs, and responses from other OCSP
      servers, DVCS, or others.

   2. indicate in the data validation certificate whether or not the
      signed document, the public key certificate(s), or the data were
      validated, and, if not, the reason why the verification failed.

   3. include a strictly monotonically increasing serial number in each
      data validation certificate.

   4. include a time of day value or a time stamp token into each data
      validation certificate.

   5. sign each data certification token using a key that has been
      certified with a dvcs signing extended key purpose, and include a
      reference to this certificate as a signed attribute in the
      signature.

   6. check the validity of its own signing key and certificate before
      delivering data validation certificates and MUST not deliver data
      validation certificate in case of failure.

   A DVCS SHOULD include within each data validation certificate a
   policy identifier to determine the trust and validation policy used
   for DVC's signature.

5. Data Certification Server Transactions

   A DVCS transaction begins with a client preparing a Data Validation
   and Certification Request.  The request always contains data for
   which validity, correctness or possession is to be certified.

   The request MAY be encapsulated using a security envelope to provide
   for authentication of both requester and server.  Requester
   authentication can be achieved by several of the formats described in
   CMS, in particular, signedData.






Adams, et al.                 Experimental                      [Page 7]

RFC 3029                     DVCS Protocols                February 2001


   The DVCS client chooses an appropriate transport mechanism to convey
   the requests to a DVCS.  It may also be necessary to choose a
   transport mechanism providing confidentiality and, in particular,
   allowing authentication of the DVCS by the requestor, e.g., TLS or
   CMS or S/MIME encryption.

   If the request is valid, the DVCS performs all necessary
   verifications steps, and generates a Data Validation Certificate
   (DVC), and sends a response message containing the DVC back to the
   requestor.

   The Data Validation Certificate is formed as a signed document (CMS
   SignedData).

   As with the request, it may be necessary to choose a transport
   mechanism that provides for confidentiality to carry the DVC.  DVCs
   are not necessarily transported the same way as requests, e.g., they
   can be returned using e-mail after an online request received via
   HTTPS.

   If the request was invalid, the DVCS generates a response message
   containing an appropriate error notification.

   Upon receiving the response, the requesting entity SHOULD verify its
   validity, i.e., whether it contains an acceptable time, the correct
   name for the DVCS, the correct request information and message
   imprint, a valid signature, and satisfactory status, service and
   policy fields.

   When verifying the validity of a DVC, it is up to the requestor's
   application to check whether a DVCS's signing certificate is valid.
   Depending on the usage environment, different methods, online or out
   of band, e.g., CRLs, DVCS, or OCSP, may have to be used.

   After all checks have passed, the data validation certificate can be
   used to authenticate the correctness or possession of the
   corresponding data.

   A DVCS may return more than one DVC corresponding to one request.  In
   this case, all but one request have a global status of 'WAITING'.

6. Identification of the DVCS

   In order to be able to import elements from dvcs the following object
   identifier is used as a ASN.1 module identifier.

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



Adams, et al.                 Experimental                      [Page 8]

RFC 3029                     DVCS Protocols                February 2001


   The DVCS that use SignedData to provide authentication for DVCs MUST
   sign all data certification messages with a key whose corresponding
   certificate MUST contain the extended key usage field extension as
   defined in [RFC2459] Section 4.2.1.14 with KeyPurposeID having value
   id-kp-dvcs.  This extension MUST be marked as critical.

   The Data Validation Certificate MUST contain an ESSCertID
   authenticated attribute for the certificate used by the DVCS for
   signing.

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

   Consistent KeyUsage bits:

   digitalSignature, nonRepudiation, keyCertSign, cRLSign

   A DVCS's certificate MAY contain an Authority Information Access
   extension [RFC2459] in order to convey the method of contacting the
   DVCS.  The accessMethod field in this extension MUST contain the OID
   id-ad-dvcs:

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

   The value of the 'accessLocation' field defines the transport (e.g.,
   an URI) used to access the DVCS.

7. Common Data Types

   There are several common data types that occur in the request and the
   response data structures.  These data types are either defined by
   this document or imported from other sources.  This chapter defines
   and describes these types and lists their usages.

7.1 Version:

   The request and the response include an optional integer field
   specifying the version of the data structure.  For both fields the
   value is 1, or the field is not present at all in this version of the
   protocol.










Adams, et al.                 Experimental                      [Page 9]

RFC 3029                     DVCS Protocols                February 2001


7.2 DigestInfo:

   This element is defined in [RFC2315].  Since the status of that
   document is informational, the definition is repeated here:

   DigestInfo ::= SEQUENCE {
       digestAlgorithm   DigestAlgorithmIdentifier,
       digest            Digest }

   Digest ::= OCTET STRING

   The fields of type DigestInfo have the following meanings:

   - The field 'digestAlgorithm' identifies the message-digest algorithm
     (and any associated parameters) under which data are digested.

   - The field 'digest' is the result of the message-digesting process.

   A DigestInfo is used in two places:

   - as a data portion for the ccpd service, and

   - in all a data validation certificates to hold a digest of the data
     portion of the corresponding request or a copy of the data field
     for a ccpd service.

7.3. Time Values

   Indicators of time can be present in requests and responses.  In the
   most simple form, the time is represented as GeneralizedTime where
   fractions of seconds are allowed.

   An alternate form is a timeStampToken from a TSA, or as a DVC (or
   some other token) from another third party service.

   It is a matter of policy whether a DVCS tries to interpret or
   validate a Time Value in a request.

   DVCSTime ::= CHOICE  {
        genTime                      GeneralizedTime,
        timeStampToken               ContentInfo }

   Future versions of the protocol MAY include additional time formats.

   Time values generated by the DVCS are increasing but not necessarily
   unique, an order among DVCs is defined by serial numbers.





Adams, et al.                 Experimental                     [Page 10]

RFC 3029                     DVCS Protocols                February 2001


7.4. PKIStatusInfo

   This structure is defined in [RFC2510].  It is used as component of
   the 'chain' field of a TargetEtcChain structure, and as a global
   status indicator in the DVCSResponse structure.  Every occurrence of
   PKIStatusInfo is generated by the responding DVCS to reflect the
   result of some local verification.

7.5. TargetEtcChain

   A TargetEtcChain structure contains certificates and other indicators
   to describe either (in a request for a cpkc service) information to
   be validated, or the result of the verifications.  The structure may
   also contain information about policies and policy mappings.

   The details about how to fill in and to interpret the structure are
   defined later for each service.

   The 'pathProcInput' field contains information about policies and
   policy mapping to be used or used during a validation.

   In a response, the 'pkistatus' and `certstatus' choices can only
   occur in the 'chain' sequence.  If present, they contain the result
   of a local verification of the immediately preceding element, or of
   the target value, if it is the first element in the 'chain' sequence.
   If no 'pkistatus' or 'certstatus' is present, the DVCS considers all
   elements in the 'chain' as trustworthy.  Note, that there may be a
   valid OCSP response or DVC indicating an invalid certificate.

   TargetEtcChain ::= SEQUENCE {
        target                       CertEtcToken,
        chain                        SEQUENCE SIZE (1..MAX) OF
                                        CertEtcToken OPTIONAL,
        pathProcInput                [0] PathProcInput OPTIONAL }

   PathProcInput ::= SEQUENCE {
        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                        PolicyInformation,
        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
        explicitPolicyReqd           BOOLEAN DEFAULT FALSE }

   CertEtcToken ::= CHOICE {

        certificate                  [0] IMPLICIT Certificate ,
        esscertid                    [1] ESSCertId ,
        pkistatus                    [2] IMPLICIT PKIStatusInfo ,
        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,



Adams, et al.                 Experimental                     [Page 11]

RFC 3029                     DVCS Protocols                February 2001


        ocspcertstatus               [5] IMPLICIT CertStatus,
        oscpcertid                   [6] IMPLICIT CertId ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension }

   Certificate, PolicyInformation and CertificateList are defined in
   [RFC2459].  ESSCertId is defined in [RFC2634].  CertId, OCSPResponse
   and CertStatus are defined in [RFC2560].  PKIStatusField is defined
   in [RFC2510].

   The choice 'assertion' can contain a data validation certificate, or
   a timeStamp, or other assertions.

   The choices 'assertion', 'ocspresponse' and 'crl' are provided by
   services external to the responding DVCS.  The choices 'certStatus'
   and 'pkistatus' reflect decisions made directly by the responding
   DVCS.

   As a replacement for certificates, certification identifiers
   (ESSCertId, CertId)  MAY be used in requests and responses, if this
   is sufficient to perform the service, e.g., when the corresponding
   certificates are provided elsewhere in a request or response (as part
   of the SignedData type).

   Certificate or certification identifiers of certification authorities
   MAY occur in any order and MAY represent several certification
   chains.

   The choice 'capabilities' can be used to indicate SMIMECapabilities.
   It applies to the certificate identified by the preceding element in
   the sequence.

7.6. DVCSRequestInformation

   A DVCSRequestInformation data structure contains general information
   about the Data Validation and Certification Request.  This structure
   occurs in a request, and is also included in a corresponding Data