- 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 20019.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 200110.  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 200111.  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 JuniorUniversity# 5,001,752     Public/Key Date-Time Notary Facility(issued) March 19, 1991(inventor) Addison M.  FischerAdams, 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 CryptographicCertificate(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(issued) June 6, 1995(inventor) Addison M.  Fischer# 5,781,629     Digital Document Authentication System(issued) July 14, 1998(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr.(assignee) Surety Technologies, Inc.,Adams, et al.                 Experimental                     [Page 24]RFC 3029                     DVCS Protocols                February 200113.  References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119, March 1997.   [RFC2510]  Adams, C. and S. Farrell, "Internet X.509 Public Key              Infrastructure, Certificate Management Protocols", RFC              2510, March 1999.   [RFC2459]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet              X.509 Public Key Infrastructure, Certificate and CRL              Profile", RFC 2459, January 1999.   [RFC2630]  Housley, R., "Cryptographic Message Syntax", RFC 2630,              June 1999.   [ISONR]    ISO/IEC 10181-5:  Security Frameworks in Open Systems.              Non-Repudiation Framework.