Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5126

CMS Advanced Electronic Signatures (CAdES)

Pages: 141
Informational
Obsoletes:  3126
Part 5 of 7 – Pages 86 to 109
First   Prev   Next

Top   ToC   RFC5126 - Page 86   prevText

Annex B (Informative): Extended Forms of Electronic Signatures

Section 4 provides an overview of the various formats of electronic signatures included in the present document. This annex lists the attributes that need to be present in the various extended electronic signature formats and provides example validation sequences using the extended formats.

B.1. Extended Forms of Validation Data

The Complete validation data (CAdES-C) described in Section 4.3 and illustrated in Figure 3 may be extended to create electronic signatures with extended validation data. Some electronic signature forms that include extended validation are explained below. An X-Long electronic signature (CAdES-X Long) is the CAdES-C with the values of the certificates and revocation information. This form of electronic signature can be useful when the verifier does not have direct access to the following information: - 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 CAdES-C. In some situations, additional time-stamps may be created and added to the Electronic Signatures as additional attributes. For example: - time-stamping all the validation data as held with the ES (CAdES-C), this eXtended validation data is called a CAdES-X Type 1; or - time-stamping individual reference data as used for complete validation. This form of eXtended validation data is called an CAdES-X Type 2. NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X Type 2 are discussed in Annex C.4.4. The above time-stamp forms can be useful when it is required to counter the risk that any CA keys used in the certificate chain may be compromised.
Top   ToC   RFC5126 - Page 87
   A combination of the two formats above may be used.  This form of
   eXtended validation data is called an ES X-Long Type 1 or CAdES-X
   Long Type 2.  This form of electronic signature can be useful when
   the verifier needs both the values and proof of when the validation
   data existed.

      NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and
      CAdES-X long Type 2 are discussed in Annex C.4.6.

B.1.1. CAdES-X Long

An electronic signature with the additional validation data forming the CAdES-X Long form (CAdES-X-Long) is illustrated in Figure B.1 and comprises the following: - CAdES-BES or CAdES-EPES, as defined in Sections 4.3 , 5.7, or 5.8; - complete-certificate-references attribute, as defined in Section 6.2.1; - complete-revocation-references attribute, as defined in Section 6.2.2. The following attributes are required if a TSP is not providing a time-mark of the ES: - signature-time-stamp attribute, as defined in Section 6.1.1. The following attributes are required if the full certificate values and revocation values are not already included in the CAdES-BES or CAdES-EPES: - certificate-values attribute, as defined in Section 6.3.3; - revocation-values attribute, as defined in Section 6.3.4. If attributes certificates are used, then the following attributes may be present: - attribute-certificate-references attribute, defined in Section 6.2.3; - attribute-revocation-references attribute, as defined in Section 6.2.4. Other unsigned attributes may be present, but are not required.
Top   ToC   RFC5126 - Page 88
      NOTE: Attribute certificate and revocation references are only
      present if a user attribute certificate is present in the
      electronic signature; see Sections 6.2.2 and 6.2.3.

+---------------------- CAdES-X-Long --------------------------------+
|+-------------------------------------- CAdES-C ---+                |
||                                     +----------+ | +-------------+|
||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | |             ||
|||                                  | |over      | | | Complete    ||
|||+---------++----------++---------+| |digital   | | | certificate ||
||||         ||          ||         || |signature | | |    and      ||
||||Signer's ||  Signed  ||Digital  || |          | | | revocation  ||
||||Document ||Attributes||signature|| |Optional  | | |    data     ||
||||         ||          ||         || |when      | | |             ||
|||+---------++----------++---------+| |timemarked| | |             ||
||+----------------------------------+ +----------+ | |             ||
||                                     +-----------+| +-------------+|
||                                     |Complete   ||                |
||                                     |certificate||                |
||                                     |and        ||                |
||                                     |revocation ||                |
||                                     |references ||                |
||                                     +-----------+|                |
|+--------------------------------------------------+                |
|                                                                    |
+--------------------------------------------------------------------+

             Figure B.1: Illustration of CAdES-X-Long

B.1.2. CAdES-X Type 1

An electronic signature with the additional validation data forming the eXtended validation data - Type 1 X is illustrated in Figure B.2 and comprises the following: - the CAdES-BES or CAdES-EPES, as defined in Sections 4.2, 5.7, or 5.8; - complete-certificate-references attribute, as defined in Section 6.2.1; - complete-revocation-references attribute, as defined in Section 6.2.2; - CAdES-C-Timestamp attribute, as defined in Section 6.3.5.
Top   ToC   RFC5126 - Page 89
   The following attributes are required if a TSP is not providing a
   time-mark of the ES:

      - signature-time-stamp attribute, as defined in Section 6.1.1.

   If attributes certificates are used, then the following attributes
   may be present:

      - attribute-certificate-references attribute, defined in Section
        6.2.3;

      - attribute-revocation-references attribute, as defined in Section
        6.2.4.

   Other unsigned attributes may be present, but are not required.

