W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2008

ACTION-91: First draft of long term signatures.

From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
Date: Tue, 04 Nov 2008 14:29:33 +0100
Message-ID: <49104E3D.2080405@ac.upc.edu>
To: XMLSec WG Public List <public-xmlsec@w3.org>

Dear all,

Below follows an initial draft for text dealing with requirements on 
long term signatures.

I guess that in the forecoming meetings we may talk on how this may be 
improved and whether it is suitable to generate a specific type of 
document or not.

This should close action 91 on me.

Regards

Juan Carlos.



INITIAL DRAFT TEXT:

REQUIREMENTS FOR LONG-TERM SIGNATURES.

First draft: 2008-11-04

Juan Carlos Cruellas.

1. Introduction

Long term signatures are signatures whose contents allow to an entity to 
ascertain, long time after the signature was firstly verified, that the 
signature had.

The “long term” expression typically implies periods of several years 
(in certain European countries, invoices must be kept for up to five 
years, and this requirement is extended to electronic invoices 
electronically signed). These signatures must counter time passing 
effects. One of them, for instance is the fact that after their first 
verification and after such a long period of time, certificates within 
the certificate path will have expired or even some of them may have 
been revoked.

The ascertaining entity may be in some cases, different from the 
relaying party that firstly verified the signature (an arbitrator in 
charge of solving disputes between signer and verifier, for instance).

There are specific requirements associated with long term signatures, 
namely:

1. There must be deployed secure mechanisms for proving that the 
signature was generated before a certain point in time.

2. There must be deployed secure mechanisms for proving that the 
signature was firstly verified by the corresponding relaying party 
before a certain point in time.

3. There must be deployed mechanisms allowing the ascertaining entity to 
gain access to all the validation material that the relaying party had 
used for verifying the signature.

4. There must be deployed mechanisms allowing to countering weaknesses 
discovered on cryptographic algorithms or keys used in the generation of 
the signature, or expiration of verification material.

Generally speaking each of the generic requirements in the list above 
may imply the incorporation of additional information within the XML Sig 
structure once the ds:SignatureValue has been generated.

2. Proving that the signature was generated before a certain point of time.

A long term signature must securely prove that it was actually generated 
before a certain point in time.

At present, two mechanisms have been identified for achieving such a 
requirement:

a. The inclusion in the signature of a trusted time-stamp, generated by 
a Trusted Time-Stamping Authority, immediately after the signature has 
been generated (signature time-stamp).

b. To deploy a process that generates artifacts that actually may prove 
in the future that the signature was created at that point of time 
(secure records of actions, for instance).

3. Proving that the signature was firstly verified before a certain 
point of time.

For resolving potential disputes between signer and verifier, a long 
term signature must also be able to securely prove that the relaying 
party firstly verified it before a certain point in time.

For proving this, it must be securely proved that the verifier had 
gained access to all the verification material before that point of 
time. The requirements on the signature are, in consequence as follows:

1. Mechanisms must be provided for collecting within the XML sig, all 
the validation material used by the relaying party in the first 
verification. This includes:

a. Certificates within certificate path of the signing certificate.

b. Material reporting the status of each certificate within the cert 
path of the signing certificate (CRLs or OCSP responses)

c. Certificates within the certificate path of the certificate used by 
the Trusted Time-Stamping Authority that generated the signature time-stamp.

d. Material reporting the status of each certificate within the cert 
path aforementioned in c.

2. A trusted time-stamp generated by a Trusted Time-Stamping Authority, 
covering both, the signature generated and the verification material 
listed before. This time-stamp will actually prove that the relaying 
party had gained access to the validation material and in consequence, 
had the capability for verifying the signature, before the time 
indicated in the time-stamp.

4. Countering algorithm / keys weaknesses or validation material expiration

Once the validation material has been collected and time-stamped, the 
action of time may bring two different types of consequences:

1. Some of the algorithms (or keys) used for generating the signature or 
any of the aforementioned time-stamps may be broken.

2. Some of the certificates in the certification path of the time-stamp 
covering this validation material may expire.

A long-term signature must counter any of the two consequences in the list.

A countering mechanism consists in regularly generating trusted 
time-stamps covering the signature, all the previously issued 
time-stamps and all the validation material (archive time-stamps).


If some algorithm / key has been broken, this time-stamp may use 
different algorithm / keying material.

If some of the certificates within the cert path of the latest 
time-stamp has expired, the new one will have a new certificate within 
its corresponding cert path.

A form of long term signatures may be obtained by allowing to XML 
Signatures the incorporation of such kind of archive time-stamps.

5. XAdES and long term XML Signatures

XAdES (ETSI TS 101 903) specifies XML Schema types suitable for 
containing all the different types of data mentioned in this document, 
namely, time-stamp tokens, validation data, etc.

XAdES also standardizes ways for adding all this material to regular XML 
Signatures, increasing interoperability among applications.
Received on Tuesday, 4 November 2008 13:30:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:55 GMT