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 20017.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 20017.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   Validation Certificate.   DVCSRequestInformation ::= SEQUENCE  {           version                      INTEGER DEFAULT 1 ,           service                      ServiceType,           nonce                        INTEGER OPTIONAL,           requestTime                  DVCSTime OPTIONAL,           requester                    [0] GeneralNames OPTIONAL,           requestPolicy                [1] PolicyInformation OPTIONAL,Adams, et al.                 Experimental                     [Page 12]RFC 3029                     DVCS Protocols                February 2001           dvcs                         [2] GeneralNames OPTIONAL,           dataLocations                [3] GeneralNames OPTIONAL,           extensions                   [4] IMPLICIT Extensions OPTIONAL   }   The ServiceType type enumerates the DVCS service type of a request.