+------------------------ CAdES-X-Type 1 ----------------------------+
|+---------------------------------- CAdES-C ------+                 |
||                                    +----------+ | +-------------+ |
||+--- CAdES-BES or CAdES-EPES ------+|Timestamp | | |             | |
|||                                  ||over      | | |             | |
|||+---------++----------++---------+||digital   | | |             | |
||||Signer's ||  Signed  || Digital |||signature | | | Timestamp   | |
||||Document ||Attributes||signature|||          | | |    over     | |
||||         ||          ||         |||Optional  | | |   CAdES-C   | |
|||+---------++----------++---------+||when      | | |             | |
||+----------------------------------+|timemarked| | |             | |
||                                    +----------+ | |             | |
||                                    +-----------+| +-------------+ |
||                                    |Complete   ||                 |
||                                    |certificate||                 |
||                                    |   and     ||                 |
||                                    |revocation ||                 |
||                                    |references ||                 |
||                                    +-----------+|                 |
|+-------------------------------------------------+                 |
|                                                                    |
+--------------------------------------------------------------------+

               Figure B.2: Illustration of CAdES-X Type 1
Top   ToC   RFC5126 - Page 90

B.1.3. CAdES-X Type 2

An electronic signature with the additional validation data forming the eXtended Validation Data - Type 2 X is illustrated in Figure B.3 and comprises the following: - CAdES-BES or CAdES-EPES, as defined in Sections 4.2, 5.7, or 5.8; - complete-certificate-references attribute, as defined in Section 6.2.1; - complete-revocation-references attribute, as defined in Section 6.2.2; - time-stamped-certs-crls-references attribute, as defined in Section 6.3.6. The following attributes are required if a TSP is not providing a time-mark of the ES: - signature-time-stamp attribute, as defined in Section 6.1.1. If attributes certificates are used, then the following attributes may be present: - attribute-certificate-references attribute, defined in Section 6.2.3; - attribute-revocation-references attribute, as defined in Section 6.2.4. Other unsigned attributes may be present, but are not required.
Top   ToC   RFC5126 - Page 91
+----------------------- CAdES-X-Type 2 -----------------------------+
|+-------------------------------------- CAdES-C --+                 |
||                                    +----------+ |                 |
||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | |                 |
|||                                  ||over      | |                 |
|||+---------++----------++---------+||digital   | | +-------------+ |
||||         ||          ||         |||Signature | | | Timestamp   | |
||||Signer's ||  Signed  || Digital |||          | | | only over   | |
||||Document ||Attributes||signature|||Optional  | | | Complete    | |
||||         ||          ||         |||when      | | | certificate | |
|||+---------++----------++---------+||Timemarked| | |    and      | |
||+----------------------------------++----------+ | | revocation  | |
||                                    +-----------+| | references  | |
||                                    |Complete   || +-------------+ |
||                                    |certificate||                 |
||                                    |and        ||                 |
||                                    |revocation ||                 |
||                                    |references ||                 |
||                                    +-----------+|                 |
|+-------------------------------------------------+                 |
|                                                                    |
+--------------------------------------------------------------------+

               Figure B.3: Illustration of CAdES-X Type 2

B.1.4. CAdES-X Long Type 1 and CAdES-X Long Type 2

An electronic signature with the additional validation data forming the CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in Figure B.4 and comprises the following: - CAdES-BES or CAdES-EPES, as defined in Sections 4.3, 5.7, or 5.8; - complete-certificate-references attribute, as defined in Section 6.2.1; - complete-revocation-references attribute, as defined in Section 6.2.2; The following attributes are required if a TSP is not providing a time-mark of the ES: - signature-time-stamp attribute, as defined in Section 6.1.1.
Top   ToC   RFC5126 - Page 92
   The following attributes are required if the full certificate values
   and revocation values are not already included in the CAdES-BES or
   CAdES-EPES:

      - certificate-values attribute, as defined in Section 6.3.3;

      - revocation-values attribute, as defined in Section 6.3.4.

   If attributes certificates are used, then the following attributes
   may be present:

      - attribute-certificate-references attribute, defined in Section
        6.2.3;

      - attribute-revocation-references attribute, as defined in Section
        6.2.4.

   Plus one of the following attributes is required:

      - CAdES-C-Timestamp attribute, as defined in Section 6.3.5;

      - time-stamped-certs-crls-references attribute, as defined in
        Section 6.3.6.

   Other unsigned attributes may be present, but are not required.
