RFC 5126
CMS Advanced Electronic Signatures (CAdES)
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.
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.
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.
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
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.
+----------------------- 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 2B.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.
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.
+---------------------- 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 2B.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.
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.
+--------------------------- 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.
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;
- 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
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.
+----------------------------------------------------- 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.
+------------------------------------------------ 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.
+-------------------------------------------- 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.
+----------------------------- 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-AB.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;
- 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;
- 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
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.
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
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.
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
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)
