tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5126

 
 
 

CMS Advanced Electronic Signatures (CAdES)

Part 5 of 7, p. 86 to 109
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 86 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part