See chapter 2 for the description of the services.   ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }7.7. GeneralName and GeneralNames   There are several occurrences of SEQUENCES of GeneralName and   GeneralNames.  These structures are imported from [RFC2459].8. Data Validation and Certification Requests   A Data Validation and Certification request is a ContentInfo defined   in [RFC2630].   It may consist of a [RFC2630] content with a contenttype id-ct-   DVCSRequestData signalling a DVCSRequestData,   id-ct-DVCSRequestData OBJECT IDENTIFIER ::= {iso(1) member-body(2)     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7}   These data are optionally encapsulated by contenttypes that provide   for authentication and/or confidentiality.   This document describes the usage of a SignedData construct of   [RFC2630] where the contenttype indicated in the eContentType of the   encapContentInfo is id-ct-DVCSRequestData and the eContent of the   encapContentInfo, carried as an octet string, contains a   DVCSRequestData structure.   When using a SignedData structure, a Data Validation and   Certification Request MAY contain several SignerInfo structures, and   countersignature attributes depending on operational environments.   When an end user client creates the request, there is one or zero   SignerInfo.  A relaying DVCS MAY add an additional signature or a   countersignature attribute, or MAY use another encapsulation from   [RFC2630] that provides for authentication and/or confidentiality.   The content of a request consists of a description of the desired   service and additional parameters, the data to be validated, and an   optional identifier of the request.Adams, et al.                 Experimental                     [Page 13]RFC 3029                     DVCS Protocols                February 2001   DVCSRequest ::= SEQUENCE  {       requestInformation         DVCSRequestInformation,       data                       Data,       transactionIdentifier      GeneralName OPTIONAL   }   The 'DVCSRequest.requestInformation' element contains general   information about the request.  It is filled in by the requester as   follows:   - The 'version' field is set to 1 or the field is absent in this     version of the protocol.     The field 'service' contains the requested service.   - The 'nonce' field MAY be used to provide additional protection     against replay or content guessing attacks.   - The 'requestTime' field MAY be used to indicate the time for which     the requested service should be performed.  For a vsd and cpkc     service, it specifies the time for which the validity of a signed     document or certicates is to be asserted.  For the other service,     the field is ignored by the DVCS.  If the field is absent, the     current time is assumed.   - The value of the 'requester' field indicates the requesting entity.     The interpretation and usage of this field MUST be defined by the     DVCS policy.     Some usage examples are:     If the field is present, and the request is signed, a DVCS MAY     require that the field MUST match the identity (subjectName or     subjectAltName extension) of the corresponding signature     certificate.     A request MAY be signed by a DVCS when relaying it to another DVCS.     When acting as a relay, a DVCS MAY add its own identity in the     request relayed to another service provider, and it MAY remove the     initial value.   - The 'requestPolicy' field SHOULD indicate the policy under which     the validation is requested.  This field MUST be checked by the     DVCS to verify agreement with its own policy.  The absence of this     field indicates that any policy is acceptable.Adams, et al.                 Experimental                     [Page 14]RFC 3029                     DVCS Protocols                February 2001   - The 'dvcs' field MAY be used to indicate a list of DVCS which can     be contacted to provide (additional) information or to perform     additional operations necessary to produce the response.     It is up to the DVCS policy whether to honor this field or not, and     to define which choice of a general name is acceptable (e.g., an     URL or a DN).   - The 'dataLocations' field MAY be used to indicate where a copy of     the 'data' field of the request or supplementary information can be     obtained.  The DVCS does not use this field for its own operation,     the exact interpretation of this field is defined by applications.   - The 'requestTime' field MAY be used to indicate the time for which     the requested service should be performed.  For a vsd and cpkc     service, it specifies the time for which the validity of a signed     document or certicates is to be asserted.  For the other service,     the field is ignored by the DVCS.  If the field is absent, the     current time is assumed.  The DVCS service may have a time limit or     a delta time limit regarding current time which are specified in     the local policy of the DVCS service.   - The 'extensions' field MAY be used to include additional     information.  Extensions may be marked critical or not in order to     indicate whether the DVCS is supposed to understand them.  This     document does not define extensions.   The DVCSRequest.data contains service-specific content, defined by   each particular service provided by the DVCS.   Depending on the requested service type, the field may contain a   signed document, a list of certificates, a message digest or   arbitrary data.   The following type is used:   Data ::= CHOICE {         message           OCTET STRING ,         messageImprint    DigestInfo,         certs             SEQUENCE SIZE (1..MAX) OF                               TargetEtcChain   }   The requester fills the 'data' element as follows:   - For a vsd service request, the requestor encapsulates a CMS     SignedData object in the value octets of the 'message' choice.Adams, et al.                 Experimental                     [Page 15]RFC 3029                     DVCS Protocols                February 2001     It is up to the requester to decide whether and how to provide any     certificate that may be needed to verify the signature(s) in the     signedData object.  A requester MAY add certificates to the     encapsulated signedData object or in the certificate list of the     request.   - For a cpkc service request the 'certs' choice is used.     Each certificate to be verified MUST be included in a separate     instance of TargetEtcChain.  The 'TargetEtcChain.chain' field, if     present, indicates one or more chains of trust that can be used to     validate the certificate.  The DVCS MAY choose to select a subset     of certificates as certification path, or to ignore this field.     The 'TargetEtcChain.pathProcInput' field, if present, indicates the     acceptable policy set and initial settings for explicit-policy-     indicator and inhibit-policy-mapping indicators to be used in X.509     public key certificate path validation (see [RFC2459]).     Only the Certificate, ESSCertId, CertId or Extension choices of the     TargetEtcChain can be used in the request.     The requester is responsible for providing sufficient information     to the DVCS to identify the corresponding certificates.   - For a ccpd service the 'messageImprint' choice is used.     The hash algorithm indicated in the hashAlgorithm field SHOULD be a     "strong" hash algorithm (that is, it SHOULD be one-way and     collision resistant).  It is up to the Data Certification Server to     decide whether or not the given hash algorithm is sufficiently     "strong" (based on the current state of knowledge in cryptanalysis     and the current state of the art in computational resources, for     example).   - For a cpd service the 'message' choice is used.     The field contains requester-specific data with any type of     content.  The DVCS does not inspect, modify, or take any particular     action based on the particular content of the 'message' field.   The field 'DVCSRequest.transactionIdentifier' MAY be used in order to   associate DVCS responses containing error messages, to requests.  For   example, in a mail based environment, the parameter could be a copy   of a messageid.  Note, that the transactionIdentifier is not   necessary for associating a request with a valid data validation   certificate.Adams, et al.                 Experimental                     [Page 16]RFC 3029                     DVCS Protocols                February 20019. DVCS Responses   This chapters describes the data structures that are created by a   DVCS to indicate the results of validation and certification   requests.   A DVCS Response structure is generated by the DVCS as a result of   processing of the data validation and certification request.   A Data Validation response contains an [RFC2630] ContentInfo with a   type of id-ct-DVCSResponseData signalling a DVCSResponse structure.   id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { iso(1) member-body(2)       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 8 }   The data MAY be encapsulated by constructs of [RFC2630] in order to   provide authentication of the DVCS, and or integrity and   confidentiality of the request.  This document specifies the usage of   a SignedData construct of [RFC2630].   The contenttype indicated in the eContentType of the encapContentInfo   is of type id-ct-DVCSResponseData, signalling a DVCSResponse as   eContent of the encapContentInfo (carried as an octet string).  The   DVCS SHOULD use a key for which a corresponding certificate indicates   in an extendedKeyUsage the purpose of DVCS signing.   In a critical situation when a DVCS cannot produce a valid signature   (if the DVCS's signing key is known to be compromised, for example),   the DVCSResponse, containing the error notification, MUST be   generated as a signedData with no signerInfo attached.  Receiving   unsigned DVCSResponse MUST be treated by the clients as a critical   and fatal error, and the content of the message should not be   implicitly trusted.   A valid response can contain one of the following:   1. A Data Validation Certificate (DVC), delivering the results of      data validation operations, performed by the DVCS.   2. An error notification.  This may happen when a request fails due      to a parsing error, requester authentication failure, or anything      else that prevented the DVCS from executing the request.Adams, et al.                 Experimental                     [Page 17]RFC 3029                     DVCS Protocols                February 2001   The following type is used:   DVCSResponse ::= CHOICE {       dvCertInfo         DVCSCertInfo ,       dvErrorNote        [0] DVCSErrorNotice }9.1. Data Validation Certificate   A Data Validation Certificate is a signedData object containing a   DVCSResponse with a 'dvCertInfo' choice.   DVCSCertInfo::= SEQUENCE  {            version             Integer DEFAULT 1 ,            dvReqInfo           DVCSRequestInformation,            messageImprint      DigestInfo,            serialNumber        Integer,            responseTime        DVCSTime,            dvStatus            [0] PKIStatusInfo OPTIONAL,            policy              [1] PolicyInformation OPTIONAL,            reqSignature        [2] SignerInfos  OPTIONAL,            certs               [3] SEQUENCE SIZE (1..MAX) OF                                    TargetEtcChain OPTIONAL,            extensions          Extensions OPTIONAL }   The DVCSCertInfo structure is returned as a result of successful   execution of data validation service.  It contains the results of the   data validation, a reference to the original request, and other   parameters.  Please note that 'successful execution' does not   necessarily mean that the validation itself was successful - a   DVCSCertInfo may contain both the 'valid' and 'invalid' results.   The DVCS creates a DVCSCertInfo as follows:   - 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.