Top   ToC   RFC5126 - Page 93
   +---------------------- CAdES-X-Type 1 or 2 ------------------------+
   |                                                   +--------------+|
   |+-------------------------------------- CAdES-C --+|+------------+||
   ||                                    +----------+ ||| Timestamp  |||
   ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | |||    over    |||
   |||                                  ||over      | |||  CAdES-C   |||
   |||+---------++----------++---------+||digital   | | +------------+ |
   ||||         ||          ||         |||signature | ||      or      ||
   ||||Signer's ||  Signed  || Digital |||          | ||+------------+||
   ||||Document ||Attributes||Signature|||Optional  | ||| Timestamp  |||
   ||||         ||          ||         |||when      | ||| only over  |||
   |||+---------++----------++---------+||timemarked| ||| complete   |||
   ||+----------------------------------++----------+ ||| certificate|||
   ||                                                 |||    and     |||
   ||                                    +-----------+||| revocation |||
   ||                                    |Complete   |||| references |||
   ||                                    |certificate|||+------------+||
   ||                                    |and        ||+--------------+|
   ||                                    |revocation || +------------+ |
   ||                                    |references || |Complete    | |
   ||                                    +-----------+| |certificate | |
   |+-------------------------------------------------+ |   and      | |
   |                                                    |revocation  | |
   |                                                    |  values    | |
   |                                                    +------------+ |
   +-------------------------------------------------------------------+

             Figure B.4: Illustration of CAdES-X Long Type 1
                         and CAdES-X Long Type 2

B.2. Time-Stamp Extensions

Each instance of the time-stamp attribute may include, as unsigned attributes in the signedData of the time-stamp, the following attributes related to the TSU: - complete-certificate-references attribute of the TSU, as defined in Section 6.2.1; - complete-revocation-references attribute of the TSU, as defined in Section 6.2.2; - certificate-values attribute of the TSU, as defined in Section 6.3.3; - revocation-values attribute of the TSU, as defined in Section 6.3.4.
Top   ToC   RFC5126 - Page 94
   Other unsigned attributes may be present, but are not required.

B.3. Archive Validation Data (CAdES-A)

Before the algorithms, keys, and other cryptographic data used at the time the CAdES-C was built become weak and the cryptographic functions become vulnerable, or the certificates supporting previous time-stamps expire, the signed data, the CAdES-C, and any additional information (i.e., any CAdES-X) should be time-stamped. If possible, this should use stronger algorithms (or longer key lengths) than in the original time-stamp. This additional data and time-stamp is called Archive validation data required for the ES Archive format (CAdES-A). The Time-stamping process may be repeated every time the protection used to time-stamp a previous CAdES-A becomes weak. A CAdES-A may thus bear multiple embedded time-stamps. An example of an electronic signature (ES), with the additional validation data for the CAdES-C and CAdES-X forming the CAdES-A is illustrated in Figure B.5.
Top   ToC   RFC5126 - Page 95
+--------------------------- CAdES-A---------------------------------+
|+----------------------------------------------------+              |
||                                    +--------------+| +----------+ |
||+--------------------- CAdES-C ----+|+------------+|| |          | |
|||                     +----------+ ||| Timestamp  ||| |          | |
|||+-- CAdES-BES ------+|Timestamp | |||   over     ||| |          | |
||||   or CAdES-EPES   ||over      | |||  CAdES-C   ||| |  Archive | |
||||                   ||digital   | ||+------------+|| |          | |
||||                   ||signature | ||     or       || |Timestamp | |
||||                   ||          | ||+------------+|| |          | |
||||                   ||optional  | ||| Timestamp  ||| |          | |
||||                   ||when      | ||| only over  ||| |          | |
||||                   ||timemarked| ||| complete   ||| |          | |
|||+-------------------++----------+ ||| certificate||| +----------+ |
|||                                  |||    and     |||              |
|||                   +-------------+||| revocation |||              |
|||                   | Complete    |||| references |||              |
|||                   | certificate |||+------------+||              |
|||                   | and         ||+--------------+|              |
|||                   | revocation  || +------------+ |              |
|||                   | references  || |Complete    | |              |
|||                   +-------------+| |certificate | |              |
||+----------------------------------+ |   and      | |              |
||                                     |revocation  | |              |
||                                     |  values    | |              |
||                                     +------------+ |              |
|+----------------------------------------------------+              |
+--------------------------------------------------------------------+

                    Figure B.5: Illustration of CAdES-A

   The CAdES-A comprises the following elements:

      - the CAdES-BES or CAdES-EPES, including their signed and unsigned
        attributes;

      - complete-certificate-references attribute, as defined in Section
        6.2.1;

      - complete-revocation-references attribute, as defined in Section
        6.2.2.

   The following attributes are required if a TSP is not providing a
   time-mark of the ES:

      - signature-time-stamp attribute, as defined in Section 6.1.1.
