[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3029

Internet Draft                   Adams, Sylvester, Zolotarev, Zuccherato
PKIX Working Group         September 14, 2000     expires March 14, 2001


                Internet X.509 Public Key Infrastructure
          Data Validation and Certification Server Protocols
                      <draft-ietf-pkix-dcs-06.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes a general Data Validation and Certification
   Server (DVCS) and the protocols to be used when communicating with
   it.  The Data Validation and Certification Server is a Trusted Third
   Party (TTP) that can be used as one component in building reliable
   non-repudiation services (see [ISONR]).

   Useful Data Validation and Certification Server responsibilities in a
   PKI are to assert the validity of signed documents, public key
   certificates, and the possession or existence of data.

   Assertions created by this protocol are called Data Validation
   Certificates (DVC).

   We give examples of how to use the Data Validation and Certification
   Server to extend the lifetime of a signature beyond key expiry or
   revocation and to query the Data Validation and Certification Server
   regarding the status of a public key certificate. the docuyment



Adams, Sylvester, Zolotarev, Zuccherato                         [Page 1]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   include a complete example of a time stamping transaction.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in [RFC2119].

1. Introduction

   A Data Validation and Certification Server (DVCS) is a Trusted Third
   Party (TTP) providing data validation services, asserting correctness
   of digitally signed documents, validity of public key certificates,
   and possession or existence of data.

   As a result of the validation, a DVCS generates a Data Validation
   Certificate (DVC) The data validation certificate can be used for
   constructing evidence of non-repudiation, relating to the validity
   and correctness of an entity's claim to possess data, the validity
   and revocation status of an entity's public key certificate and the
   validity and correctness of a digitally signed document.

   Services provided by a DVCS do not replace the usage of CRLs and OCSP
   for public key certificate revocation checking in large open
   environments, due to concerns about the scalability of the protocol.

   It should be rather used to support non-repudiation or to supplement
   more traditional services concerning paperless document environments.
   The presence of a data validation certificate supports non-
   repudiation in two ways. It provides evidence that a digitally signed
   document or public key certificate was valid at the time indicated in
   the dvc.

   A DVC validating a public key certificate can for example be used
   even after the public key certificate expires and its revocation
   information is no longer or not easily available.  Determining the
   validity of a DVC is assumed to be a simpler task, for example, if
   the population of DVCS is significantly smaller than the population
   of public certificate owners.

   An important feature of the protocol is that DVCs can be validated by
   using the same protocol (not necessarily using the same service), and
   the validity of a signed document, in particular a DVC, can also be
   determined by means other than by verifying its signature(s), e.g. by
   comparing against an archive.

   The production of a data validation certificate in response to a
   signed request for validation of a signed document or public key
   certificate also provides evidence that due diligence was performed
   by the requester in validating a digital signature or public key



Adams, Sylvester, Zolotarev, Zuccherato                         [Page 2]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   certificate.

   This document defines the use of digital signatures to insure the
   authenticity of documents and DVCs, and uses a corresponding
   terminology; the use of other methods to provide evidence for
   authenticity is not excluded, in particular it is possibile to
   replace a SignedData security envelope by another.


2. Services provided by DVCS

   The current specification defines 4 types of validation and
   certification services:

   - Certification of Possession of Data (cpd),
   - Certification of Claim of Possession of Data (ccpd),
   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).

   A DVCS MUST support at least a subset of these services.  A DVCS may
   support a restructed vsd service allowing to validate data validation
   certificates.

   On completion of each service, the DVCS produces a data validation
   certificate - a signed document containing the validation results and
   trustworthy time information.

2.1 Certification Possession of Data

   The Certification of Possession of Data service provides evidence
   that the requester possessed data at the time indicated and that the
   actual data where presented to the Data Validation Server.

2.2 Certification of Claim of Possession of Data

   The Certification Claim of Possession of Data service is similar to
   the previous one, except that the requester does not present the data
   itself but a message digest. This service is similar to time stamping
   services as described in [TSP].

2.3 Validation of Digitally Signed Documents

   The Validation of Digitally Signed Document service is used when
   validity of a signed document is to be asserted.

   The DVCS verifies all signatures attached to the signed document
   using all appropriate status information and public key certificates.
   The DVCS verifies the mathematical correctness of all signatures



Adams, Sylvester, Zolotarev, Zuccherato                         [Page 3]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   attached to the document and also checks whether the signing entities
   can be trusted, for example by validating the full certification path
   from the signing entities to a trusted point (e.g., the DVCS's CA, or
   the root CA in a hierarchy).

   The DVCS may be able to rely on relevant CRLs or may need to
   supplement this with access to more current status information from
   the CAs for example by accessing to an OCSP service, a trusted
   directory service, or other DVCS services.

   The DVCS will perform verification of all signatures attached to the
   signed document. A failure of the verification of one of the
   signatures does not necessarily result in the failure of the entire
   validation, and vice versa, a global failure may occur if the
   document has an insufficient number of signatures.

2.4 Validation of Public Key Certificates

   The Validation of Public Key Certificates service is used to verify
   and assert the validity (according to [RFC2459]) of one or more
   public key certificates at the specified time.

   When verifying a public key certificate, the DVCS verifies that the
   certificate included in the request is a valid certificate and
   determines its revocation status at a specified time.  DVS checks the
   full certification path from the certificate's issuer to a trusted
   point.  Again, the DVCS MAY be able to rely on external information
   (CRL, OCSP, DVCS).

3. Data Certification Server Usage and Scenarii.

   It is outside the scope of this document to completely describe
   different operational scenarii or usages for DVCS.

   See Appendix B and C for a set of some basic examples and use cases.

   The Validate Signed Document service can be used to support non-
   repudiation services, to allow use of the signed document beyond
   public key certificate revocation or expiry, or simply to delegate
   signature validation to a trusted central (company wide) service.

   The Validate Public Key Certificate service can be used when timely
   information regarding a certificate's revocation status is required
   (e.g. high value funds transfer or the compromise of a highly
   sensitive key) or when evidence supporting non-repudiation is
   required.

   A data validation certificate may be used to simplify the validation



Adams, Sylvester, Zolotarev, Zuccherato                         [Page 4]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   of a signature beyond the expiry or subsequent revocation of the
   signing certificate: a Data validation certificate used as an
   authenticated attribute in a signature includes an additional
   assertion about the usability of a certificate that was used for
   signing. In order to validate such a signature it may be sufficient
   to only validate the data validation certificate.

   A DVCS may include additional key exchange certificates in a data
   validation certificate to validate a key exchange certificate in
   order to provide to an application a set of additional authorised
   recipients for which a session key should also be encrypted. This can
   be used for example to provide central management of a company wide
   recovery scheme. Note, that the additional certificates may not only
   depend on the requested certificate, but also on the requester's
   identity.

   The Certification of Claim of Possession of Data service is an
   extension and modification of the services described in [TSP].

   The Certification of Possession of Data service can be used to assert
   legal deposit of documents, or to implement archival services as a
   trusted third party service.

   The Data Validation and Certification Server Protocols can be used in
   different service contexts. Examples include company-wide centralised
   services (verification of signatures, certification of company
   certificates), service to cooperate in a multi-organisation
   community, or general third party services for time stamping or data
   archival.

   An important application of DVCS is an enterprise environment where
   all security decision are based on company wide rules.  A company
   wide DVCS service can be used to delegate all technical decisions
   (e.g., path validation, trust configuration) to a centrally managed
   service.

   In all cases, the trust that PKI entities have in the Data Validation
   and Certification Server is transferred to the contents of the Data
   Validation Certificate  (just as trust in a CA is transferred to the
   public key certificates that it issues).

   A DVCS service may be combined with or use archiving and logging
   systems, in order to serve as a strong building block in non-
   repudiation services. In this sense it can be regarded as an Evidence
   Recording Authority [ISO-NR].






