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

Re: Best practices: time-stamps comments

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Mon, 2 Jun 2008 18:07:34 -0400
Message-Id: <C1CAB2A7-E402-4AAF-B169-69FBC3A23F6C@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec XMLSec <public-xmlsec-maintwg@w3.org>
To: ext Juan Carlos Cruellas <cruellas@ac.upc.edu>

Is it correct to say that some timestamps might not always be  
intended for long term signatures, and thus not need to meet the  
XAdES approach in those short term cases?

Why cannot a timestamp and nonce be generated, and  then the  
signature including references to those items? You suggest the  
signature must be generated first?

regards, Frederick

Frederick Hirsch
Nokia



On May 20, 2008, at 8:04 AM, ext Juan Carlos Cruellas wrote:

>
> Dear all,
>
> Some comments on time-stamps best practices.
>
> 1. I suggest to substitute the text: "DSS Profiles contain  
> timestamps" by some text that provide some hints on XAdES way of  
> using time-stamping for long term signatures and how DSS profiles  
> deal with the request and verification of such issues.
>
> Proposed text:
>
> "ETSI has produced TS 101 903: "XML Advanced Electronic Signatures  
> (XAdES)", which among other ones, deals with the issue of long-term  
> electronic signatures. It has defined a standard way for  
> incorporating time-stamps to XML signatures. In addition to the  
> signature time-stamp, which should be generated soon after the  
> generation of the signature, other time-stamps may be added to the  
> signature structure protecting the validation material used by the  
> verifier. Recurrent time-stamping (with stronger algorithms and  
> keys) on all these items, i.e., the signature, the validation  
> material and previous time-stamps counters the revocation of  
> validation data and weaknesses of cryptographic algorithms and keys.
>
> OASIS DSS core specifies a XML format for time-stamps based in XML  
> Sig. In addition DSS core and profiles allow the generation and  
> verification of signatures, time-stamps, and time-stamped  
> signatures by a centralized server"
>
> 2. Best practice 14.
> This reads: "Nonce and timestamp must be signature protected."
>
> Is this correct? I have the impression taht in this section we are  
> speaking of time-stamps of signatures, ie, time-stamps generated  
> after the signature has been produced so that we may prove that at  
> certain point of time the signature already existed; how the time- 
> stamp could be protected by this signature? In addition, a time- 
> stamp  is a secure piece of information: by the TSA's signature  
> (RFC3161 or the DSS time-stamp) or because of the linking mechanism.
>
> Reading what comes before this text:
>
> "Nonces and passwords must fall under at least one signature to be  
> effective. In addition, the signature should include at least a  
> critical portion of the message payload, otherwise an attacker  
> might be able to discard the timestamp and its signature without  
> arousing suspicion.
>
>
> I have the impression that the  Best practice 14 text should be:
> "Nonce and passwords must be signature protected."
>
>
> Regards
>
> Juan Carlos.
> Best Practice 14:
>
>
>
Received on Monday, 2 June 2008 22:10:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 June 2008 22:10:36 GMT