rfc3029.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,647 行 · 第 1/5 页

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


















Adams, et al.                 Experimental                     [Page 24]

RFC 3029                     DVCS Protocols                February 2001


13.  References

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

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

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

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

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

   [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 2001


14.  Authors' Addresses

   Carlisle Adams
   Entrust Technologies
   1000 Innovation Drive
   Ottawa, Ontario
   K2K 3E7
   CANADA

   EMail: [e-mail]


   Michael Zolotarev
   Baltimore Technologies Pty Limited
   5th Floor, 1 James Place
   North Sydney, NSW 2060
   AUSTRALIA

   EMail: [e-mail]


   Peter Sylvester
   EdelWeb SA - Groupe ON-X Consulting
   15, Quai de Dion Bouton
   F-92816 Puteaux Cedex
   FRANCE

   EMail: [e-mail]


   Robert Zuccherato
   Entrust Technologies
   1000 Innovation Drive
   Ottawa, Ontario
   K2K 3E7
   CANADA

   EMail: [e-mail]













Adams, et al.                 Experimental                     [Page 26]

RFC 3029                     DVCS Protocols                February 2001


APPENDIX 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 difficult





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