[RFC2119]  Bradner, S., "Key works for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119, March 1997.   [RFC2511]  Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet              X.509 Certificate Request Message Format", RFC 2511, March              1999.   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",              RFC 2246, January 1999.   [RFC2634]  Hoffman P., "Enhanced Security Services for S/MIME", RFC              2634, June 1999.   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.              Adams, "X.509 Internet Public Key Infrastructure Online              Certificate Status Protocol", RFC 2560, June 1999.Adams, et al.                 Experimental                     [Page 25]RFC 3029                     DVCS Protocols                February 200114.  Authors' Addresses   Carlisle Adams   Entrust Technologies   1000 Innovation Drive   Ottawa, Ontario   K2K 3E7   CANADA   EMail: cadams@entrust.com   Michael Zolotarev   Baltimore Technologies Pty Limited   5th Floor, 1 James Place   North Sydney, NSW 2060   AUSTRALIA   EMail: mzolotarev@baltimore.com   Peter Sylvester   EdelWeb SA - Groupe ON-X Consulting   15, Quai de Dion Bouton   F-92816 Puteaux Cedex   FRANCE   EMail: peter.sylvester@edelweb.fr   Robert Zuccherato   Entrust Technologies   1000 Innovation Drive   Ottawa, Ontario   K2K 3E7   CANADA   EMail: robert.zuccherato@entrust.comAdams, et al.                 Experimental                     [Page 26]RFC 3029                     DVCS Protocols                February 2001APPENDIX A - PKCS #9 Attribute   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 validation   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 an 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, et al.                 Experimental                     [Page 27]RFC 3029                     DVCS Protocols                February 2001      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 verify a signature on 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, et al.                 Experimental                     [Page 28]RFC 3029                     DVCS Protocols                February 2001      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.        Organizations require that encrypted documents need to be        recoverable.  One simple way is to always encrypt documents with        additional recipients that act as 'domain encryption centers' or        'recovery centers'.  This is not a technically difficultAdams, et al.                 Experimental                     [Page 29]RFC 3029                     DVCS Protocols                February 2001        problem, but may require complicated and difficult interactions        with the end user, in particular when the document's recipients        are in several different organizations.        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        organizations, 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 organization.  The remotes organization'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 indicating 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 use 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 organization'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:   RFC 3029 on Data Validation and Certification Server ProtocolsAdams, et al.                 Experimental                     [Page 30]RFC 3029                     DVCS Protocols                February 2001   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 SyntaxPKIXDVCS {iso(1) identified-organization(3) dod(6) internet(1)