Adams, Sylvester, Zolotarev, Zuccherato                         [Page 5]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


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, TSA and DVCS.

   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 monotonously 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 attributes 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.

   The DVCS client chooses an appropriate transport mechanism to convey



Adams, Sylvester, Zolotarev, Zuccherato                         [Page 6]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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 do 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 was 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 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, Sylvester, Zolotarev, Zuccherato                         [Page 7]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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 field '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.

7.2 DigestInfo:

   This element is defined in [RFC2315]. Since the status of that



Adams, Sylvester, Zolotarev, Zuccherato                         [Page 8]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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 interprete 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, Sylvester, Zolotarev, Zuccherato                         [Page 9]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 10]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,
        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 'capablities' 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,



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 11]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


           requestTime                  DVCSTime OPTIONAL,
           requester                    [0] GeneralNames OPTIONAL,
           requestPolicy                [1] PolicyInformation OPTIONAL,
           dvcs                         [2] GeneralNames OPTIONAL,
           dataLocations                [3] GeneralNames OPTIONAL,
           extensions                   [4] IMPLICIT Extensions OPTIONAL
   }

   The ServiceType type enumerates the DVCS service type of a request.
   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 occurences 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 consists 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.




Adams, Sylvester, Zolotarev, Zuccherato                        [Page 12]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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.

   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 example are:

     If the field is present, and the request is signed, a DVCS MAY for
     example 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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 13]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


     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.

   - The 'dvcs' field MAY be used to indicate a list a 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
   }



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 14]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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.

     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, and to be verified.  The
     'TargetEtcChain.chain' field, if present, MUST indicate the chain
     of trust to be used when certifying the certificate.  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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 15]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   of a messageid.  Note, that the transactionIdentifier is not
   necessary for associating a request with a valid data validation
   certificate.

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 resonse contain 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 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, Sylvester, Zolotarev, Zuccherato                        [Page 16]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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' and 'dataLocations', and 'nonce' of the ReqInfo
     structure, e.g., if the request was processed by a chain of DVCS,
     if the request 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, Sylvester, Zolotarev, Zuccherato                        [Page 17]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   - 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 to 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 'DVCSCertInfo.nonce' field MAY be used to protect against
     replay attacks.

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

     If the field is missing, it is an equvivalent 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 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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 18]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


     signatures verified successfully.

     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 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 invidual status of waiting in some of the 'certs' field,
     or not to return such a TargetEtcChain at all.

     The 'acceptablePolicySet' sequence  indicate 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 is supposed to understand them. This
     document does not define extensions.

9.2. DVCS Error Notification

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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 19]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


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

   The PKIStatusInfo is defined in the [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 initialises 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]).

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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 20]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   asymchronous communication between a client and a DVCS.

   A DVCS MAY use a combination of protocol, for exmaple 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 an
   appropriate Content-Transfer-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 4 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 to 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, References.

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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 21]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   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 an 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

   # 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



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 22]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   (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
   (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.,


10. References

   [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
   RFC 2119.

   [TSA] C.  Adams, P. Cain, D. Pinkas, R. Zuccherato, "Internet X.509
   Public Key Infrastructure, Time Stamp Protocols," draft-ietf-pkix-
   time-stamp-06.txt, 2000 (work in progress).

   [RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key
   Infrastructure, Certificate Management Protocols," RFC-2510, 1999.

   [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509
   Public Key Infrastructure, Certificate and CRL Profile",  RFC-2459.
   January 1999.

   [RFC2630] R. Housley, "Cryptographic Message Syntax", RFC-2630, June
   1999.

   [ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems. Non-
   Repudiation Framework.

   [RFC2119] Key works for use in RFCs to Indicate Requirement Levels,
   S. Bradner, RFC 2119, March 1997.



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 23]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   [RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp "Internet X.509
   Certificate Request Message Format," RFC-2511, March 1999.

   [RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC
   2246, January 1999.

   [RFC2634] P. Hoffman, "Enhanced Security Services for S/MIME", RFC
   2634, June 1999

   [RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams,
   "X.509 Internet Public Key Infrastructure Online Certificate Status
   Protocol", RFC 2560, June 1999.

11. Authors' Addresses

   Carlisle Adams
   Entrust Technologies
   750 Heron Road
   Ottawa, Ontario
   K1V 1A7
   CANADA
   cadams@entrust.com

   Peter Sylvester
   EdelWeb SA
   33 avenue du Maine
   F-75755 Paris Cedex 15
   FRANCE
   peter.sylvester@edelweb.fr

   Michael Zolotarev
   Baltimore Technologies Pty Limited,
   5th Floor, 1 James Place,
   North Sydney, NSW 2060.
   AUSTRALIA
   mzolotarev@baltimore.com

   Robert Zuccherato
   Entrust Technologies
   750 Heron Road
   Ottawa, Ontario
   K1V 1A7
   CANADA
   robert.zuccherato@entrust.com


APPENDIX A - PKCS #9 Attribute




Adams, Sylvester, Zolotarev, Zuccherato                        [Page 24]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   We define a PKCS #9 [PKCS9] attribute type. The attribute type has
   ASN.1 type SignedData and contains a data validation certificate.

   The object identifier id-aa-dvcs-dvc identifies the data valication
   certificate attribute type.

   id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 29 }

   The attribute may be used as a authenticated or unauthenticated
   attribute in CMS SignedData documents.

APPENDIX B - Signed document validation.

   We present some examples of a possible use of DVCS in the context of
   validation of signed documents.

B.1 Signed document validation

   The example covers the case where a DVCS is used by a signer to
   obtain a proof that a document's structure, including one or more
   attached signatures, is/was correct, after the document was signed.

   The DVC can be produced either by a DVCS that is trusted by the
   signer, or by a DVCS that is trusted by an intended verifier of the
   document.

   The signer uses the obtained DVC as an evidence that its intentions
   were good and it produced a signed document using the
   environment(keys, algorithms, etc) that was known to be OK.

   It produces a stand-alone document that can be used to extend the
   life of a signature.  This example assumes that we have total trust
   in the Data Validation and Certification Server.

   Signature algorithms and keys have a finite lifetime.  Therefore,
   signatures have a finite lifetime.  The Data Certification Server can
   be used to extend the lifetime of a signature.

   In order to extend the lifetime of a signature in this way, the
   following technique can be used:


   1) The signature needs to be certified:

      The signed message is presented to the Data Validation and
      Certification Server in a 'vsd' service request.




Adams, Sylvester, Zolotarev, Zuccherato                        [Page 25]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


      The DVCS verifies that the signature and certificates are valid at
      that time by checking expiry dates, status information, or DVCs,
      and returns a DVC.

   2) The DVC SHOULD be verified.

      The signature of the Data Validation and Certification Server in
      data certification token SHALL be verified using the Data
      Certification Server's valid verification key.

   A signer's signing key (and therefore, its signature) is only valid
   until some specified time T1.  The DVCS's signing key (and therefore,
   its signature) is valid until some specified time T2 that is
   (usually) after time T1.  Without certification, the signer's
   signature would only be valid until time T1.  With certification, the
   signer's signature remains valid until time T2, regardless of
   subsequent revocation or expiry at time T1.

   If the signature of the DVCS is valid, the trust we have in the DVCS
   allows us to conclude that the original signature on the data was
   valid at the time included in the DVC.

   The DVCS signing key MUST be of a sufficient length to allow for a
   sufficiently long lifetime.  Even if this is done, the key will have
   a finite lifetime.  Since data validation certificates are just
   another type of signed documents, they can be validated using
   (another) DVCS.

APPENDIX C - Verifying the Status of a Public Key Certificate

   We now present three examples of how to produce a data validation
   certificate that can be used to assert that a public key certificate
   is valid, trusted, and can be used for a particular purpose.

   A client wants to use a given public key certificate either to use it
   to sign a document or to use it for document encryption.

   A DVCS MUST have access to current information regarding public
   certificate status, it can therefore be used to verify the revocation
   status of a certificate at the current time.

   The following technique can be used:


   A) The public key certificate needs to be validated.

      The certificate is presented to the Data Certification Server
      using a 'vpkc' service.



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 26]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


      The Data Validation and Certification Server verifies that the
      public key certificate is valid and that it hasn't been revoked
      and then returns a data validation certificate.

   B) The data validation certificate MUST be verified.

      The signature of the Data Certification Server in the data
      certification token SHALL be verified using the Data Validation
      and Certification Server's valid certificate.

   C) The public key certificate is used:

   C.1) A clients's own public key certificate (i.e., the corresponding
        private key) can be used to add a signature to a document. The
        signing certificate and the data validation certificate can be
        added as signed attributes to the signature.

        A data validation certificate can now be used during the
        validation signatures using the key contained in the public key
        certificate. This service provided by the DVCS can be thought of
        as a supplement to the usual method of checking revocation
        status.

        In other words, signature validation at a later time does not
        necessarily require access to the revocation status of the
        user's signing certificate, access to a DVCS service and
        validation of the DVC is sufficient to verify a signature. Note
        that the DVC does not tell when the signature had been created,
        it only indicates when the signing certificate was valid.

   C.2) A public key certificate for key exchange can be used after
        having obtained a data validation certification certificate to
        encrypt data. The DVC can be stored with the data and/or stored
        by the creator of the encrypted document.

        If an intended recipient of the document claims that the creator
        did not use an appropriate encryption key, the DVC (obtained by
        a recipient's DVCS) can be used as evidence that the recipient's
        DVCS has authorized the usage of the public key.

   C.3) The procedure described in the previous paragraph can be
        enhanced to provide domain encryption in several ways.
        Organisations require that encrypted documents need to be
        recoverable. One simple way is to always encryt documents with
        additional recipients that acts as 'domain encryption centers'
        or 'recovery centers'. This is technically not a difficult
        problem, but may require complicated and difficult interactions
        with the end user, in particular when the document's recipients



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 27]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


        are in several different organisations.

        One possible solution consists of adding additional certificates
        to the dvc that validates the usage of a particular public key
        certificate used for encryption. In an environment of several
        organisation, one of the possible procedures may be:

        The client asks its local dvcs to validate the public key
        certificate.  The dvcs forwards the request to a dvcs of a
        remote organisation.  The remotes organisation's dvcs verifies
        the certificate and provides a dvc assertion validating the
        certificate. It adds additional certificates usable for key
        exchange to the certEtcChain structure indication additional
        required recipients.  The local dvc creates a dvc containing the
        dvc of the remote dvcs. It may add additional certificates or
        references to the dvc.  The clients uses all validated
        certificates to be usable for key exchange to enhance its list
        of recipients.

        In the local dvcs may as well use local information about the
        remote organisation's need for additional recipients.



