rfc3126.txt

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

   some specific TSP services MAY be mandated by signature policy.  TSP
   supporting services may provide the following information: user
   certificates, cross-certificates, time-stamping tokens, CRLs, ARLs,
   OCSP responses.

   The following TSPs are used to support the validation or the
   verification of electronic signatures:

      *  Certification Authorities;
      *  Registration Authorities;
      *  Repository Authorities (e.g., a Directory);
      *  Time-Stamping Authorities;
      *  One-line Certificate Status Protocol responders;
      *  Attribute Authorities;
      *  Signature Policy Issuers.

   Certification Authorities provide users with public key certificates.

   Registration Authorities allows the registration of entities before a
   CA generates certificates.






Pinkas, et al.               Informational                      [Page 6]

RFC 3126              Electronic Signature Formats        September 2001


   Repository Authorities publish CRLs issued by CAs, cross-certificates
   (i.e., CA certificates) issued by CAs, signature policies issued by
   Signature Policy Issuers and optionally public key certificates
   (i.e., leaf certificates) issued by CAs.

   Time-Stamping Authorities attest that some data was formed before a
   given trusted time.

   One-line Certificate Status Protocol responders (OSCP responders)
   provide information about the status (i.e., revoked, not revoked,
   unknown) of a particular certificate.

   A Signature Policy Issuer issues signatures policies that define the
   technical and procedural requirements for electronic signature
   creation, validation and verification, in order to meet a particular
   business need.

   Attributes Authorities provide users with attributes linked to public
   key certificates

2.4  Electronic Signatures and Validation Data

   Validation of an electronic signature in accordance with this
   document requires:

      *  The electronic signature; this includes:

         -  the signature policy;
         -  the signed user data;
         -  the digital signature;
         -  other signed attributes provided by the signer;
         -  other unsigned attributes provided by the signer.

   Validation data which is the additional data needed to validate the
   electronic signature; this includes:

         -  certificates references;
         -  certificates;
         -  revocation status information references;
         -  revocation status information;
         -  time-stamps from Time Stamping Authorities (TSAs).

      *  The signature policy specifies the technical requirements on
         signature creation and validation in order to meet a particular
         business need.  A given legal/contractual context may recognize
         a particular signature policy as meeting its requirements.





Pinkas, et al.               Informational                      [Page 7]

RFC 3126              Electronic Signature Formats        September 2001


   For example: a specific signature policy may be recognized by court
   of law as meeting the requirements of the European Directive for
   electronic commerce.  A signature policy may be written using a
   formal notation like ASN.1 or in an informal free text form provided
   the rules of the policy are clearly identified.  However, for a given
   signature policy there shall be one definitive form which has a
   unique binary encoded value.

   Signed user data is the user's data that is signed.

   The Digital Signature is the digital signature applied over the
   following attributes provided by the signer:

      *  hash of the user data (message digest);
      *  signature Policy Identifier;
      *  other signed attributes

   The other signed attributes include any additional information which
   must be signed to conform to the signature policy or this document
   (e.g., signing time).

   According to the requirements of a specific signature policy in use,
   various Validation Data shall be collected and attached to or
   associated with the signature structure by the signer and/or the
   verifier.  The validation data includes CA certificates as well as
   revocation status information in the form of certificate revocation
   lists (CRLs) or certificate status information provided by an on-line
   service.  Additional data also includes time-stamps and other time
   related data used to provide evidence of the timing of given events.
   It is required, as a minimum, that either the signer or verifier
   obtains a time-stamp over the signer's signature or a secure time
   record of the electronic signature must be maintained.  Such secure
   records must not be undetectably modified and must record the time
   close to when the signature was first validated.

2.5  Forms of Validation Data

   An electronic signature may exist in many forms including:

      *  the Electronic Signature (ES), which includes the digital
         signature and other basic information provided by the signer;

      *  the ES with Time-Stamp (ES-T), which adds a time-stamp to the
         Electronic Signature, to take initial steps towards providing
         long term validity;






Pinkas, et al.               Informational                      [Page 8]