Top   ToC   RFC5126 - Page 96
   If attributes certificates are used, then the following attributes
   may be present:

      - attribute-certificate-references attribute, defined in Section
        6.2.3;

      - attribute-revocation-references attribute, as defined in Section
        6.2.4.

   The following attributes are required if the full certificate values
   and revocation values are not already included in the CAdES-BES or
   CAdES-EPES:

      - certificate-values attribute, as defined in Section 6.3.3;

      - revocation-values attribute, as defined in Section 6.3.4.

   At least one of the following two attributes is required:

      - CAdES-C-Timestamp attribute, as defined in Section 6.3.5;

      - time-stamped-certs-crls-references attribute, as defined in
        Section 6.3.6.

   The following attribute is required:

      - archive-time-stamp attributes, defined in Section 6.4.1.

   Several instances of the archive-time-stamp attribute may occur with
   an electronic signature, both over time and from different TSUs.  The
   time-stamp should be created using stronger algorithms (or longer key
   lengths) than in the original electronic signatures or time-stamps.

   Other unsigned attributes of the ES may be present, but are not
   required.

   The archive-time-stamp will itself contain the certificate and
   revocation information required to validate the archive-time-stamp;
   this may include the following unsigned attributes:

      - complete-certificate-references attribute of the TSU, as defined
        in Section 6.2.1;

      - complete-revocation-references attribute of the TSU, as defined
        in Section 6.2.2;

      - certificate-values attribute of the TSU, as defined in Section
        6.3.3;
Top   ToC   RFC5126 - Page 97
      - revocation-values attribute of the TSU, as defined in Section
        6.3.4.

   Other unsigned attributes may be present, but are not required.

B.4. Example Validation Sequence

As described earlier, the signer or initial verifier may collect all the additional data that forms the electronic signature. Figure B.6 and the subsequent description describe how the validation process may build up a complete electronic signature over time. +------------------------------------------ CAdES-C -------------+ |+------------------------------- CAdES-T ------+ | ||+-------------- CAdES ------------+ | | |||+--------------------++---------+|+---------+| +-----------+ | |||| ________ || |||Timestamp|| |Complete | | |||||Sign.Pol| ||Digital |||over || |certificate| | ||||| Id. | Signed ||signature|||digital || | and | | ||||| option.|attributes|| |||signature|| |revocation | | |||||________| |+---------+|+---------+| |references | | |||+--------------------+ | ^ | +-----------+ | ||+---------------------------------+ | | ^ | || 1 | / | | | |+---------------------- | ------------/--------+ | | +----------------------- | ---------- / --------------- / -------+ | /2 ----3-------- +----------+ | / / | | v / | | Signer's | +---------------------+ +-------------+ | document |----->| Validation Process |---->|- Valid | | | +---------------------+ 4 |- Invalid | +----------+ | ^ | ^ |- Validation | v | v | | Incomplete | +---------+ +--------+ +-------------+ |Signature| |Trusted | | Policy | |Service | | Issuer | |Provider| +---------+ +--------+ Figure B.6: Illustration of a CAdES validation sequence Soon after receiving the electronic signature (CAdES) from the signer (1), the digital signature value may be checked; the validation process shall at least add a time-stamp (2), unless the signer has provided one which is trusted by the verifier. The validation process may also validate the electronic signature using additional data (e.g., certificates, CRL, etc.) provided by Trusted Service
Top   ToC   RFC5126 - Page 98
   Providers.  When applicable, the validation process will also need to
   conform to the requirements specified in a signature policy.  If the
   validation process is validation incomplete, then the output from
   this stage is the CAdES-T.

   To ascertain the validity status as Valid or Invalid and communicate
   that to the user (4), all the additional data required to validate
   the CAdES-C must be available (e.g., the complete certificate and
   revocation information).

   Once the data needed to complete validation data references (CAdES-C)
   is available, then the validation process should:

      - obtain all the necessary additional certificates and revocation
        status information;

      - complete all the validation checks on the ES using the complete
        certificate and revocation information (if a time-stamp is not
        already present, this may be added at the same stage, combining
        the CAdES-T and CAdES-C processes);

      - record the complete certificate and revocation references (3);

      - indicate the validity status to the user (4).

   At the same time as the validation process creates the CAdES-C, the
   validation process may provide and/or record the values of
   certificates and revocation status information used in CAdES-C (5).
   The end result is called CAdES-X Long.

   This is illustrated in Figure B.7.