Appendix D - MIME Registration

   To: ietf-types@iana.org Subject: Registration of MIME media type
   application/timestamp

   MIME media type name: application

   MIME subtype name: dvcs

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary or Base64

   Security considerations: Carries a request for a data validation and
   certification service and the response. A request may be
   cryptographically signed. The response will be cryptographically
   signed.

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Data
   Validation and Certification Server Protocols



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 28]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   Applications which use this media type: Data Validation and
   Certification Servers and Clients

   Additional information:

     Magic number(s): None
     File extension(s): .dvc
     Macintosh File Type Code(s): none

   Person & email address to contact for further information: Peter
   Sylvester <peter.sylvester@edelweb.fr>

   Intended usage: COMMON

   Author/Change controller: Peter Sylvester
   <peter.sylvester@edelweb.fr>

Appendix E - ASN.1 Module using 1988 Syntax

     PKIXDVCS {iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dvcs(15)}

     DEFINITIONS IMPLICIT TAGS ::=

     BEGIN

     -- EXPORTS ALL --

     IMPORTS
           Extensions, AlgorithmIdentifier
           FROM PKIX1Explicit88 {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-explicit-88(1)}

           GeneralName, PolicyInformation
           FROM PKIX1Implicit88 {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-implicit-88(2)}

           PKIStatusInfo, PKIStatusField FROM PKIXCMP {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-cmp(9)}

           ContentInfo FROM CryptographicMessageSyntax {iso(1)
           member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
           smime(16) modules(0) cms(1)}

           ESSCertID FROM ExtendedSecurityServices



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 29]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


           { iso(1) member-body(2) us(840) rsadsi(113549)
           pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }

           CertId, OCSPResponse, CertStatus
           FROM OCSP
           {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-ocsp(14)}

           SMIMECapabilities FROM SecureMimeMessageV3
           { iso(1) member-body(2) us(840) rsadsi(113549)
            pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }

           ;

   -- Authority Information Access for DVCS

   id-ad-dvcs  OBJECT IDENTIFIER ::= {id-pkix id-ad(48) 4}

   -- Key Purpose for DVCS

   id-kp-dvcs  OBJECT IDENTIFIER ::= {id-pkix id-kp(3) 10}

   -- eContentType for a dvcs requests and responses

   id-ct-DVCSRequestData  OBJECT IDENTIFIER ::= { id-smime ct(1) 7 }
   id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-smime ct(1) 8 }

   -- Data validation certificate attribute

   id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-smime aa(2) 29 }

   -- using the following bases :

   id-pkix     OBJECT IDENTIFIER ::= {iso(1)
                  identified-organization(3) dod(6)
                  internet(1) security(5) mechanisms(5) pkix(7)}

   id-smime    OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

   Version ::= Integer

   DigestInfo ::= SEQUENCE {
       digestAlgorithm   DigestAlgorithmIdentifier,
       digest            Digest
   }




Adams, Sylvester, Zolotarev, Zuccherato                        [Page 30]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   Digest ::= OCTET STRING

   Nonce ::= Integer

   DVCSTime ::= CHOICE  {
        genTime                      GeneralizedTime,
        timeStampToken               ContentInfo
   }
   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,
        ocspcertstatus               [5] IMPLICIT CertStatus,
        oscpcertid                   [6] IMPLICIT CertId ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension
   }

   DVCSRequestInformation ::= SEQUENCE  {
           version                      INTEGER DEFAULT 1 ,
           service                      ServiceType,
           nonce                        Nonce OPTIONAL,
           requestTime                  DVCSTime OPTIONAL,
           requester                    [0] GeneralNames OPTIONAL,
           requestPolicy                [1] PolicyInformation OPTIONAL,
           dvcs                         [2] GeneralNames OPTIONAL,
           dataLocations                [3] GeneralNames OPTIONAL,
           extensions                   [4] IMPLICIT Extensions OPTIONAL
   }

   ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 31]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   DVCSRequest ::= SEQUENCE  {
       requestInformation         DVCSRequestInformation,
       data                       Data,
       transactionIdentifier      GeneralName OPTIONAL
   }

   Data ::= CHOICE {
         message           OCTET STRING ,
         messageImprint    DigestInfo,
         certs             SEQUENCE SIZE (1..MAX) OF
                               TargetEtcChain
   }

   DVCSResponse ::= CHOICE
   {
       dvCertInfo         DVCSCertInfo ,
       dvErrorNote        [0] DVCSErrorNotice
   }

   DVCSCertInfo::= SEQUENCE  {
            version             Integer DEFAULT 1 ,
            dvReqInfo           DVCSRequestInformation,
            messageImprint      DigestInfo,
            serialNumber        Integer,
            responseTime        DVCSTime,
            nonce               Nonce OPTIONAL,
            dvStatus            [0] PKIStatusInfo OPTIONAL,
            policy              [1] PolicyInformation OPTIONAL,
            reqSignature        [2] SignerInfos  OPTIONAL,
            certs               [3] SEQUENCE SIZE (1..MAX) OF
                                    TargetEtcChain OPTIONAL,
            extensions          Extensions OPTIONAL
   }

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

   END

