Subject: Re: XAdES questions

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Nov 2004 16:15:59 +0100 (MET)

Since Denis mentioned ltans, I think it is worth to forward it to the ltans list. 

----- Begin Included Message -----

Date:         Wed, 3 Nov 2004 15:04:33 +0100
To: "PLUGTESTS-SECURITY: Discussion list on security Interoperability matters" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Subject: Re: XAdES questions
To: [email-masked]

> Szabo,

> You are absolutely right about the problem and this is why I think 
 > that XAdES is inconsistent at this time. The problem of archiving
 > can not be solved using implementation such as XAdES, which delivers
 > only partial solution to the problem. In theory you could rely
 > on CA policy, which should issue CRLs immediately after a certificate
 > is revoked and even in this scenario some timeframe remains open for
 > manipulation. However, please keep in mind that XAdES does not limit
 > itself to some particular reference data but rather leaves this part
 > of the signature open (at least to my understanding), which means
 > that you can use other reference information such as DVCS or OCSP
 > response and carry over the liability to third party or use the method
 > as you have suggested bellow. I state again that electronic records
 > and digital signatures preservation is suppose to stay in hands of
 > trusted archival services, where you can play around arbitrary
 > implementation, using several timestamps to archive a full archival
 > process.

TAS is certainly the solution. I have sent comments on that topic to the 
LTANS WG from the IETF introducing the concept of a "cryptographic 
maintenance policy" that comes separate from the "signature policy" (in fact 
which must take the relay before the signature policy expires, but may also 
be used before the signature policy expires).

Denis

> Best regards
> 
> aleksej
> 
> 
>>-----Original Message-----
>>From: PLUGTESTS-SECURITY: Discussion list on security 
>>Interoperability matters 
>>[mailto:[email-masked]] On Behalf Of Szabó Áron
>>Sent: Thursday, October 28, 2004 11:32 AM
>>To: [email-masked]
>>Subject: Re: XAdES questions
>>
>>Dear Juan Carlos,
>>
>>thanks for your comments, they were very useful. I would 
>>react to some of them.
>>
>>In connection with "grace period"...
>>
>>At "time 0" a CRL has been issued, the next issue is at "time 4".
>>At "time 1" I request timestamp by generating and sending the 
>>hash (messageImprint).
>>At "time 2" I create the electronic signature with the 
>>requested timestamp (SigningTime).
>>At "time 3" I revoke my certificate.
>>At "time 4" I get the newly issued CRL which contains the 
>>serialNumber of my revoked certificate.
>>
>>Between "time 0" and "time 4" (CRL issues) can elapse several 
>>hours. If I want to verify the electronic signature between 
>>"time 2" and "time 4" I cannot decide whether the signature 
>>is good or wrong. You're right, I have to wait until the next 
>>issue of the CRL. But this means, that if I want to create a 
>>XAdES-A archive signature that cannot be good, because that 
>>will always contain the CRL that just have been issued at 
>>"time 0" (but the needed one would be the other one - issued 
>>at "time 4" or later). I could imagine just one solution to 
>>create correct XAdES-A, but I'm afraid this could hardly work...
>>
>>step 1: timestamp request for SigningTime step 2: generating 
>>SignatureValue and the whole structure step 3: waiting until 
>>next CRL is issued (i.e. 4 hours) step 4: fetching the newly 
>>issued CRL (after SigningTime) step 5: generating 
>>ArchiveTimeStamp upon all needed data
>>
>>In connection with optional attributes of XAdES...
>>
>>Why are "Id" and "URI" attributes of elements optional? How 
>>could be referenced i.e. the optional "Id" of the enveloped 
>>data by the optional "URI" of Reference tag? If I understand 
>>well, there is an inconsistency in this question. The 
>>IncludeType of TimeStampType says (i.e. at
>>ArchiveTimeStamp) that "URI" is "required" to several 
>>included (Include) elements identified by "Id" attribute, but 
>>those "Id" attributes are "optional". It is needed to change 
>>the "optional" flag to "required" at those included elements, 
>>isn't it? Or is there any other way to make references to 
>>those obejcts, tags?
>>
>>Best regards,
>>Aron
>>
>>----------------------------------------------------
>>Aron Szabo, M. Sc.
>>Research Associate,
>>Center of Information Technology
>>Budapest University of Technology and Economics
>>
>>Postal code: 1117
>>Budapest, Hungary
>>Address: Magyar tudosok krt. 2.
>>E-mail: [email-masked]
>>
> 
> 

----- End Included Message -----

---

From: [email-masked]
Date: Wed, 3 Nov 2004 16:58:24 +0100

As Denis mentioned, there is an activity going on by IETF trying to define
requirments for long term archival services. You may want to have a look at the
current progress and outcomes. Information available at: ltans.edelweb.fr.