Top   ToC   RFC5126 - Page 99
+----------------------------------------------------- CAdES-X Long -+
|+------------------------------- CAdES-C -------------+             |
||+-------------- CAdES ------------+                  |             |
|||+--------------------++---------+|+---------+       |+-----------+|
|||| ________           ||         |||Timestamp|       ||Complete   ||
|||||Sign.Pol|          ||Digital  |||over     |       ||certificate||
|||||  Id.   | Signed   ||signature|||digital  |       ||   and     ||
||||| option.|attributes||         |||signature|       ||revocation ||
|||||________|          ||         ||+---------+       ||  values   ||
|||+--------------------++---------+|  ^  +-----------+|+-----------+|
||+---------------------------------+  |  |Complete   ||      ^      |
||                         |           |  |certificate||      |      |
||                         |         2 |  |   and     ||      |      |
||                         |           |  |revocation ||      |      |
||                         |           |  |references ||      |      |
||                       1 |          /   +-----------+|      |      |
|+------------------------ | ------- / --------- ^-----+     /       |
+------------------------- | ------ / ---------- |--------- / -------+
                           |       /      ----- /  ------- /
      +----------+         |      /      /  3     /   5
      |          |         v     |      |        |
      | Signer's |      +--------------------+      +-----------+
      | document |----->| Validation Process |----->| - Valid   |
      |          |      +--------------------+  4   | - Invalid |
      +----------+          |  ^       |  ^         +-----------+
                            v  |       v  |
                        +---------+ +--------+
                        |Signature| |Trusted |
                        | Policy  | |Service |
                        | Issuer  | |Provider|
                        +---------+ +--------+

          Figure B.7: Illustration of a CAdES validation sequence
                      with CAdES-X Long

   When the validation process creates the CAdES-C, it may also create
   extended forms of validation data.

   A first alternative is to time-stamp all data forming the CAdES-X
   Type 1.

   This is illustrated in Figure B.8.
Top   ToC   RFC5126 - Page 100
+------------------------------------------------ CAdES-X Type 1 -----+
|+------------------------------- CAdES-C ------------------+         |
||+-------------- CAdES ------------+                       |         |
|||+--------------------++---------+|+---------++----------+|+-------+|
|||| ________           ||         |||Timestamp|| Complete |||       ||
|||||Sign.Pol|          ||Digital  |||over     ||  cert.   |||Time-  ||
|||||  Id.   | Signed   ||signature|||digital  ||   and    |||stamp  ||
||||| option.|attributes||         |||signature||  revoc.  ||| over  ||
|||||________|          |+---------+|+---------+|references|||CAdES-C||
|||+--------------------+           |    ^      |          |||       ||
||+---------------------------------+    |      +----------+|+-------+|
||                         |             |            ^     |    ^    |
||                       1 |            /             |     |    |    |
|+------------------------ | --------- / ----------- / -----+    |    |
+------------------------- | -------- / ----------- / --------- / ----+
                           |       2 /     ---3----            /
      +----------+         |        /    /   -----------5------
      |          |         v       |    |  /
      | Signer's |      +--------------------+       +-----------+
      | document |----->| Validation Process |-----> | - Valid   |
      |          |      +--------------------+  4    | - Invalid |
      +----------+          |  ^       |  ^          +-----------+
                            v  |       v  |
                        +---------+ +--------+
                        |Signature| |Trusted |
                        | Policy  | |Service |
                        | Issuer  | |Provider|
                        +---------+ +--------+

    Figure B.8: Illustration of CAdES with eXtended validation data
                CAdES-X Type 1

   Another alternative is to time-stamp the certificate and revocation
   information references used to validate the electronic signature (but
   not the signature) (6).  The end result is called CAdES-X Type 2.

   This is illustrated in Figure B.9.