Appendix F - Examples

   This chapter contains an example of a request and a response of a
   'Certify Claim of Possession of Data' transaction of the Clepsydre
   Demonstration Project.

   The information has been formatted with Peter Gutmann's dumpasn1



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 32]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   program.

   The response Data Validation Certificate contains the signing
   certificate.

   The data that are time stamped is the binary of the client program
   used to make the request.

   Request:

      0 30 NDEF: SEQUENCE {
      2 06    9:   OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
     13 A0 NDEF:   [0] {
     15 30  565:     SEQUENCE {
     19 02    1:       INTEGER 3
     22 31   11:       SET {
     24 30    9:         SEQUENCE {
     26 06    5:           OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
     33 05    0:           NULL
               :           }
               :         }
     35 30 NDEF:       SEQUENCE {
     37 06   11:         OBJECT IDENTIFIER
               :       id-ct-DVCSRequestData (1 2 840 113549 1 9 16 1 7)
     50 A0 NDEF:         [0] {
     52 04  134:           OCTET STRING, encapsulates {
     55 30  131:               SEQUENCE {
     58 30   96:                 SEQUENCE {
     60 0A    1:                   ENUMERATED CCPD (4)
     63 A0   77:                   [0] {
     65 A4   75:                     [4] {
     67 30   73:                       SEQUENCE {
     69 31   11:                         SET {
     71 30    9:                           SEQUENCE {
     73 06    3:                             OBJECT IDENTIFIER
               :                               countryName (2 5 4 6)
     78 13    2:                             PrintableString 'FR'
               :                             }
               :                           }
     82 31   14:                         SET {
     84 30   12:                           SEQUENCE {
     86 06    3:                             OBJECT IDENTIFIER
               :                               localityName (2 5 4 7)
     91 13    5:                             PrintableString 'Paris'
               :                             }
               :                           }
     98 31   16:                         SET {
    100 30   14:                           SEQUENCE {



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 33]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


    102 06    3:                             OBJECT IDENTIFIER
               :                             organizationName (2 5 4 10)
    107 13    7:                             PrintableString 'EdelWeb'
               :                             }
               :                           }
    116 31   24:                         SET {
    118 30   22:                           SEQUENCE {
    120 06    3:                             OBJECT IDENTIFIER
               :                               commonName (2 5 4 3)
    125 13   15:                       PrintableString 'Peter Sylvester'
               :                             }
               :                           }
               :                         }
               :                       }
               :                     }
    142 A1   12:                   [1] {
    144 06   10:              OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1'
               :                     }
               :                   }
    156 30   31:                 SEQUENCE {
    158 30    7:                   SEQUENCE {
    160 06    5:                  OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
               :                     }
    167 04   20:                   OCTET STRING
               :         75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F
               :                   CD 1F A5 66
               :                   }
               :                 }
               :               }
               :           }
               :         }
    193 31  387:       SET {
    197 30  383:         SEQUENCE {
    201 02    1:           INTEGER 1
    204 30  124:           SEQUENCE {
    206 30  112:             SEQUENCE {
    208 31   11:               SET {
    210 30    9:                 SEQUENCE {
    212 06    3:                  OBJECT IDENTIFIER countryName (2 5 4 6)
    217 13    2:                   PrintableString 'FR'
               :                   }
               :                 }
    221 31   21:               SET {
    223 30   19:                 SEQUENCE {
    225 06    3:            OBJECT IDENTIFIER organizationName (2 5 4 10)
    230 13   12:                   PrintableString 'EdelWeb S.A.'
               :                   }
               :                 }



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 34]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


    244 31   40:               SET {
    246 30   38:                 SEQUENCE {
    248 06    3:                   OBJECT IDENTIFIER
               :                     organizationalUnitName (2 5 4 11)
    253 13   31:        PrintableString 'Clepsydre Demonstration Service'
               :                   }
               :                 }
    286 31   32:               SET {
    288 30   30:                 SEQUENCE {
    290 06    3:                   OBJECT IDENTIFIER commonName (2 5 4 3)
    295 13   23:                PrintableString 'Time Stamping Authority'
               :                   }
               :                 }
               :               }
    320 02    8:             INTEGER
               :               00 94 88 17 21 34 37 76
               :             }
    330 30    9:           SEQUENCE {
    332 06    5:             OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
    339 05    0:             NULL
               :             }
    341 A0   95:           [0] {
    343 30   26:             SEQUENCE {
    345 06    9:               OBJECT IDENTIFIER
               :                 contentType (1 2 840 113549 1 9 3)
    356 31   13:               SET {
    358 06   11:                 OBJECT IDENTIFIER
               :         id-ct-DVCSRequestData (1 2 840 113549 1 9 16 1 7)
               :                 }
               :               }
    371 30   28:             SEQUENCE {
    373 06    9:               OBJECT IDENTIFIER
               :                 signingTime (1 2 840 113549 1 9 5)
    384 31   15:               SET {
    386 17   13:                 UTCTime '000417171457Z'
               :                 }
               :               }
    401 30   35:             SEQUENCE {
    403 06    9:               OBJECT IDENTIFIER
               :                 messageDigest (1 2 840 113549 1 9 4)
    414 31   22:               SET {
    416 04   20:                 OCTET STRING
               :           4D A8 C2 D2 CE 7C 0D 04 41 2F 44 13 33 75 DB 2F
               :           5B 2D F9 DC
               :                 }
               :               }
               :             }
    438 30   13:           SEQUENCE {



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 35]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


    440 06    9:             OBJECT IDENTIFIER
               :               rsaEncryption (1 2 840 113549 1 1 1)
    451 05    0:             NULL
               :             }
    453 04  128:           OCTET STRING
               :           6E 7B 0E 36 F5 08 5F 16 3C 31 7B 28 BB 0B C2 C6
               :           17 67 A6 B5 54 F1 98 E2 6F 89 96 0E 0C 99 E6 CB
               :           40 C1 9B 8D D8 D7 8E D3 2B 41 F7 16 26 5B B7 08
               :           BF E6 95 B2 D9 01 6C FE B1 2C 52 C1 5A D2 31 F3
               :           8E CA DD 11 A1 72 05 29 41 6A DD 28 40 AA 5C 77
               :           C6 9D 1D 80 53 DB 6F 9C 4C A5 A3 8F 92 8B 18 3F
               :           D5 3A AD 01 87 69 C3 FD D3 D8 C3 D0 CA 6B E6 0D
               :           4E 53 6E 50 20 99 7C 94 C2 44 25 1B 06 C0 99 96
               :           }
               :         }
               :       }
               :     }
               :   }

   The corresponding data in PEM format are:

   -----BEGIN PKCS7-----
   MIAGCSqGSIb3DQEHAqCAMIICNQIBAzELMAkGBSsOAwIaBQAwgAYLKoZIhvcNAQkQ
   AQeggASBhjCBgzBgCgEEoE2kSzBJMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMFUGFy
   aXMxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAMTD1BldGVyIFN5bHZlc3RlcqEM
   BgorBgEEAak9AQIBMB8wBwYFKw4DAhoEFHW2ha9viUZ96AcVJR5Fl4/NH6VmAAAA
   ADGCAYMwggF/AgEBMHwwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIg
   Uy5BLjEoMCYGA1UECxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEg
   MB4GA1UEAxMXVGltZSBTdGFtcGluZyBBdXRob3JpdHkCCACUiBchNDd2MAkGBSsO
   AwIaBQCgXzAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQAQcwHAYJKoZIhvcNAQkF
   MQ8XDTAwMDQxNzE3MTQ1N1owIwYJKoZIhvcNAQkEMRYEFE2owtLOfA0EQS9EEzN1
   2y9bLfncMA0GCSqGSIb3DQEBAQUABIGAbnsONvUIXxY8MXsouwvCxhdnprVU8Zji
   b4mWDgyZ5stAwZuN2NeO0ytB9xYmW7cIv+aVstkBbP6xLFLBWtIx847K3RGhcgUp
   QWrdKECqXHfGnR2AU9tvnEylo4+Sixg/1TqtAYdpw/3T2MPQymvmDU5TblAgmXyU
   wkQlGwbAmZYAAAAA
   -----END PKCS7-----

   Response:


      0 30 NDEF: SEQUENCE {
      2 06    9:   OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
     13 A0 NDEF:   [0] {
     15 30 2020:     SEQUENCE {
     19 02    1:       INTEGER 3
     22 31   11:       SET {
     24 30    9:         SEQUENCE {
     26 06    5:           OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 36]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


     33 05    0:           NULL
               :           }
               :         }
     35 30 NDEF:       SEQUENCE {
     37 06   11:         OBJECT IDENTIFIER
               :    id-ct-DVCSResponseData (1 2 840 113549 1 9 16 1 8)
     50 A0 NDEF:         [0] {
     52 04  280:           OCTET STRING, encapsulates {
     56 30  276:               SEQUENCE {
     60 30  214:                 SEQUENCE {
     63 0A    1:                   ENUMERATED CCPD (4)
     66 A0   77:                   [0] {
     68 A4   75:                     [4] {
     70 30   73:                       SEQUENCE {
     72 31   11:                         SET {
     74 30    9:                           SEQUENCE {
     76 06    3:                             OBJECT IDENTIFIER
               :                               countryName (2 5 4 6)
     81 13    2:                             PrintableString 'FR'
               :                             }
               :                           }
     85 31   14:                         SET {
     87 30   12:                           SEQUENCE {
     89 06    3:                             OBJECT IDENTIFIER
               :                               localityName (2 5 4 7)
     94 13    5:                             PrintableString 'Paris'
               :                             }
               :                           }
    101 31   16:                         SET {
    103 30   14:                           SEQUENCE {
    105 06    3:                             OBJECT IDENTIFIER
               :                             organizationName (2 5 4 10)
    110 13    7:                             PrintableString 'EdelWeb'
               :                             }
               :                           }
    119 31   24:                         SET {
    121 30   22:                           SEQUENCE {
    123 06    3:                             OBJECT IDENTIFIER
               :                               commonName (2 5 4 3)
    128 13   15:                       PrintableString 'Peter Sylvester'
               :                             }
               :                           }
               :                         }
               :                       }
               :                     }
    145 A1   12:                   [1] {
    147 06   10:              OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1'
               :                     }



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 37]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


    159 A2  116:                   [2] {
    161 A4  114:                     [4] {
    163 30  112:                       SEQUENCE {
    165 31   11:                         SET {
    167 30    9:                           SEQUENCE {
    169 06    3:                             OBJECT IDENTIFIER
               :                               countryName (2 5 4 6)
    174 13    2:                             PrintableString 'FR'
               :                             }
               :                           }
    178 31   21:                         SET {
    180 30   19:                           SEQUENCE {
    182 06    3:                             OBJECT IDENTIFIER
               :                             organizationName (2 5 4 10)
    187 13   12:                          PrintableString 'EdelWeb S.A.'
               :                             }
               :                           }
    201 31   40:                         SET {
    203 30   38:                           SEQUENCE {
    205 06    3:                             OBJECT IDENTIFIER
               :                        organizationalUnitName (2 5 4 11)
    210 13   31:        PrintableString 'Clepsydre Demonstration Service'
               :                             }
               :                           }
    243 31   32:                         SET {
    245 30   30:                           SEQUENCE {
    247 06    3:                             OBJECT IDENTIFIER
               :                               commonName (2 5 4 3)
    252 13   23:                PrintableString 'Time Stamping Authority'
               :                             }
               :                           }
               :                         }
               :                       }
               :                     }
               :                   }
    277 30   31:                 SEQUENCE {
    279 30    7:                   SEQUENCE {
    281 06    5:                     OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
               :                     }
    288 04   20:                   OCTET STRING
               :            75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F
               :            CD 1F A5 66
               :                   }
    310 02    7:                 INTEGER
               :                   01 78 0A 1E CA 88 23
    319 18   15:                 GeneralizedTime '20000417171617Z'
               :                 }
               :               }



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 38]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


               :           }
               :         }
    340 A0  992:       [0] {
    344 30  988:         SEQUENCE {
    348 30  708:           SEQUENCE {
    352 A0    3:             [0] {
    354 02    1:               INTEGER 2
               :               }
    357 02    8:             INTEGER
               :               00 94 88 17 17 64 37 32
    367 30   13:             SEQUENCE {
    369 06    9:               OBJECT IDENTIFIER
               :                 md5withRSAEncryption (1 2 840 113549 1 1 4)
    380 05    0:               NULL
               :               }
    382 30  112:             SEQUENCE {
    384 31   11:               SET {
    386 30    9:                 SEQUENCE {
    388 06    3:                   OBJECT IDENTIFIER countryName (2 5 4 6)
    393 13    2:                   PrintableString 'FR'
               :                   }
               :                 }
    397 31   21:               SET {
    399 30   19:                 SEQUENCE {
    401 06    3:               OBJECT IDENTIFIER organizationName (2 5 4 10)
    406 13   12:                   PrintableString 'EdelWeb S.A.'
               :                   }
               :                 }
    420 31   40:               SET {
    422 30   38:                 SEQUENCE {
    424 06    3:                   OBJECT IDENTIFIER
               :                     organizationalUnitName (2 5 4 11)
    429 13   31:           PrintableString 'Clepsydre Demonstration Service'
               :                   }
               :                 }
    462 31   32:               SET {
    464 30   30:                 SEQUENCE {
    466 06    3:                   OBJECT IDENTIFIER commonName (2 5 4 3)
    471 13   23:                   PrintableString 'Time Stamping Authority'
               :                   }
               :                 }
               :               }
    496 30   30:             SEQUENCE {
    498 17   13:               UTCTime '000125161938Z'
    513 17   13:               UTCTime '200120161938Z'
               :               }
    528 30  112:             SEQUENCE {
    530 31   11:               SET {



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 39]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


    532 30    9:                 SEQUENCE {
    534 06    3:                   OBJECT IDENTIFIER countryName (2 5 4 6)
    539 13    2:                   PrintableString 'FR'
               :                   }
               :                 }
    543 31   21:               SET {
    545 30   19:                 SEQUENCE {
    547 06    3:                OBJECT IDENTIFIER organizationName (2 5 4 10)
    552 13   12:                   PrintableString 'EdelWeb S.A.'
               :                   }
               :                 }
    566 31   40:               SET {
    568 30   38:                 SEQUENCE {
    570 06    3:                   OBJECT IDENTIFIER
               :                     organizationalUnitName (2 5 4 11)
    575 13   31:            PrintableString 'Clepsydre Demonstration Service'
               :                   }
               :                 }
    608 31   32:               SET {
    610 30   30:                 SEQUENCE {
    612 06    3:                   OBJECT IDENTIFIER commonName (2 5 4 3)
    617 13   23:                   PrintableString 'Time Stamping Authority'
               :                   }
               :                 }
               :               }
    642 30  290:             SEQUENCE {
    646 30   13:               SEQUENCE {
    648 06    9:                 OBJECT IDENTIFIER
               :                   rsaEncryption (1 2 840 113549 1 1 1)
    659 05    0:                 NULL
               :                 }
    661 03  271:               BIT STRING 0 unused bits
               :              30 82 01 0A 02 82 01 01 00 FA C3 17 AE EB B7 9D
               :              EB AB BD 05 7E 39 43 6D 04 45 58 74 05 A5 CC F3
               :              6C 2F 8C 8E 77 7E C2 9F 12 11 5C 7D DB BE 23 28
               :              9A 90 D2 AB C6 A2 BA BD A3 7E 99 A6 99 21 A5 D8
               :              90 B9 CF A7 23 4E A0 56 A0 C1 0A 46 89 8E 3C 91
               :              67 37 FD 9B AB 49 17 FC 4A A5 F2 E4 4C 6E E3 6A
               :              1C 92 97 04 6F 7F 0C 5C FB 74 CB 95 7E 4C C3 58
               :              12 E8 A9 D6 F0 DD 12 44 15 E7 8B 2E AF 51 C0 0C
               :                         [ Another 142 bytes skipped ]
               :               }
    936 A3  122:             [3] {
    938 30  120:               SEQUENCE {
    940 30   15:                 SEQUENCE {
    942 06    3:                OBJECT IDENTIFIER basicConstraints (2 5 29 19)
    947 04    8:                   OCTET STRING, encapsulates {
    949 30    6:                       SEQUENCE {



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 40]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


    951 01    1:                         BOOLEAN TRUE
    954 02    1:                         INTEGER 0
               :                         }
               :                       }
               :                   }
    957 30   22:                 SEQUENCE {
    959 06    3:                   OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
    964 01    1:                   BOOLEAN TRUE
    967 04   12:                   OCTET STRING, encapsulates {
    969 30   10:                       SEQUENCE {
    971 06    8:                         OBJECT IDENTIFIER '1 3 6 1 5 5 7 3 10'
               :                         }
               :                       }
               :                   }
    981 30   77:                 SEQUENCE {
    983 06    8:                   OBJECT IDENTIFIER
               :                     authorityInfoAccess (1 3 6 1 5 5 7 1 1)
    993 01    1:                   BOOLEAN TRUE
    996 04   62:                   OCTET STRING, encapsulates {
    998 30   60:                       SEQUENCE {
   1000 30   58:                         SEQUENCE {
   1002 06    8:                         OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 4'
   1012 86   46:                           [6]
               :               'https://clepsydre.edelweb.fr/dvcs/service-ccpd'
               :                           }
               :                         }
               :                       }
               :                   }
               :                 }
               :               }
               :             }
   1060 30   13:           SEQUENCE {
   1062 06    9:             OBJECT IDENTIFIER
               :               md5withRSAEncryption (1 2 840 113549 1 1 4)
   1073 05    0:             NULL
               :             }
   1075 03  257:           BIT STRING 0 unused bits
               :             08 DA AF 5B 09 39 66 D3 BE 80 1D D7 72 B5 2C A3
               :             04 FB 46 F8 05 F5 BF 83 F3 6D 6D 32 28 1C 46 EE
               :             0F EA 30 61 8A 1E 8A 03 4E 98 81 60 1F 97 17 53
               :             D1 54 73 3F 72 98 45 D3 10 9A D3 77 B8 74 0E 9A
               :             90 29 8E AC A4 EB D2 24 6D F6 21 1D 3F 52 8B 2C
               :             E6 92 E7 52 C6 54 93 91 BC 57 74 21 38 39 75 CD
               :             30 49 54 13 94 6C FE F1 64 38 1F 5F 7D BB E0 3E
               :             A8 F1 28 1C F1 D9 28 FA 32 1E 3B 48 BF 5C 70 21
               :                     [ Another 128 bytes skipped ]
               :           }
               :         }



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 41]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   1336 31  699:       SET {
   1340 30  695:         SEQUENCE {
   1344 02    1:           INTEGER 1
   1347 30  124:           SEQUENCE {
   1349 30  112:             SEQUENCE {
   1351 31   11:               SET {
   1353 30    9:                 SEQUENCE {
   1355 06    3:                   OBJECT IDENTIFIER countryName (2 5 4 6)
   1360 13    2:                   PrintableString 'FR'
               :                   }
               :                 }
   1364 31   21:               SET {
   1366 30   19:                 SEQUENCE {
   1368 06    3:                 OBJECT IDENTIFIER organizationName (2 5 4 10)
   1373 13   12:                   PrintableString 'EdelWeb S.A.'
               :                   }
               :                 }
   1387 31   40:               SET {
   1389 30   38:                 SEQUENCE {
   1391 06    3:                   OBJECT IDENTIFIER
               :                     organizationalUnitName (2 5 4 11)
   1396 13   31:             PrintableString 'Clepsydre Demonstration Service'
               :                   }
               :                 }
   1429 31   32:               SET {
   1431 30   30:                 SEQUENCE {
   1433 06    3:                   OBJECT IDENTIFIER commonName (2 5 4 3)
   1438 13   23:                   PrintableString 'Time Stamping Authority'
               :                   }
               :                 }
               :               }
   1463 02    8:             INTEGER
               :               00 94 88 25 72 35 27 50
               :             }
   1473 30    9:           SEQUENCE {
   1475 06    5:             OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
   1482 05    0:             NULL
               :             }
   1484 A0  276:           [0] {
   1488 30   26:             SEQUENCE {
   1490 06    9:               OBJECT IDENTIFIER
               :                 contentType (1 2 840 113549 1 9 3)
   1501 31   13:               SET {
   1503 06   11:                 OBJECT IDENTIFIER
               :            id-ct-DVCSResponseData (1 2 840 113549 1 9 16 1 8)
               :                 }
               :               }
   1516 30   28:             SEQUENCE {



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 42]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   1518 06    9:               OBJECT IDENTIFIER
               :                 signingTime (1 2 840 113549 1 9 5)
   1529 31   15:               SET {
   1531 17   13:                 UTCTime '000417171619Z'
               :                 }
               :               }
   1546 30   35:             SEQUENCE {
   1548 06    9:               OBJECT IDENTIFIER
               :                 messageDigest (1 2 840 113549 1 9 4)
   1559 31   22:               SET {
   1561 04   20:                 OCTET STRING
               :               68 50 DC 90 20 2E C2 F0 55 15 7F 77 A9 A6 0C 34
               :               CC 13 06 FA
               :                 }
               :               }
   1583 30  178:             SEQUENCE {
   1586 06   11:               OBJECT IDENTIFIER
               :          id-aa-signingCertificate (1 2 840 113549 1 9 16 2 12)
   1599 31  162:               SET {
   1602 30  159:                 SEQUENCE {
   1605 30  156:                   SEQUENCE {
   1608 30  153:                     SEQUENCE {
   1611 04   20:                       OCTET STRING
               :                 5C F1 18 F3 4A CA B4 67 D6 D8 E7 F8 3B 4A D9 7A
               :                 32 A5 43 A5
   1633 30  128:                       SEQUENCE {
   1636 30  116:                         SEQUENCE {
   1638 A4  114:                           [4] {
   1640 30  112:                             SEQUENCE {
   1642 31   11:                               SET {
   1644 30    9:                                 SEQUENCE {
   1646 06    3:                                   OBJECT IDENTIFIER
               :                                     countryName (2 5 4 6)
   1651 13    2:                                   PrintableString 'FR'
               :                                   }
               :                                 }
   1655 31   21:                               SET {
   1657 30   19:                                 SEQUENCE {
   1659 06    3:                                   OBJECT IDENTIFIER
               :                                     organizationName (2 5 4 10)
   1664 13   12:                                   PrintableString 'EdelWeb S.A.'
               :                                   }
               :                                 }
   1678 31   40:                               SET {
   1680 30   38:                                 SEQUENCE {
   1682 06    3:                                   OBJECT IDENTIFIER
               :                                organizationalUnitName (2 5 4 11)
   1687 13   31:                 PrintableString 'Clepsydre Demonstration Service'



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 43]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


               :                                   }
               :                                 }
   1720 31   32:                               SET {
   1722 30   30:                                 SEQUENCE {
   1724 06    3:                                   OBJECT IDENTIFIER
               :                                     commonName (2 5 4 3)
   1729 13   23:                         PrintableString 'Time Stamping Authority'
               :                                   }
               :                                 }
               :                               }
               :                             }
               :                           }
   1754 02    8:                         INTEGER
               :                   00 94 88 25 72 35 27 50
               :                         }
               :                       }
               :                     }
               :                   }
               :                 }
               :               }
               :             }
   1764 30   13:           SEQUENCE {
   1766 06    9:             OBJECT IDENTIFIER
               :               rsaEncryption (1 2 840 113549 1 1 1)
   1777 05    0:             NULL
               :             }
   1779 04  256:           OCTET STRING
               :             2E 70 9F 56 5E 01 56 A9 E1 47 81 12 35 21 29 09
               :             16 7A ED 45 F9 5A A2 ED E4 FE 9D 2C E4 DA 12 66
               :             62 14 59 61 8B 50 7B 01 82 3D BD 7E E6 38 D0 A8
               :             A0 37 98 79 13 26 39 29 C6 72 20 A9 95 71 E7 53
               :             7F 79 77 98 EF 23 02 4E B9 BD 90 9B AC 05 A2 70
               :             8F 3A 42 36 9C 2C B0 94 B1 2B 0B 36 94 0E 78 0E
               :             B0 D1 09 20 63 BC FF CD 32 F1 5A D3 AB 9F 93 9C
               :             5A A3 58 99 A0 28 11 E0 80 4D 4D 1E 77 04 F4 50
               :                     [ Another 128 bytes skipped ]
               :           }
               :         }
               :       }
               :     }
               :   }

   The corresponding data in PEM format (together with a technical
   textual description) are:


   Data Validation Certificate:
       Request Information:



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 44]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


         Service: Certify Claim of Possession of Data - ccpd(4)
         Policy: EdelWeb Customer Policy Clepsydre
         Requester:
           DirName:/C=FR/L=Paris/O=EdelWeb/CN=Peter Sylvester
         DVCS:
           DirName:/C=FR/O=EdelWeb S.A./
     OU=Clepsydre Demonstration Service/CN=Time Stamping Authority
       SerialNumber: 01780a1eca8823
       MessageDigest:
         Algorithm: sha1
         Data     : 75B685AF6F89467DE80715251E45978FCD1FA566
       Asserted Time:
         Generalized Time: 17-Apr-2000 19:16:17 (Apr 17 17:16:17 2000 GMT)
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number:
               94:88:17:17:64:37:32
           Signature Algorithm: md5WithRSAEncryption
           Issuer: C=FR, O=EdelWeb S.A.,
       OU=Clepsydre Demonstration Service, CN=Time Stamping Authority
           Validity
               Not Before: Jan 25 16:19:38 2000 GMT
               Not After : Jan 20 16:19:38 2020 GMT
           Subject: C=FR, O=EdelWeb S.A.,
       OU=Clepsydre Demonstration Service, CN=Time Stamping Authority
           Subject Public Key Info:
               Public Key Algorithm: rsaEncryption
               RSA Public Key: (2048 bit)
                   Modulus (2048 bit):
                       00:fa:c3:17:ae:eb:b7:9d:eb:ab:bd:05:7e:39:43:
                       6d:04:45:58:74:05:a5:cc:f3:6c:2f:8c:8e:77:7e:
                       c2:9f:12:11:5c:7d:db:be:23:28:9a:90:d2:ab:c6:
                       a2:ba:bd:a3:7e:99:a6:99:21:a5:d8:90:b9:cf:a7:
                       23:4e:a0:56:a0:c1:0a:46:89:8e:3c:91:67:37:fd:
                       9b:ab:49:17:fc:4a:a5:f2:e4:4c:6e:e3:6a:1c:92:
                       97:04:6f:7f:0c:5c:fb:74:cb:95:7e:4c:c3:58:12:
                       e8:a9:d6:f0:dd:12:44:15:e7:8b:2e:af:51:c0:0c:
                       5f:a8:65:fc:47:a1:c9:98:1f:d4:e1:ea:bc:1c:1a:
                       27:bb:8b:56:f1:12:55:10:f4:8e:d8:9f:19:9c:1e:
                       81:f7:db:63:dd:88:37:3f:71:79:5b:96:e2:5f:82:
                       d5:12:19:05:0d:e1:3d:a5:6d:66:e4:2c:1e:ed:c7:
                       4c:b8:df:aa:38:c8:15:6a:ae:25:7d:46:2a:07:f9:
                       83:77:c4:51:ee:90:dc:05:d0:c3:f0:f1:5f:e8:d4:
                       ed:5d:34:70:91:9d:9f:08:55:7d:5b:e5:8d:5f:35:
                       59:83:4e:72:19:bb:9c:88:d1:7a:fc:23:a5:84:99:
                       b4:17:8a:4d:6c:9d:d0:a6:35:80:5f:ca:fb:24:8b:
                       54:1d



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 45]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


                   Exponent: 65537 (0x10001)
           X509v3 extensions:
               X509v3 Basic Constraints:
                   CA:TRUE, pathlen:0
               X509v3 Extended Key Usage: critical
                   DVCS Signing
               Authority Information Access: critical
            DVCS - URI:https://clepsydre.edelweb.fr/dvcs/service-ccpd

       Signature Algorithm: md5WithRSAEncryption
           08:da:af:5b:09:39:66:d3:be:80:1d:d7:72:b5:2c:a3:04:fb:
           46:f8:05:f5:bf:83:f3:6d:6d:32:28:1c:46:ee:0f:ea:30:61:
           8a:1e:8a:03:4e:98:81:60:1f:97:17:53:d1:54:73:3f:72:98:
           45:d3:10:9a:d3:77:b8:74:0e:9a:90:29:8e:ac:a4:eb:d2:24:
           6d:f6:21:1d:3f:52:8b:2c:e6:92:e7:52:c6:54:93:91:bc:57:
           74:21:38:39:75:cd:30:49:54:13:94:6c:fe:f1:64:38:1f:5f:
           7d:bb:e0:3e:a8:f1:28:1c:f1:d9:28:fa:32:1e:3b:48:bf:5c:
           70:21:29:ef:be:72:24:da:0d:f9:51:7a:fe:d7:f5:ff:e8:c2:
           ea:c6:4c:45:14:51:53:fd:00:d5:5b:cc:67:2a:23:94:31:9e:
           c2:90:38:9b:b0:df:f9:de:67:0c:57:5c:d7:b0:fc:f2:72:96:
           c4:d1:7a:9d:a0:e6:51:24:99:9e:89:c6:39:f9:72:7a:44:fd:
           2d:3f:bc:df:c7:25:27:94:a1:b5:7d:ba:06:75:67:1c:95:6c:
           bd:2c:74:41:3e:cd:cd:39:5c:2e:9c:c3:c3:09:e3:79:d5:eb:
           85:e8:f1:72:29:80:f6:c6:6e:61:1b:58:fc:87:3e:d9:e1:53:
           10:e0:b1:05

   -----BEGIN PKCS7-----
   MIAGCSqGSIb3DQEHAqCAMIIH5AIBAzELMAkGBSsOAwIaBQAwgAYLKoZIhvcNAQkQ
   AQiggASCARgwggEUMIHWCgEEoE2kSzBJMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMF
   UGFyaXMxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAMTD1BldGVyIFN5bHZlc3Rl
   cqEMBgorBgEEAak9AQIBonSkcjBwMQswCQYDVQQGEwJGUjEVMBMGA1UEChMMRWRl
   bFdlYiBTLkEuMSgwJgYDVQQLEx9DbGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2
   aWNlMSAwHgYDVQQDExdUaW1lIFN0YW1waW5nIEF1dGhvcml0eTAfMAcGBSsOAwIa
   BBR1toWvb4lGfegHFSUeRZePzR+lZgIHAXgKHsqIIxgPMjAwMDA0MTcxNzE2MTda
   AAAAAKCCA+AwggPcMIICxKADAgECAggAlIgXF2Q3MjANBgkqhkiG9w0BAQQFADBw
   MQswCQYDVQQGEwJGUjEVMBMGA1UEChMMRWRlbFdlYiBTLkEuMSgwJgYDVQQLEx9D
   bGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2aWNlMSAwHgYDVQQDExdUaW1lIFN0
   YW1waW5nIEF1dGhvcml0eTAeFw0wMDAxMjUxNjE5MzhaFw0yMDAxMjAxNjE5Mzha
   MHAxCzAJBgNVBAYTAkZSMRUwEwYDVQQKEwxFZGVsV2ViIFMuQS4xKDAmBgNVBAsT
   H0NsZXBzeWRyZSBEZW1vbnN0cmF0aW9uIFNlcnZpY2UxIDAeBgNVBAMTF1RpbWUg
   U3RhbXBpbmcgQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
   AQEA+sMXruu3neurvQV+OUNtBEVYdAWlzPNsL4yOd37CnxIRXH3bviMompDSq8ai
   ur2jfpmmmSGl2JC5z6cjTqBWoMEKRomOPJFnN/2bq0kX/Eql8uRMbuNqHJKXBG9/
   DFz7dMuVfkzDWBLoqdbw3RJEFeeLLq9RwAxfqGX8R6HJmB/U4eq8HBonu4tW8RJV
   EPSO2J8ZnB6B99tj3Yg3P3F5W5biX4LVEhkFDeE9pW1m5Cwe7cdMuN+qOMgVaq4l
   fUYqB/mDd8RR7pDcBdDD8PFf6NTtXTRwkZ2fCFV9W+WNXzVZg05yGbuciNF6/COl
   hJm0F4pNbJ3QpjWAX8r7JItUHQIDAQABo3oweDAPBgNVHRMECDAGAQH/AgEAMBYG
   A1UdJQEB/wQMMAoGCCsGAQUFBwMKME0GCCsGAQUFBwEBAQH/BD4wPDA6BggrBgEF



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 46]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   BQcwBIYuaHR0cHM6Ly9jbGVwc3lkcmUuZWRlbHdlYi5mci9kdmNzL3NlcnZpY2Ut
   Y2NwZDANBgkqhkiG9w0BAQQFAAOCAQEACNqvWwk5ZtO+gB3XcrUsowT7RvgF9b+D
   821tMigcRu4P6jBhih6KA06YgWAflxdT0VRzP3KYRdMQmtN3uHQOmpApjqyk69Ik
   bfYhHT9SiyzmkudSxlSTkbxXdCE4OXXNMElUE5Rs/vFkOB9ffbvgPqjxKBzx2Sj6
   Mh47SL9ccCEp775yJNoN+VF6/tf1/+jC6sZMRRRRU/0A1VvMZyojlDGewpA4m7Df
   +d5nDFdc17D88nKWxNF6naDmUSSZnonGOflyekT9LT+838clJ5ShtX26BnVnHJVs
   vSx0QT7NzTlcLpzDwwnjedXrhejxcimA9sZuYRtY/Ic+2eFTEOCxBTGCArswggK3
   AgEBMHwwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIgUy5BLjEoMCYG
   A1UECxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEgMB4GA1UEAxMX
   VGltZSBTdGFtcGluZyBBdXRob3JpdHkCCACUiCVyNSdQMAkGBSsOAwIaBQCgggEU
   MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABCDAcBgkqhkiG9w0BCQUxDxcNMDAw
   NDE3MTcxNjE5WjAjBgkqhkiG9w0BCQQxFgQUaFDckCAuwvBVFX93qaYMNMwTBvow
   gbIGCyqGSIb3DQEJEAIMMYGiMIGfMIGcMIGZBBRc8RjzSsq0Z9bY5/g7Stl6MqVD
   pTCBgDB0pHIwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIgUy5BLjEo
   MCYGA1UECxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEgMB4GA1UE
   AxMXVGltZSBTdGFtcGluZyBBdXRob3JpdHkCCACUiCVyNSdQMA0GCSqGSIb3DQEB
   AQUABIIBAC5wn1ZeAVap4UeBEjUhKQkWeu1F+Vqi7eT+nSzk2hJmYhRZYYtQewGC
   Pb1+5jjQqKA3mHkTJjkpxnIgqZVx51N/eXeY7yMCTrm9kJusBaJwjzpCNpwssJSx
   Kws2lA54DrDRCSBjvP/NMvFa06ufk5xao1iZoCgR4IBNTR53BPRQB9WLVKAjMv+m
   nOK6uNtVR8nIugfvkBRIqLbFfNWpIHQcVu+PG7P8h22B8dRvGocwkkdp4HngvBCZ
   z002TDYDUXLRW6YeLYbxHwrov+s4+c4a7LCPUa4qO0aEv02Mn+4f78U1o2O+OMAD
   fDpeuM87GBCI27tPePb75ByN1Pj761AAAAAA
   -----END PKCS7-----




Appendix G - Acknowledgements

   This document is based on two initial works from Robert Zuccherato
   and Carlisle Adams, both at Entrust Technologies, for time stamping
   and for notary and data certification services.

   Thanks to Denis Pinkas, Bull and Bruno Salgueiro, SIBS for valuable
   comments.


Appendix G - Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.  This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other



Adams, Sylvester, Zolotarev, Zuccherato                        [Page 47]

draft-ietf-pkix-dcs-06.txt   DVCS Protocols           September 14, 2000


   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process shall be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.

   This document expires expires March 14, 2001.



































Adams, Sylvester, Zolotarev, Zuccherato                        [Page 48]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/