RFC 3126              Electronic Signature Formats        September 2001


      *  the ES with Complete validation data (ES-C), which adds to the
         ES-T references to the complete set of data supporting the
         validity of the electronic signature (i.e., revocation status
         information).

   The signer must provide at least the ES form, but in some cases may
   decide to provide the ES-T form and in the extreme case could provide
   the ES-C form.  If the signer does not provide ES-T, the verifier
   must either create the ES-T on first receipt of an electronic
   signature or shall keep a secure time record of the ES.  Either of
   these two approaches provide independent evidence of the existence of
   the signature at the time it was first verified which should be near
   the time it was created, and so protects against later repudiation of
   the existence of the signature.  If the signer does not provide ES-C
   the verifier must create the ES-C when the complete set of revocation
   and other validation data is available.

   The ES satisfies the legal requirements for electronic signatures as
   defined in the European Directive on electronic signatures, see Annex
   C for further discussion on relationship of this document to the
   Directive.  It provides basic authentication and integrity protection
   and can be created without accessing on-line (time-stamping)
   services. However, without the addition of a time-stamp or a secure
   time record the electronic signature does not protect against the
   threat that the signer later denies having created the electronic
   signature (i.e., does not provide non-repudiation of its existence).

   The ES-T time-stamp or time record should be created close to the
   time that ES was created to provide protection against repudiation.
   At this time all the data needed to complete the validation may not
   be available but what information is readily available may be used to
   carry out some of the initial checks.  For example, only part of the
   revocation information may be available for verification at that
   point in time.  Generally, the ES-C form cannot be created at the
   same time as the ES, as it is necessary to allow time for any
   revocation information to be captured.  Also, if a certificate is
   found to be temporarily suspended, it will be necessary to wait until
   the end of the suspension period.

   The signer should only create the ES-C in situations where it was
   prepared to wait for a sufficient length of time after creating the
   ES form before dispatching the ES-C.  This, however, has the
   advantage that the verifier can be presented with the complete set of
   data supporting the validity of the ES.

   Support for ES-C by the verifier is mandated (see clause 6 for
   specific conformance requirements).




Pinkas, et al.               Informational                      [Page 9]

RFC 3126              Electronic Signature Formats        September 2001


   An Electronic Signature (ES), with the additional validation data
   forming the ES-T and ES-C is illustrated in Figure 1:

+------------------------------------------------------------ES-C-----+
|+--------------------------------------------ES-T-----+              |
||+------Elect.Signature (ES)----------+ +------------+| +-----------+|
|||+---------+ +----------+ +---------+| |Time-Stamp  || |Complete   ||
||||Signature| |  Other   | | Digital || |over digital|| |certificate||
||||Policy ID| |  Signed  | |Signature|| |signature   || |and        ||
||||         | |Attributes| |         || +------------+| |revocation ||
|||+---------+ +----------+ +---------+|               | |references ||
||+------------------------------------+               | +-----------+|
|+-----------------------------------------------------+              |
+---------------------------------------------------------------------+

         Figure 1: Illustration of an ES, ES-T and ES-C

   The verifiers conformance requirements of an ES with a time-stamp of
   the digital signature is defined in subclause 6.2.

   The ES on its own satisfies the legal requirements for electronic
   signatures as defined in the European Directive on electronic
   signatures.  The signers conformance requirements of an ES are
   defined in subclause 6.1, and are met using a structure as indicated
   in figure 2:

               +------Elect.Signature (ES)-----------|
               |+---------+ +----------+ +---------+ |
               ||Signature| |  Other   | | Digital | |
               ||Policy ID| |  Signed  | |Signature| |
               ||         | |Attributes| |         | |
               |+---------+ +----------+ +---------+ |
               |+-----------------------------------+|

                  Figure 2: Illustration of an ES
















Pinkas, et al.               Informational                     [Page 10]

RFC 3126              Electronic Signature Formats        September 2001


   Where there are requirements for long term signatures without time-
   stamping the digital signature, then a secure record is needed of the
   time of verification in association with the electronic signature
   (i.e., both must be securely recorded).  In addition the certificates
   and revocation information used at the time of verification should to
   be recorded as indicated in figure 3 as an ES-C(bis).

   +-------------------------------------------------------ES-C-----+
   |                                                                |
   | +------Elect.Signature (ES)----------+|           +-----------+|
   | |+---------+ +----------+ +---------+||           |Complete   ||
   | ||Signature| |  Other   | | Digital |||           |certificate||
   | ||Policy ID| |  Signed  | |Signature|||           |and        ||
   | ||         | |Attributes| |         |||           |revocation ||
   | |+---------+ +----------+ +---------+||           |references ||
   | +------------------------------------+|           +-----------+|
   |                                                                |
   +----------------------------------------------------------------+

                Figure 3: Illustration of an ES-C(bis)

   The verifiers conformance requirements of an ES-C(bis) is defined in
   subclause 6.3.

   Note: A time-stamp attached to the electronic signature or a secure
   time record helps to protect the validity of the signature even if
   some of the verification data associated with the signature become
   compromised AFTER the signature was generated.  The time-stamp or a
   secure time record provides evidence that the signature was generated
   BEFORE the event of compromise; hence the signature will maintain its
   validity status.

2.6  Extended Forms of Validation Data

   The complete validation data (ES-C) described above may be extended
   to form an ES with eXtended validation data (ES-X) to meet following
   additional requirements.

   Firstly, when the verifier does not has access to,

      *  the signer's certificate,
      *  all the CA certificates that make up the full certification
         path,
      *  all the associated revocation status information, as referenced
         in the ES-C.






Pinkas, et al.               Informational                     [Page 11]

RFC 3126              Electronic Signature Formats        September 2001