SecureBlackbox 16: CAdES and Digital Signatures

CAdES is a new standard for advanced digital signature. It was introduced by the European Directive on a community framework for Electronic Signatures, which extends the previous standard, CMS, specifying several additional profiles. CAdES provides some important features of extended electronic signature lacking in CMS, such as long term validation -- the ability to prove signature validity after a long period, several years or even decades after it was created.

CAdES specifies additional forms, or profiles, that describe the structure of advanced electronic signature. These profiles are CAdES-T, CAdES-C, CAdES-X-L, and CAdES-A. Each following profile adds some properties to the previous one.

Contents

• What's New in CAdES
• CAdES-BES
• CAdES-EPES
• Electronic Signature Formats with Validation Data
• Electronic Signature with Time (CAdES-T)
• Electronic Signature with Complete Validation Data References (CAdES-C)
• Extended Long Electronic Signature (CAdES-X Long)
• Archival Electronic Signature (CAdES-A)
• Summary

What's New in CAdES

The philosophy of CAdES includes the concept of signature policies that can be used to establish technical consistency when validating electronic signatures.

When the signature policy used by the verifier is either explicitly indicated by the signer or is obvioElectronic Signature with Time (CAdES-T), due to the nature of the data being signed, consistent results can be obtained while validating an electronic signature.

When the signature policy being used by the verifier is neither indicated by the signer nor can be derived from other data, or the signature policy is incomplete, then the verifiers, including arbitrators, may obtain different results when validating an electronic signature. Therefore, comprehensive signature policies that ensure the consistency of signature validation are recommended from both the signer's and verifier's point of view.

Thus, we have two forms of CMS advanced electronic signature specified in the CAdES standard, namely, CAdES Basic Electronic Signature (CAdES-BES) and CAdES Explicit Policy-based Electronic Signature (CAdES-EPES). Conformance to the CAdES standard mandates that the signer creates one of these formats.

CAdES-BES

A CAdES Basic Electronic Signature (CAdES-BES) contains:

• The signed user data (e.g., the signer's document), as defined in CMS ( RFC 3852 [ 4])
• A collection of mandatory signed attributes, as defined in CMS ( RFC 3852 [ 4]) and in ESS ( RFC 2634 [ 5])
• Additional mandatory signed attributes, defined later
• The digital signature value computed on the user data and, when present, on the signed attributes, as defined in CMS ( RFC 3852 [ 4]).

CAdES-BES may contain:

• A collection of additional signed attributes
• A collection of optional unsigned attributes

The mandatory signed attributes are the following:

• Content-type: This is defined in RFC 3852 [ 4] and specifies the type of the EncapsulatedContentInfo value being signed.
• Message-digest: This is defined in RFC 3852 [ 4] and specifies the message digest of the eContent OCTET STRING within the encapContentInfo being signed.
• ESS signing-certificate or ESS signing-certificate-v2: The ESS signing-certificate attribute is defined in Enhanced Security Services (ESS), RFC 2634 [ 5], and only allows for the use of SHA-1 as a digest algorithm. The ESS signing-certificate-v2 attribute is defined in "ESS Update: Adding CertID Algorithm Agility", RFC 5035 [ 15], and allows for the use of any digest algorithm. A CAdES-BES claiming compliance with the standard must include one of them.

Optional signed attributes may be added to the CAdES-BES, including optional signed attributes defined in CMS ( RFC 3852 [ 4]) and ESS ( RFC 2634 [ 5]).

A CAdES-BES form can also incorporate instances of unsigned attributes, as defined in CMS ( RFC 3852 [ 4]) and ESS ( RFC 2634 [ 5]), specifically:

• CounterSignature, as defined in CMS ( RFC 3852 [ 4]); it can be incorporated wherever embedded signatures (i.e., a signature on a previous signature) are needed.

The following illustration shows the CAdES-BES structure.

+------Elect.Signature (CAdES-BES)------+
|+----------------------------------- + |
||+---------+ +----------+            | |
|||Signer's | |  Signed  |  Digital   | |
|||Document | |Attributes| Signature  | |
|||         | |          |            | |
||+---------+ +----------+            | |
|+------------------------------------+ |
+---------------------------------------+

NOTE: CAdES-BES is the minimum format for an electronic signature to be generated by the signer. On its own, it does not provide enough information to be verified in the longer term.

CAdES-BES satisfies the legal requirements for electronic signatures, as defined in the European Directive on Electronic Signatures. It provides basic authentication and integrity protection. The semantics of the signed data of a CAdES-BES or its context, may implicitly indicate a signature policy to the verifier.

CAdES-EPES

A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) extends the definition of an electronic signature to conform to the identified signature policy.

CAdES-EPES incorporates a signed attribute (sigPolicyID) indicating the signature policy that shall be used to validate the electronic signature. This signed attribute is protected by the signature. The signature may also have other signed attributes required to conform to the mandated signature policy.

Further information on signature policies is provided in TR 102 038.

The following illustration shows the CAdES-EPES structure.

+------------- Elect.Signature (CAdES-EPES) ---------------+
|                                                          |
|+-------------------------------------------------------+ |
|| +-----------+                                         | |
|| |           |   +---------------------------+         | |
|| |           |   |   +----------+            |         | |
|| | Signer's  |   |   |Signature | Signed     | Digital | |
|| | Document  |   |   |Policy ID | Attributes |Signature| |
|| |           |   |   +----------+            |         | |
|| |           |   +---------------------------+         | |
|| +-----------+                                         | |
|+-------------------------------------------------------+ |
|                                                          |
+----------------------------------------------------------+

Electronic Signature Formats with Validation Data

Validation of an electronic signature requires additional data needed to validate the signature. This additional data is called validation data, and includes:

