rfc3029.txt

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

   - The 'version' field is never present in this version of the
     protocol.

     The 'dvReqInfo' is essentially a copy of the 'requestInformation'
     field of the corresponding request.  The DVCS MAY modify the fields
     'dvcs', 'requester', 'dataLocations', and 'nonce' of the ReqInfo
     structure, e.g., if the request was processed by a chain of DVCS,
     if the request needs to indicate DVCS, or to indicate where to find
     a copy of the data from a 'vpd' request.  The only modification
     allowed to a 'nonce' is the inclusion of a new field if it was not
     present, or to concatenate other data to the end (right) of an
     existing value.






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


   - The 'DVCSCertInfo.messageImprint' field is computed from the 'data'
     field of the corresponding request as follows:

     For the 'certs' choice (the 'vpkc' service), the digest is computed
     over the DER encoded data value.  For a 'message' choice (the 'vsd'
     and the 'vpd' services) the digest is computed over the value
     octets (not including tag and length octets) of the OCTET STRING.
     It is up to the DVCS to choose an appropriate digest algorithm.

     For a 'messageImprint' choice (the 'vcpd' service), the
     'messageImprint' of the DVCSRequest is copied as is.

   - The 'DVCSCertInfo.serialNumber' field contains a unique identifier
     of the request.

   - The field 'responseTime' indicates a time value associated with the
     response.  The value MAY be a locally generated one, or a signed
     TimeStampToken (TST) or DVC obtained from an external service.
     Before using a value obtained from an external service, the DVCS
     must validate it according the rules of the external service.

   - The field 'DVCSCertInfo.dvStatus' reflects a collective result of
     the validation.

     If the field is missing, it is an equivalent of the SUCCESS
     status.

     For a vkpc, if the status field is present and set to SUCCESS, it
     indicates that all certificates were successfully validated.  If it
     is present and set to FAILED, it indicates that all or some of the
     certificates failed validation, and the specific status of the
     'certs' should be investigated, at least one of the elements of the
     'certs' TargetEtcChain structures MUST have a failure status.

     If the field 'dvStatus' does not indicate success ('granted' or
     'granted with mods') the element 'failInfo' MAY indicate the reason
     for the failure.  Note that the field 'certs' MAY contain
     additional information about verification failures.

     A failure of the verification of one of the signatures does not
     necessarily result in failing to validate a signed document.  For
     example, as long as a sufficient number of signature was
     successfully verified, a DVC with status 'grantedWithMods' may be
     produced.  A DVC with status 'granted' MUST only be produced if all
     signatures verified successfully.






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


     The field MUST be present, and the status must be set to WAITING,
     if no final response can be immediately available.  It is assumed
     that the DVCS provides an additional final status some time later.
     The details of the necessary procedures are part of the DVCS
     policy.

     In case of failure, the requester can further investigate the cause
     of the failure, by looking into the TargetEtcChain fields.
     'CertEtctoken.pkistatus' fields will indicate which item(s) has
     failed or succeeded the validation and for what reason.

   - The 'DVCSCertInfo.policy' field indicates the policy under which
     the DVCS operates.

   - If present, 'DVCSCertInfo.reqSignature' MUST be the same value as
     the signerInfos field of the corresponding request.  It is a policy
     decision whether to include this field.

   - The 'DVCSCertInfo.certs' field contains the results of the
     verifications made by the DVCS.  For the cpkc service, each element
     contains a copy of a corresponding field of the request with the
     selected subset in the targetAndChain subfield and the results of
     the verifications, and additional certificates or certificate
     references, e.g., from certification authorities or as described in
     appendix C.3.  For a vsd service, each element contains the result
     of the validation of one signature of the signed document to be
     validated.

     In case of a global status of WAITING, the DVCS MAY choose to
     return an individual status of waiting in some of the 'certs'
     field, or not to return such a TargetEtcChain at all.

     The 'acceptablePolicySet' sequence indicates the policies and
     mappings that were processed during X.509 public key certificate
     path validation.  PolicyMappingsSyntax is defined in [RFC2459].

   - The 'extensions' field MAY be used to return additional information
     to the client.  Extensions MAY be marked critical or not in order
     to indicate whether the client MUST understand them.  This document
     does not define extensions.











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