Top   ToC   RFC5126 - Page 101
+-------------------------------------------- CAdES-X Type 2 --------+
|+------------------------------- CAdES-C -------------+             |
||+-------------- CAdES ------------+                  |             |
|||+--------------------++---------+|+---------+       |+-----------+|
|||| ________           ||         |||Timestamp|       ||Timestamp  ||
|||||Sign.Pol|          ||         |||over     |       ||   over    ||
|||||  Id.   | Signed   ||Digital  |||digital  |       ||complete   ||
||||| option.|attributes||signature|||signature|       ||certificate||
|||||________|          ||         |||         |       ||           ||
|||+--------------------++---------+|+---------+       ||   and     ||
||+---------------------------------+  ^  +-----------+||revocation ||
||                         |           |  |Complete   |||references ||
||                         |           |  |certificate||+-----------+|
||                         |           |  |   and     ||     ^       |
||                       1 |         2 |  |revocation ||     |       |
||                         |           |  |references ||     |       |
||                         |           |  +-----------+|     |       |
|+------------------------ | --------- | --- ^ --------+     |       |
|                          |           |   3 |              /        |
|                          |           |    /    ----------          |
|                          |          /    /    /   6                |
|                          |         /    /    /                     |
|                          |        /    /    /                      |
+------------------------- | ----- | -- | -- / ----------------------+
                           |       |    |   |
                           v       |    |   |
                        +--------------------+      +-----------+
                        | Validation Process |----->| - Valid   |
                        +--------------------+  4   | - Invalid |
                            |  ^       |  ^         +-----------+
                            v  |       v  |
                        +---------+ +--------+
                        |Signature| |Trusted |
                        | Policy  | |Service |
                        | Issuer  | |Provider|
                        +---------+ +--------+

   Figure B.9: Illustration of CAdES with eXtended validation data
               CAdES-X Type 2

   Before the algorithms used in any of the electronic signatures become
   or are likely to be compromised or rendered vulnerable in the future,
   it may be necessary to time-stamp the entire electronic signature,
   including all the values of the validation and user data as an ES
   with Archive validation data (CAdES-A) (7).

   A CAdES-A is illustrated in Figure B.10.
Top   ToC   RFC5126 - Page 102
+----------------------------- CAdES-A ---------------------------+
|                                                                 |
|  +-- CAdES-X Long Type 1 or 2  ----------+                      |
|  |                                       |   +------------+     |
|  |                                       |   |            |     |
|  |                                       |   |  Archive   |     |
|  |                                       |   | Time-stamp |     |
|  |                                       |   |            |     |
|  |                                       |   +------------+     |
|  +---------------------------------------+         ^            |
|  +----------+          ^   ^   ^   ^               |            |
|  |          |          |   |   |   |              /             |
|  | Signers' |          |   |   |   |             /              |
|  | Document |\         |   |   |   |            /               |
|  |          | \ 1    2 | 3 | 5 | 6 |         7 /                |
|  +----------+  \       |   |   |   |          /                 |
|                 \      |   |   |   |         /                  |
+----------------- \ --- | - | - | - | ------ / ------------------+
                    \    |   |   |   |       |
                     |   |   |   |   |       |
                     |   |   |   |   |       |
                     v   v   |   |   |       |
                 +-----------------------------+      +-----------+
                 |      Validation Process     |----->| - Valid   |
                 +-----------------------------+  4   | - Invalid |
                     |  ^       |  ^                  +-----------+
                     v  |       v  |
                 +---------+ +--------+
                 |Signature| |Trusted |
                 | Policy  | |Service |
                 | Issuer  | |Provider|
                 +---------+ +--------+

                 Figure B.10: Illustration of CAdES-A

B.5. Additional Optional Features

The present document also defines additional optional features to: - indicate a commitment type being made by the signer; - indicate the claimed time when the signature was done; - indicate the claimed location of the signer; - indicate the claimed or certified role under which a signature was created;
Top   ToC   RFC5126 - Page 103
      - support counter signatures;

      - support multiple signatures.

Annex C (Informative): General Description

This annex explains some of the concepts and provides the rationale for normative parts of the present document. The specification below includes a description of why and when each component of an electronic signature is useful, with a brief description of the vulnerabilities and threats and the manner by which they are countered.

C.1. The Signature Policy