• Public Key Certificates (PKCs)
• Revocation status information for each PKC
• Trusted time-stamps applied to the digital signature; otherwise a time-mark shall be available in an audit log.
• When appropriate, the details of a signature policy to be used to verify the electronic signature

The validation data may be collected by the signer and/or the verifier. When the signature-policy-identifier signed attribute is present, it shall meet the requirements of the signature policy.

Validation data includes Certification Authority (CA) certificates as well as revocation status information in the form of Certificate Revocation Lists (CRLs) or certificate status information (OCSP) provided by an online service.

Validation data also includes evidence that the signature was created before a particular time; this may be either a time-stamp token or time-mark. The CAdES standard defines unsigned attributes able to contain validation data that can be added to CAdES-BES and CAdES-EPES, leading to electronic signature formats that include validation data.

The sections below summarize these formats and their most relevant characteristics.

Electronic Signature with Time (CAdES-T)

CAdES-T must include the trusted time associated with the signature. The trusted time may be provided by the following:

• A time-stamp attribute as an unsigned attribute added to the ES
• A time-mark of the ES provided by a Trusted Service Provider

Trusted time provides the initial steps towards providing long-term validity.

A time-stamp token is added to the CAdES-BES or CAdES-EPES as an unsigned attribute, time-stamp tokens that may themselves include unsigned attributes required to validate the time-stamp token, such as the complete-certificate-references and complete-revocation-references attributes.

Electronic Signature with Complete Validation Data References (CAdES-C)

CAdES-C adds to the CAdES-T the complete-certificate-references and complete-revocation-references attributes. The complete-certificate-references attribute contains references to all the certificates present in the certification path used for verifying the signature. The complete-revocation-references attribute contains references to the CRLs and/or OCSPs responses used for verifying the signature. Storing the references allows the values of the certification path and the CRLs or OCSPs responses to be stored elsewhere, reducing the size of a stored electronic signature.

The complete certificate and revocation references are added to the CAdES-T as an unsigned attribute. As a minimum, the signer will provide the CAdES-BES or, when indicating that the signature conforms to an explicit signing policy, the CAdES-EPES.

To reduce the risk of repudiation of the signature's creation, the trusted time indication needs to be as close as possible to the time the signature was created. The signer or a Trusted Service Provider (TSP) could provide the CAdES-T; if not, the verifier should create the CAdES-T on the first receipt of an electronic signature because the CAdES-T provides independent evidence of the existence of the signature prior to the trusted time indication.

A CAdES-T trusted time indication must be created before a certificate has been revoked or expired. The signer and TSP could provide the CAdES-C to minimize this risk, and when the signer does not provide the CAdES-C, the verifier should create the CAdES-C when the required component of revocation and validation data become available; this may require a grace period.

The grace period permits certificate revocation information to propagate through the revocation processes. This period could extend from the time an authorized entity requests certificate revocation to when the information is available for the relying party to use. In order to make sure that the certificate was not revoked at the time the signature was time-marked or time-stamped, verifiers should wait until the end of the grace period. A signature policy may define specific values for grace periods.

NOTE: CWA14171 specifies a signature validation process using CAdES-T, CAdES-C, and a grace period.

EXtended Long Electronic Signature (CAdES-X Long)

CAdES-X Long adds the certificate-values and revocation-values attributes to the CAdES-C format. The first one contains the whole certificate path required for verifying the signature; the second one contains the CRLs and/or OCSP responses required for the validation of the signature. This provides a known repository of certificate and revocation information required to validate a CAdES-C and prevents such information from getting lost. In RFC 5126 Section 6.3.3 and Section 6.3.4 you can find the specification details.

EXtended Electronic Signature with Time Type 1 (CAdES-X Type 1)
CAdES-X Type 1 adds to the CAdES-C format the CAdES-C-time-stamp attribute, whose content is a time-stamp token on the CAdES-C itself. This provides integrity and trusted time protection over all the elements and references. It may protect the certificates, CRLs, and OCSP responses in case of a later compromise of a CA key, CRL key, or OCSP issuer key. In RFC 5126 Section 6.3.5 you may find the specification details.

EXtended Electronic Signature with Time Type 2 (CAdES-X Type 2)
CAdES-X Type 2 adds to the CAdES-C format the CAdES-C-time-stamped-certs-CTRs-references attribute, whose content is a time-stamp token on the certification path and revocation information references. This provides integrity and trusted time protection over all the references. This may protect the certificates, CRLs, and OCSP responses in case of a later compromise of a CA key, CRL key, or OCSP issuer key.

Both CAdES-X Type 1 and CAdES-X Type 2 encounter the same threats, and the usage of one or the other depends on the environment. In RFC 5126 Section 6.3.5 you can find the specification details.

EXtended Long Electronic Signature with Time (CAdES-X Long Type 1 or 2)
CAdES-X Long Type 1 or 2 is a combination of CAdES-X Long and one of the two former types (CAdES-X Type 1 and CAdES-X Type 2). In RFC 5126 Appendix B.1.4 you can find details on the production of the time-stamping process.

Archival Electronic Signature (CAdES-A)

CAdES-A builds on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more archive-time-stamp attributes. This form is used for archival of long-term signatures. Successive time-stamps protect the whole material against vulnerable hashing algorithms or the breaking of the cryptographic material or algorithms. In RFC 5126 Section 6.4 you can find the specification details.

Summary

Though the previous standard on electronic signature, CMS, defines the way to digitally sign documents of a generic type, it lacks most of the features required to validate a signature after a long period after it was applied. Moreover, in general it does not provide the ability to get sufficient information about the signer and the signature policy used. The new standard, CAdES, adds new properties and features and defines requirements for clarity and confidence.