9.2. DVCS Error Notification

   A DVCS Error Notification is a CMS signedData object containing a
   DVCSResponse with a 'dvErrorNote' choice.

   DVCSErrorNotice ::= SEQUENCE {
       transactionStatus           PKIStatusInfo ,
       transactionIdentifier       GeneralName OPTIONAL }

   The PKIStatusInfo is defined in [RFC2511].  For the purposes of
   communicating the DVCSErrorNotice, the following subset of
   PKIFailureInfo values is used:

   PKIFailureInfo ::= BITSTRING  {

        badRequest       (2),
        -- transaction not permitted or supported
        badTime          (3),
        -- messageTime was not sufficiently close to the system time,
        -- as defined by local policy
        badDataFormat    (5),
        -- the data submitted has the wrong format
        wrongAuthority   (6),
        -- the DVCS indicated in the request is different from the
        -- one creating the response token
        incorrectData    (7)
        --the requester's data (i.e., signature) is incorrect )

   In the DVCSErrorNotice, the PKIStatus field of the PKIStatusInfo must
   be set to REJECTED.

   The 'statusString' field of PKIStatusInfo can be used to accommodate
   extra text, such as a reason for the failure, for example "I have
   gone out of service".  The DVCS initializes the
   'DVCSErrorNotice.transactionIdentifier' with a copy of the
   'DVCSRequest.transactionIdentifier' field of the corresponding
   request.

   In certain circumstances, a DVCS may not be able to produce a valid
   response to a request (for example, if it is unable to compute
   signatures for a period of time).  In these situations the DVCS MAY
   create a response with an DVCSErrorNotice but no signature.

   DVCS clients SHOULD NOT trust unsigned responses.  A DVCS client MAY
   trust unsigned responses, if the communication channel provides for
   server authentication (e.g., by services defined by TLS [RFC2246]).





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


10.  Transports

   There is no mandatory transport mechanism in this document.  All
   mechanisms are optional.  Two examples of transport protocols are
   given which allow online exchange of request and a response, and
   asynchronous communication between a client and a DVCS.

   A DVCS MAY use a combination of protocols, for example in order to
   return additional DVCs.

10.1 DVCS Protocol via HTTP or HTTPS

   This subsection specifies a means for conveying ASN.1-encoded
   messages for the DVCS protocol exchanges via the HyperText Transfer
   Protocol.

   The DER encoded DVCS requests and responses are encapsulated using a
   simple MIME object with Content-Type application/dvcs (and with the
   default binary encoding).

   This MIME object can be sent and received using common HTTP or HTTPS
   processing engines over WWW links and provides a simple client-server
   transport for DVCS messages.

10.2 DVCS Protocol Using Email

   This section specifies a means for conveying ASN.1-encoded messages
   for the protocol exchanges described in Section 8 via Internet mail.

   The DER encoded DVCS requests and responses are encapsulated using a
   simple MIME object with Content-Type application/dvcs with an
   appropriate Content-Transfer-Encoding.

   This MIME object can be sent and received using MIME processing
   engines and provides a simple Internet mail transport for DVCS
   messages.

   In order to be able to associate a possible error response with a
   request, the requester SHOULD use the field 'transactionIdentifier'.
   The requester SHOULD not make any assumption about the usage of
   message header fields by the responding service, in particular the
   usage of fields like Subject, Message-ID or References.









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


11.  Security Considerations

   This entire chapter discusses security considerations.

   When designing a data validation and certification service, the
   following considerations have been identified that have an impact
   upon the validity or "trust" in the data validation certificate.

   It is imperative that keys used to sign DVCs are guarded with proper
   security and controls in order to minimize the possibility of
   compromise.  Nevertheless, in case the private key does become
   compromised, an audit trail of all the DVC generated by the DVCS
   SHOULD be kept as a means to help discriminate between genuine and
   false DVCs.  A DVCS MAY provide for a vsd service to validate DVCs
   created by this DVCS or another one solely based on the audit trail.

   When confidentiality and server authentication is required, requests
   and responses MAY be protected using appropriate mechanisms (e.g.,
   CMS encapsulation [RFC 2630] or TLS [RFC2246]).

   Server authentication is highly recommended for the vsd and cpd
   service.

   Client identification and authentication MAY use services defined by
   TLS [RFC2246]) instead of, or in addition to, using a CMS format
   providing authentication.

12.  Patent Information

   The following United States Patents related to data validation and
   certification services, listed in chronological order, are known by
   the authors to exist at this time.  This may not be an exhaustive
   list.  Other patents may exist or be issued at any time.
   Implementers of the DVCS protocol and applications using the protocol
   SHOULD perform their own patent search and determine whether or not
   any encumberences exist on their implementation.

# 4,309,569     Method of Providing Digital Signatures
(issued) January 5, 1982
(inventor) Ralph C.  Merkle
(assignee) The Board of Trustees of the Leland Stanford Junior
University

# 5,001,752     Public/Key Date-Time Notary Facility
(issued) March 19, 1991
(inventor) Addison M.  Fischer





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


# 5,022,080     Electronic Notary
(issued) June 4, 1991
(inventors) Robert T.  Durst, Kevin D.  Hunter

# 5,136,643     Public/Key Date-Time Notary Facility
(issued) August 4, 1992
(inventor) Addison M.  Fischer
(Note: This is a continuation of patent # 5,001,752.)

# 5,136,646     Digital Document Time-Stamping with Catenate Certificate
(issued) August 4, 1992
(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,136,647     Method for Secure Time-Stamping of Digital Documents
(issued) August 4, 1992
(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,373,561     Method of Extending the Validity of a Cryptographic
Certificate
(issued) December 13, 1994
(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,422,95 Personal Date/Time Notary Device