The signature policy is a set of rules for the creation and validation of an electronic signature, under which the signature can be determined to be valid. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. A signature policy may be issued, for example, by a party relying on the electronic signatures and selected by the signer for use with that relying party. Alternatively, a signature policy may be established through an electronic trading association for use amongst its members. Both the signer and verifier use the same signature policy. The signature policy may be explicitly identified or may be implied by the semantics of the data being signed and other external data, like a contract being referenced, which itself refers to a signature policy. An explicit signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. To facilitate the automatic processing of an electronic signature, the parts of the signature policy, which specify the electronic rules for the creation and validation of the electronic signature, also need to be comprehensively defined and in a computer-processable form. The signature policy thus includes the following: - rules that apply to technical validation of a particular signature;
Top   ToC   RFC5126 - Page 104
      - rules that may be implied through adoption of Certificate
        Policies that apply to the electronic signature (e.g., rules for
        ensuring the secrecy of the private signing key);

      - rules that relate to the environment used by the signer, e.g.,
        the use of an agreed CAD (Card Accepting Device) used in
        conjunction with a smart card.

   For example, the major rules required for technical validation can
   include:

      - recognized root keys or "top-level certification authorities";

      - acceptable certificate policies (if any);

      - necessary certificate extensions and values (if any);

      - the need for the revocation status for each component of the
        certification tree;

      - acceptable TSAs (if time-stamp tokens are being used);

      - acceptable organizations for keeping the audit trails with
        time-marks (if time-marking is being used);

      - acceptable AAs (if any are being used),and;

      - rules defining the components of the electronic signature that
        shall be provided by the signer with data required by the
        verifier when required to provide long-term proof.

C.2. Signed Information

The information being signed may be defined as a MIME-encapsulated message that can be used to signal the format of the content in order to select the right display or application. It can be composed of formatted data, free text, or fields from an electronic form (e-form). For example, the Adobe(tm) format "pdf" or the eXtensible Mark up Language (XML) may be used. Annex D defines how the content may be structured to indicate the type of signed data using MIME.

C.3. Components of an Electronic Signature

C.3.1. Reference to the Signature Policy

When two independent parties want to evaluate an electronic signature, it is fundamental that they get the same result. This requirement can be met using comprehensive signature policies that
Top   ToC   RFC5126 - Page 105
   ensure consistency of signature validation.  Signature policies can
   be identified implicitly by the data being signed, or they can be
   explicitly identified using the CAdES-EPES form of electronic
   signature; the CAdES-EPES mandates a consistent signature policy must
   be used by both the signer and verifier.

   By signing over the Signature Policy Identifier in the CAdES-EPES,
   the signer explicitly indicates that he or she has applied the
   signature policy in creating the signature.

   In order to unambiguously identify the details of an explicit
   signature policy that is to be used to verify a CAdES-EPES, the
   signature, an identifier, and hash of the "Signature policy" shall be
   part of the signed data.  Additional information about the explicit
   policy (e.g., web reference to the document) may be carried as
   "qualifiers" to the Signature Policy Identifier.

   In order to unambiguously identify the authority responsible for
   defining an explicit signature policy, the "Signature policy" can be
   signed.

C.3.2. Commitment Type Indication

The commitment type can be indicated in the electronic signature either: - explicitly using a "commitment type indication" in the electronic signature; - implicitly or explicitly from the semantics of the signed data. If the indicated commitment type is explicit using a "commitment type indication" in the electronic signature, acceptance of a verified signature implies acceptance of the semantics of that commitment type. The semantics of explicit commitment type indications may be subject to signer and verifier agreement, specified as part of the signature policy or registered for generic use across multiple policies. If a CAdES-EPES electronic signature format is used and the electronic signature includes a commitment type indication other than one of those recognized under the signature policy, the signature shall be treated as invalid. How commitment is indicated using the semantics of the data being signed is outside the scope of the present document.
Top   ToC   RFC5126 - Page 106
      NOTE: Examples of commitment indicated through the semantics of
      the data being signed are:

      - an explicit commitment made by the signer indicated by the type
        of data being signed over.  Thus, the data structure being
        signed can have an explicit commitment within the context of the
        application (e.g., EDIFACT purchase order);

      - an implicit commitment that is a commitment made by the signer
        because the data being signed over has specific semantics
        (meaning), which is only interpretable by humans, (i.e., free
        text).

C.3.3. Certificate Identifier from the Signer

In many real-life environments, users will be able to get from different CAs or even from the same CA, different certificates containing the same public key for different names. The prime advantage is that a user can use the same private key for different purposes. Multiple use of the private key is an advantage when a smart card is used to protect the private key, since the storage of a smart card is always limited. When several CAs are involved, each different certificate may contain a different identity, e.g., as a citizen of a nation or as an employee from a company. Thus, when a private key is used for various purposes, the certificate is needed to clarify the context in which the private key was used when generating the signature. Where there is the possibility that multiple private keys are used, it is necessary for the signer to indicate to the verifier the precise certificate to be used. Many current schemes simply add the certificate after the signed data and thus are vulnerable to substitution attacks. If the certificate from the signer was simply appended to the signature and thus not protected by the signature, anyone could substitute one certificate for another, and the message would appear to be signed by someone else. In order to counter this kind of attack, the identifier of the signer has to be protected by the digital signature from the signer. In order to unambiguously identify the certificate to be used for the verification of the signature, an identifier of the certificate from the signer shall be part of the signed data.

