- From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
- Date: Tue, 04 Nov 2008 14:29:33 +0100
- 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 UTC