rfc3029.txt

PKIX的RFC英文文档

   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 2001


9. 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.