C.3.4. Role Attributes

While the name of the signer is important, the position of the signer within a company or an organization is of paramount importance as well. Some information (i.e., a contract) may only be valid if signed by a user in a particular role, e.g., a Sales Director. In
Top   ToC   RFC5126 - Page 107
   many cases, who the sales Director really is, is not that important,
   but being sure that the signer is empowered by his company to be the
   Sales Director is fundamental.

   The present document defines two different ways for providing this
   feature:

      - by placing a claimed role name in the CMS signed attributes
        field;

      - by placing an attribute certificate containing a certified role
        name in the CMS signed attributes field.

      NOTE: Another possible approach would have been to use additional
      attributes containing the roles name(s) in the signer's identity
      certificate.  However, it was decided not to follow this approach
      as it significantly complicates the management of certificates.
      For example, by using separate certificates for the signer's
      identity and roles means new identity keys need not be issued if a
      user's role changes.

C.3.4.1. Claimed Role
The signer may be trusted to state his own role without any certificate to corroborate this claim; in which case, the claimed role can be added to the signature as a signed attribute.
C.3.4.2. Certified Role
Unlike public key certificates that bind an identifier to a public key, Attribute Certificates bind the identifier of a certificate to some attributes, like a role. An Attribute Certificate is NOT issued by a CA but by an Attribute Authority (AA). The Attribute Authority, in most cases, might be under the control of an organization or a company that is best placed to know which attributes are relevant for which individual. The Attribute Authority may use or point to public key certificates issued by any CA, provided that the appropriate trust may be placed in that CA. Attribute Certificates may have various periods of validity. That period may be quite short, e.g., one day. While this requires that a new Attribute Certificate be obtained every day, valid for that day, this can be advantageous since revocation of such certificates may not be needed. When signing, the signer will have to specify which Attribute Certificate it selects. In order to do so, the Attribute Certificate will have to be included in the signed data in order to be protected by the digital signature from the signer.
Top   ToC   RFC5126 - Page 108
   In order to unambiguously identify the attribute certificate(s) to be
   used for the verification of the signature, an identifier of the
   attribute certificate(s) from the signer shall be part of the signed
   data.

C.3.5. Signer Location

In some transactions, the purported location of the signer at the time he or she applies his signature may need to be indicated. For this reason, an optional location indicator shall be able to be included. In order to provide indication of the location of the signer at the time he or she applied his signature, a location attribute may be included in the signature.

C.3.6. Signing Time

The present document provides the capability to include a claimed signing time as an attribute of an electronic signature. Using this attribute, a signer may sign over a time that is the claimed signing time. When an ES with Time is created (CAdES-T), then either a trusted time-stamp is obtained and added to the ES or a trusted time-mark exists in an audit trail. When a verifier accepts a signature, the two times shall be within acceptable limits. A further optional attribute is defined in the present document to time-stamp the content and to provide proof of the existence of the content, at the time indicated by the time-stamp token. Using this optional attribute, a trusted secure time may be obtained before the document is signed and included under the digital signature. This solution requires an online connection to a trusted time-stamping service before generating the signature and may not represent the precise signing time, since it can be obtained in advance. However, this optional attribute may be used by the signer to prove that the signed object existed before the date included in the time-stamp (see Section 5.11.4).

C.3.7. Content Format

When presenting signed data to a human user, it may be important that there is no ambiguity as to the presentation of the signed information to the relying party. In order for the appropriate representation (text, sound, or video) to be selected by the relying party when data (as opposed to data that has been further signed or encrypted) is encapsulated in the SignedData (indicated by the
Top   ToC   RFC5126 - Page 109
   eContentType within EncapsulatedContentInfo being set to id-data),
   further typing information should be used to identify the type of
   document being signed.  This is generally achieved using the MIME
   content typing and encoding mechanism defined in RFC 2045 [6]).
   Further information on the use of MIME is given in Annex F.

C.3.8. content-hints

The contents-hints attribute provides information on the innermost signed content of a multi-layer message where one content is encapsulated in another. This may be useful if the signed data is itself encrypted.

C.3.9. Content Cross-Referencing

When presenting a signed data is in relation to another signed data, it may be important to identify the signed data to which it relates. The content-reference and content-identifier attributes, as defined in ESS (RFC 2634 [5]), provide the ability to link a request and reply messages in an exchange between two parties.


(page 109 continued on part 6)

Next Section