RFC 5126
CMS Advanced Electronic Signatures (CAdES)
C.4. Components of Validation Data
C.4.1. Revocation Status Information
A verifier will have to ascertain that the certificate of the signer was valid at the time of the signature. This can be done by either: - using Certificate Revocation Lists (CRLs); - using responses from an online certificate status server (for example, obtained through the OCSP protocol). NOTE 1: The time of the signature may not be known, so time-stamping or time-marking may be used to provide the time indication of when it was known that the signature existed. NOTE 2: When validating an electronic signature and checking revocation status information, if a "grace period" is required, it needs to be suitably long enough to allow the involved authority to process a "last-minute" revocation request and for the request to propagate through the revocation system. This grace period is to be added to the time included with the time-stamp token or the time-mark, and thus the revocation status information should be captured after the end of the grace period.
C.4.1.1. CRL Information
When using CRLs to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, the appropriate certificate revocation information from the signer's CA. This should be done as soon as possible to minimize the time delay between the generation and verification of the signature. However, a "grace period" is required to allow CAs time to process revocation requests. For example, a revocation request may arrive at a CA just before issuing the next CRL, and there may not enough time to include the revised revocation status information. This involves checking that the signer certificate serial number is not included in the CRL. Either the signer, the initial verifier, or a subsequent verifier may obtain this CRL. If obtained by the signer, then it shall be conveyed to the verifier. It may be convenient to archive the CRL for ease of subsequent verification or arbitration. Alternatively, provided the CRL is archived elsewhere, which is accessible for the purpose of arbitration, then the serial number of the CRL used may be archived together with the verified electronic signature as a CAdES-C form. Even if the certificate serial number appears in the CRL with the status "suspended" (i.e., on hold), the signature is not to be deemed as valid since a suspended certificate is not supposed to be used even by its rightful owner.C.4.1.2. OCSP Information
When using OCSP to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, an OCSP response that contains the status "valid". This should be done as soon as possible after the generation of the signature, still providing a "grace period" suitable enough to allow the involved authority to process a "last-minute" revocation request. The signer, the verifier, or any other third party may fetch this OCSP response. Since OCSP responses are transient and thus are not archived by any TSP, including CA, it is the responsibility of every verifier to make sure that it is stored in a safe place. The simplest way is to store them associated with the electronic signature. An alternative would be to store them so that they can then be easily retrieved and incorporate references to them in the electronic signature itself as a CAdES-C form.
In the same way as for the case of the CRL, it may happen that the certificate is declared as invalid but with the secondary status "suspended". In such a case, the same comment as for the CRL applies.C.4.2. Certification Path
A verifier may have to ascertain that the certification path was valid, at the time of the signature, up to a trust point, according to the: - naming constraints; - certificate policy constraints; - signature policy, when applicable. Since the time of the signature cannot be known with certainty, an upper limit of it should be used as indicated by either the time-stamp or time-mark. In this case, it will be necessary to capture all the certificates from the certification path, starting with those from the signer and ending up with those of the self-signed certificate from one trusted root; when applicable, this may be specified as part of the Signature Policy. In addition, it will be necessary to capture the Certificate Authority Revocation Lists (CARLs) to prove that none of the CAs from the chain were revoked at the time of the signature. Again, all this material may be incorporated in the electronic signature (ES X forms). An alternative would be to store this information so that it can be easily retrieved and incorporate references to it in the electronic signature itself as a CAdES-C form.C.4.3. Time-Stamping for Long Life of Signatures
An important property for long-standing signatures is that a signature, having been found once to be valid, shall continue to be so months or years later. A signer, verifier, or both may be required to provide, on request, proof that a digital signature was created or verified during the validity period of all the certificates that make up the certificate path. In this case, the signer, verifier, or both will also be required to provide proof that the signer's certificate and all the CA certificates used to form a valid certification path were not revoked when the signature was created or verified.
It would be quite unacceptable to consider a signature as invalid even if the keys or certificates were later compromised. Thus, there is a need to be able to demonstrate that the signature keys were valid at the time that the signature was created to provide long-term evidence of the validity of a signature. It could be the case that a certificate was valid at the time of the signature but revoked some time later. In this event, evidence shall be provided that the document was signed before the signing key was revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide such evidence. A time-stamp is obtained by sending the hash value of the given data to the TSA. The returned "time-stamp" is a signed document that contains the hash value, the identity of the TSA, and the time of stamping. This proves that the given data existed before the time of stamping. Time-stamping a digital signature (by sending a hash of the signature to the TSA) before the revocation of the signer's private key provides evidence that the signature had been created before the certificate was revoked. If a recipient wants to hold a valid electronic signature, he will have to ensure that he has obtained a valid time-stamp for it before that key (and any key involved in the validation) is revoked. The sooner the time-stamp is obtained after the signing time, the better. Any time-stamp or time-mark that is taken after the expiration date of any certificate in the certification path has no value in proving the validity of a signature. It is important to note that signatures may be generated "off-line" and time-stamped at a later time by anyone, for example, by the signer or any recipient interested in the value of the signature. The time-stamp can thus be provided by the signer, together with the signed document, or obtained by the recipient following receipt of the signed document. The time-stamp is NOT a component of the Basic Electronic Signature, but it is the essential component of the ES with Time. It is required, in the present document, that if a signer's digital signature value is to be time-stamped, the time-stamp token is issued by a trusted source, known as a Time-Stamping Authority. The present document requires that the signer's digital signature value be time-stamped by a trusted source before the electronic signature can become an ES with Complete validation data. Acceptable TSAs may be specified in a Signature Validation Policy. This technique is referred to as CAdES-C in the present document.
Should both the signer and verifier be required to time-stamp the signature value to meet the requirements of the signature policy, the signature policy may specify a permitted time delay between the two time-stamps.C.4.4. Time-Stamping for Long Life of Signature before CA Key Compromises
Time-stamped, extended electronic signatures are needed when there is a requirement to safeguard against the possibility of a CA key in the certificate chain ever being compromised. A verifier may be required to provide, on request, proof that the certification path and the revocation information used at the time of the signature were valid, even in the case where one of the issuing keys or OCSP responder keys is later compromised. The present document defines two ways of using time-stamps to protect against this compromise: - time-stamp the ES with Complete validation data, when an OCSP response is used to get the status of the certificate from the signer (CAdES-X Type 1). This format is suitable to be used with an OCSP response, and it offers the additional advantage of providing an integrity protection over the whole data; - time-stamp only the certification path and revocation information references when a CRL is used to get the status of the certificate from the signer (CAdES-X Type2). This format is suitable to be used with CRLs, since the time-stamped information may be used for more than one signature (when signers have their certificates issued by the same CA and when signatures can be checked using the same CRLs). NOTE: The signer, verifier, or both may obtain the time-stamp.C.4.4.1. Time-Stamping the ES with Complete Validation Data (CAdES-X Type 1)
When an OCSP response is used, it is necessary to time-stamp in particular that response in the case the key from the responder would be compromised. Since the information contained in the OCSP response is user specific and time specific, an individual time-stamp is needed for every signature received. Instead of placing the time-stamp only over the certification path references and revocation information references, which include the OCSP response, the time-stamp is placed on the CAdES-C. Since the certification path and revocation information references are included in the ES with Complete validation data, they are also protected. For the same
cryptographic price, this provides an integrity mechanism over the ES
with Complete validation data. Any modification can be immediately
detected. It should be noticed that other means of
protecting/detecting the integrity of the ES with Complete validation
data exist and could be used. Although the technique requires a
time-stamp for every signature, it is well suited for individual
users wishing to have an integrity-protected copy of all the
validated signatures they have received.
By time-stamping the complete electronic signature, including the
digital signature as well as the references to the certificates and
revocation status information used to support validation of that
signature, the time-stamp ensures that there is no ambiguity in the
means of validating that signature.
This technique is referred to as CAdES-X Type 1 in the present
document.
NOTE: Trust is achieved in the references by including a hash of
the data being referenced.
If it is desired for any reason to keep a copy of the additional data
being referenced, the additional data may be attached to the
electronic signature, in which case the electronic signature becomes
a CAdES-X Long Type 1, as defined by the present document.
A CAdES-X Long Type 1 is simply the concatenation of a CAdES-X Type
1, with a copy of the additional data being referenced.
C.4.4.2. Time-Stamping Certificates and Revocation Information
References (CAdES-X Type 2)
Time-stamping each ES with Complete validation data, as defined
above, may not be efficient, particularly when the same set of CA
certificates and CRL information is used to validate many signatures.
Time-stamping CA certificates will stop any attacker from issuing
bogus CA certificates that could be claimed to exist before the CA
key was compromised. Any bogus time-stamped CA certificates will
show that the certificate was created after the legitimate CA key was
compromised. In the same way, time-stamping CA CRLs will stop any
attacker from issuing bogus CA CRLs that could be claimed to exist
before the CA key was compromised.
Time-stamping of commonly used certificates and CRLs can be done
centrally, e.g., inside a company or by a service provider. This
method reduces the amount of data the verifier has to time-stamp; for
example, it could be reduced to just one time-stamp per day (i.e., in
the case where all the signers use the same CA, and the CRL applies
for the whole day). The information that needs to be time-stamped is
not the actual certificates and CRLs, but the unambiguous references
to those certificates and CRLs.
This technique is referred to as CAdES-X Type 2 in the present
document and requires the following:
- all the CA certificates references and revocation information
references (i.e., CRLs) used in validating the CAdES-C are
covered by one or more time-stamps.
Thus, a CAdES-C with a time-stamp signature value at time T1 can be
proved valid if all the CA and CRL references are time-stamped at
time T1+.
C.4.5. Time-Stamping for Archive of Signature
Advances in computing increase the probability of being able to break
algorithms and compromise keys. There is therefore a requirement to
be able to protect electronic signatures against this possibility.
Over a period of time, weaknesses may occur in the cryptographic
algorithms used to create an electronic signature (e.g., due to the
time available for cryptoanalysis, or improvements in
cryptoanalytical techniques). Before such weaknesses become likely,
a verifier should take extra measures to maintain the validity of the
electronic signature. Several techniques could be used to achieve
this goal, depending on the nature of the weakened cryptography. In
order to simplify matters, a single technique called Archive
validation data, covering all the cases, is being used in the present
document.
Archive validation data consists of the validation data and the
complete certificate and revocation data, time-stamped together with
the electronic signature. The Archive validation data is necessary
if the hash function and the crypto algorithms that were used to
create the signature are no longer secure. Also, if it cannot be
assumed that the hash function used by the Time-Stamping Authority is
secure, then nested time-stamps of the Archived Electronic Signature
are required.
The potential for a Trusted Service Provider (TSP) key compromise
should be significantly lower than user keys because TSP(s) are
expected to use stronger cryptography and better key protection. It
can be expected that new algorithms (or old ones with greater key
lengths) will be used. In such a case, a sequence of time-stamps
will protect against forgery. Each time-stamp needs to be affixed
before either the compromise of the signing key or the cracking of the algorithms used by the TSA. TSAs (Time-Stamping Authorities) should have long keys (e.g., which at the time of drafting the present document was at least 2048 bits for the signing RSA algorithm) and/or a "good" or different algorithm. Nested time-stamps will also protect the verifier against key compromise or cracking the algorithm on the old electronic signatures. The process will need to be performed and iterated before the cryptographic algorithms used for generating the previous time-stamp are no longer secure. Archive validation data may thus bear multiple embedded time-stamps. This technique is referred to as CAdES-A in the present document.C.4.6. Reference to Additional Data
Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data, verifiers still need to keep track of all the components that were used to validate the signature, in order to be able to retrieve them again later on. These components may be archived by an external source, like a Trusted Service Provider; in which case, referenced information that is provided as part of the ES with Complete validation data (CAdES-C) is adequate. The actual certificates and CRL information reference in the CAdES-C can be gathered when needed for arbitration. If references to additional data are not adequate, then the actual values of all the certificates and revocation information required may be part of the electronic signature. This technique is referred to as CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document.C.4.7. Time-Stamping for Mutual Recognition
In some business scenarios, both the signer and the verifier need to time-stamp their own copy of the signature value. Ideally, the two time-stamps should be as close as possible to each other. EXAMPLE: A contract is signed by two parties, A and B, representing their respective organizations; to time-stamp the signer and verifier data, two approaches are possible: - under the terms of the contract, a predefined common "trusted" TSA may be used;
- if both organizations run their own time-stamping services, A
and B can have the transaction time-stamped by these two
time-stamping services.
In the latter case, the electronic signature will only be considered
valid if both time-stamps were obtained in due time (i.e., there
should not be a long delay between obtaining the two time-stamps).
Thus, neither A nor B can repudiate the signing time indicated by
their own time-stamping service. Therefore, A and B do not need to
agree on a common "trusted" TSA to get a valid transaction.
It is important to note that signatures may be generated "off-line"
and time-stamped at a later time by anyone, e.g., by the signer or
any recipient interested in validating the signature. The time-stamp
over the signature from the signer can thus be provided by the
signer, together with the signed document, and/or be obtained by the
verifier following receipt of the signed document.
The business scenarios may thus dictate that one or more of the
long-term signature time-stamping methods described above be used.
This may be part of a mutually agreed Signature Validation Policy
that is part of an agreed signature policy under which digital
signatures may be used to support the business relationship between
the two parties.
C.4.8. TSA Key Compromise
TSA servers should be built in such a way that once the private
signature key is installed, there is minimal likelihood of compromise
over as long as a possible period. Thus, the validity period for the
TSA's keys should be as long as possible.
Both the CAdES-T and the CAdES-C contain at least one time-stamp over
the signer's signature. In order to protect against the compromise
of the private signature key used to produce that time-stamp, the
Archive validation data can be used when a different Time-Stamping
Authority key is involved to produce the additional time-stamp. If
it is believed that the TSA key used in providing an earlier
time-stamp may ever be compromised (e.g., outside its validity
period), then the CAdES-A should be used. For extremely long
periods, this may be applied repeatedly using new TSA keys.
This technique is referred to as a nested CAdES-A in the present
document.
C.5. Multiple Signatures
Some electronic signatures may only be valid if they bear more than one signature. This is generally the case when a contract is signed between two parties. The ordering of the signatures may or may not be important, i.e., one may or may not need to be applied before the other. Several forms of multiple and counter signatures need to be supported, which fall into two basic categories: - independent signatures; - embedded signatures. Independent signatures are parallel signatures where the ordering of the signatures is not important. The capability to have more than one independent signature over the same data shall be provided. Embedded signatures are applied one after the other and are used where the order in which the signatures are applied is important. The capability to sign over signed data shall be provided. These forms are described in Section 5.13. All other multiple signature schemes, e.g., a signed document with a countersignature, double countersignatures, or multiple signatures can be reduced to one or more occurrences of the above two cases.Annex D (Informative): Data Protocols to Interoperate with TSPs
D.1. Operational Protocols
The following protocols can be used by signers and verifiers to interoperate with Trusted Service Providers during the electronic signature creation and validation.D.1.1. Certificate Retrieval
User certificates, CA certificates, and cross-certificates can be retrieved from a repository using the Lightweight Directory Access Protocol as defined in RFC 3494 [RFC3494], with the schema defined in RFC 4523 [RFC4523].D.1.2. CRL Retrieval
Certificate revocation lists, including authority revocation lists and partial CRL variants, can be retrieved from a repository using the Lightweight Directory Access Protocol, as defined in RFC 3494 [RFC3494], with the schema defined in RFC 4523 [RFC4523].
D.1.3. Online Certificate Status
As an alternative to the use of certificate revocation lists, the status of a certificate can be checked using the Online Certificate Status Protocol (OCSP), as defined in RFC 2560 [3].D.1.4. Time-Stamping
The time-stamping service can be accessed using the Time-Stamping Protocol defined in RFC 3161 [7].D.2. Management Protocols
Signers and verifiers can use the following management protocols to manage the use of certificates.D.2.1. Request for Certificate Revocation
Request for a certificate to be revoked can be made using the revocation request and response messages defined in RFC 4210 [RFC4210].Annex E (Informative): Security Considerations
E.1. Protection of Private Key
The security of the electronic signature mechanism defined in the present document depends on the privacy of the signer's private key. Implementations should take steps to ensure that private keys cannot be compromised.E.2. Choice of Algorithms
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of mandatory-to-implement algorithms to change over time.
Annex F (Informative): Example Structured Contents and MIME
F.1. Use of MIME to Encode Data
The signed content may be structured using MIME (Multipurpose Internet Mail Extensions -- RFC 2045 [6]). Whilst the MIME structure was initially developed for Internet email, it has a number of features that make it useful to provide a common structure for encoding a range of electronic documents and other multi-media data (e.g., photographs, video). These features include: - providing a means of signalling the type of "object" being carried (e.g., text, image, ZIP file, application data); - providing a means of associating a file name with an object; - associating several independent objects (e.g., a document and image) to form a multi-part object; - handling data encoded in text or binary and, if necessary, re-encoding the binary as text. When encoding a single object, MIME consists of: - header information, followed by; - encoded content. This structure can be extended to support multi-part content.F.1.1. Header Information
A MIME header includes: MIME Version information: e.g., MIME-Version: 1.0 Content type information, which includes information describing the content sufficient for it to be presented to a user or application process, as required. This includes information on the "media type" (e.g., text, image, audio) or whether the data is for passing to a particular type of application. In the case of text, the content type includes information on the character set used, e.g., Content-Type: text/plain; charset="us-ascii". Content-encoding information, which defines how the content is encoded (see below about encoding supported by MIME).
Other information about the content, such as a description or an associated file name. An example MIME header for text object is: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable An example MIME header for a binary file containing a pdf document is: Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Description: JCFV201.pdf Content-Disposition: filename="JCFV201.pdf"F.1.2. Content Encoding
MIME supports a range of mechanisms for encoding both text and binary data. Text data can be carried transparently as lines of text data encoded in 7- or 8-bit ASCII characters. MIME also includes a "quoted-printable" encoding that converts characters other than the basic ASCII into an ASCII sequence. Binary can either be carried: - transparently as 8-bit octets; or - converted to a basic set of characters using a system called Base64. NOTE: As there are some mail relays that can only handle 7-bit ASCII, Base64 encoding is usually used on the Internet.F.1.3. Multi-Part Content
Several objects (e.g., text and a file attachment) can be associated together using a special "multi-part" content type. This is indicated by the content type "multipart" with an indication of the string to be used indicating a separation between each part. In addition to a header for the overall multipart content, each part includes its own header information indicating the inner content type and encoding.
An example of a multipart content is: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC4599.98004A80" Content-Transfer-Encoding: 7bit ------=_NextPart_000_01BC4599.98004A80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Per your request, I've attached our proposal for the Java Card Version 2.0 API and the Java Card FAQ. ------=_NextPart_000_01BC4599.98004A80 Content-Type: application/pdf; name="JCFV201.pdf" Content-Transfer-Encoding: base64 Content-Description: JCFV201.pdf Content-Disposition: attachment; filename="JCFV201.pdf" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// //////////AANhAAQAYg== ------=_NextPart_000_01BC4599.98004A80-- Multipart content can be nested. So a set of associated objects (e.g., HTML text and images) can be handled as a single attachment to another object (e.g., text). The Content-Type from each part of the S/MIME message indicates the type of content.F.2. S/MIME
The specific use of MIME to carry CMS (extended as defined in the present document) secured data is called S/MIME (see [RFC3851]). S/MIME carries electronic signatures as either: - an "application/pkcs7-mime" object with the CMS carried as a binary attachment (PKCS7 is the name of the early version of CMS). The signed data may be included in the SignedData, which itself may be included in a single S/MIME object. See [RFC3851], Section 3.4.2: "Signing Using application/pkcs7-mime with SignedData" and Figure F.1 hereafter.
or
- a "multipart/signed" object with the signed data and the
signature encoded as separate MIME objects.
The signed data is not included in the SignedData, and the CMS
structure only includes the signature. See [RFC3851], Section
3.4.3: "Signing Using the multipart/signed Format" and Figure
F.2 hereafter.
+-------------++----------++-------------++------------+
| || || || |
| S/MIME || CAdES || MIME || pdf file |
| || || || |
|Content-Type=||SignedData||Content-Type=||Dear MrSmith|
|application/ || eContent ||application/ ||Received |
|pkcs7-mime || ||pdf || 100 tins |
| || || || |
|smime-type= || /| || /| || Mr.Jones |
|signed-data || / -----+ / ------+ |
| || \ -----+ \ ------+ |
| || \| || \| |+------------+
| || |+-------------+
| |+----------+
+-------------+
Figure F.1: Signing Using application/pkcs7-mime
F.2.1. Using application/pkcs7-mime
This approach is similar to handling signed data as any other binary
file attachment.
An example of signed data encoded using this approach is:
Content-Type: application/pkcs7-mime; smime-type=signed-data;
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
F.2.2. Using application/pkcs7-signature
CMS also supports an alternative structure where the signature and data being protected are separate MIME objects carried within a single message. In this case, the signed data is not included in the SignedData, and the CMS structure only includes the signature. See [RFC3851], Section 3.4.3: "Signing Using the multipart/signed Format" and Figure F.2 hereafter. An example of signed data encoded using this approach is: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- With this second approach, the signed data passes through the CMS process and is carried as part of a multiple-parts signed MIME structure, as illustrated in Figure F.2. The CMS structure just holds the electronic signature.
+---------------++----------++-------------++------------+ | || || || | | MIME || CAdES || MIME || pdf file | | || || || | |Content-Type= ||SignedData||Content-Type=||Dear MrSmith| |multipart/ || ||application/ ||Received | |signed || ||pdf || 100 tins | | /| || || || | | / -------------------+ /| || Mr.Jones | | \ -------------------+ / -----+ | | \| || || \ -----+ | |Content-Type= || || \| |+------------+ |application/ || |+-------------+ |pdf || | | || | |Content-Type= || | |application/ || | |pkcs7-signature|| | | || | | /| || | | / -------+ | | \ -------+ | | \| ||----------+ | | +---------------+ Figure F.2: Signing Using application/pkcs7-signature This second approach (multipart/signed) has the advantage that the signed data can be decoded by any MIME-compatible system even if it does not recognize CMS-encoded electronic signatures.Annex G (Informative): Relationship to the European Directive and EESSI
G.1. Introduction
This annex provides an indication of the relationship between electronic signatures created under the present document and requirements under the European Parliament and Council Directive on a Community framework for electronic signatures. NOTE: Legal advice should be sought on the specific national legislation regarding use of electronic signatures. The present document is one of a set of standards that has been defined under the "European Electronic Signature Standardization Initiative" (EESSI) for electronic signature products and solutions compliant with the European Directive for Electronic Signatures.
G.2. Electronic Signatures and the Directive
This directive defines electronic signatures as: - "data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication". The directive states that an electronic signature should not be denied "legal effectiveness and admissibility as evidence in legal proceedings" solely on the grounds that it is in electronic form. The directive identifies an electronic signature as having equivalence to a hand-written signature if it meets specific criteria: - it is an "advanced electronic signature" with the following properties: a) it is uniquely linked to the signatory; b) it is capable of identifying the signatory; c) it is created using means that the signatory can maintain under his sole control; and d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable. - it is based on a certificate that meets detailed criteria given in Annex I of the directive and is issued by a "certification-service-provider" that meets requirements given in Annex II of the directive. Such a certificate is referred to as a "qualified certificate"; - it is created by a "device", for which detailed criteria are given in Annex III of the directive. Such a device is referred to a "secure-signature-creation device". This form of electronic signature is referred to as a "qualified electronic signature" in EESSI (see below).
G.3. ETSI Electronic Signature Formats and the Directive
An electronic signature created in accordance with the present document is: a) considered to be an "electronic signature" under the terms of the Directive; b) considered to be an "advanced electronic signature" under the terms of the Directive; c) considered to be a "Qualified Electronic Signature", provided the additional requirements in Annex I, II, and III of the Directive are met. The requirements in Annex I, II, and III of the Directive are outside the scope of the present document, and are subject to standardization elsewhere.G.4. EESSI Standards and Classes of Electronic Signature
G.4.1. Structure of EESSI Standardization
EESSI looks at standards in several areas. See the ETSI and CEN web sites for the latest list of standards and their versions: - use of X.509 public key certificates as qualified certificates; - security Management and Certificate Policy for CSPs Issuing Qualified Certificates; - security requirements for trustworthy systems used by CSPs Issuing Qualified Certificates; - security requirements for Secure Signature Creation Devices; - security requirements for Signature Creation Systems; - procedures for Electronic Signature Verification; - electronic signature syntax and encoding formats; - protocol to interoperate with a Time-Stamping Authority; - Policy requirements for Time-Stamping Authorities; and - XML electronic signature formats.
Each of these standards addresses a range of requirements, including the requirements of Qualified Electronic Signatures, as specified in Article 5.1 of the Directive. However, some of them also address general requirements of electronic signatures for business and electronic commerce, which all fall into the category of Article 5.2 of the Directive. Such variation in the requirements may be identified either as different levels or different options.G.4.2. Classes of Electronic Signatures
Since some of these standards address a range of requirements, it may be useful to identify a set of standards to address a specific business need. Such a set of standards and their uses define a class of electronic signature. The first class already identified is the qualified electronic signature, fulfilling the requirements of Article 5.1 of the Directive. A limited number of "classes of electronic signatures" and corresponding profiles could be defined in close cooperation with actors on the market (business, users, suppliers). The need for such standards is envisaged, in addition to those for qualified electronic signatures, in areas such as: - different classes of electronic signatures with long-term validity; - electronic signatures for business transactions with limited value.G.4.3. Electronic Signature Classes and the ETSI Electronic Signature Format
The electronic signature format defined in the present document is applicable to the EESSI area "electronic signature and encoding formats". An electronic signature produced by a signer (see Section 5 and conformance Section 10.1) is applicable to the proposed class of electronic signature: "qualified electronic signatures fulfilling article 5.1". With the addition of attributes by the verifier (see Section 6 and conformance Section 10.2) the qualified electronic signature supports long-term validity.
(next page on part 7)
