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
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
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
- 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
C.4.4. Time-Stamping for Long Life of Signature before CA Key
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
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
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
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
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
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
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
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
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
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
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
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
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 .
The time-stamping service can be accessed using the Time-Stamping
Protocol defined in RFC 3161 .
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
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
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 ). 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:
Content-Type: text/plain; charset=ISO-8859-1
An example MIME header for a binary file containing a pdf document
F.1.2. Content Encoding
MIME supports a range of mechanisms for encoding both text and binary
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
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
An example of a multipart content is:
Content-Type: multipart/mixed; boundary="----
Content-Type: text/plain; charset=ISO-8859-1
Per your request, I've attached our proposal for the Java Card Version
2.0 API and the Java Card FAQ.
Content-Type: application/pdf; name="JCFV201.pdf"
Content-Disposition: attachment; filename="JCFV201.pdf"
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.
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
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.
- 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
| || || || |
| S/MIME || CAdES || MIME || pdf file |
| || || || |
|application/ || eContent ||application/ ||Received |
|pkcs7-mime || ||pdf || 100 tins |
| || || || |
|smime-type= || /| || /| || Mr.Jones |
|signed-data || / -----+ / ------+ |
| || \ -----+ \ ------+ |
| || \| || \| |+------------+
| || |+-------------+
Figure F.1: Signing Using application/pkcs7-mimeF.2.1. Using application/pkcs7-mime
This approach is similar to handling signed data as any other binary
An example of signed data encoded using this approach is:
Content-Type: application/pkcs7-mime; smime-type=signed-data;
Content-Disposition: attachment; filename=smime.p7m
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:
This is a clear-signed message.
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
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/ || |
| || |
| /| || |
| / -------+ |
| \ -------+ |
| \| ||----------+
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
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
- it is an "advanced electronic signature" with the following
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
a) considered to be an "electronic signature" under the terms of
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
- 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
- electronic signatures for business transactions with limited
G.4.3. Electronic Signature Classes and the ETSI Electronic Signature
The electronic signature format defined in the present document is
applicable to the EESSI area "electronic signature and encoding
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
With the addition of attributes by the verifier (see Section 6 and
conformance Section 10.2) the qualified electronic signature supports