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

Re: Best practices: time-stamps comments

From: Pratik Datta <pratik.datta@oracle.com>
Date: Mon, 09 Jun 2008 23:40:49 -0700
Message-ID: <484E21F1.5080001@oracle.com>
To: Juan Carlos Cruellas <cruellas@ac.upc.edu>
CC: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec XMLSec <public-xmlsec-maintwg@w3.org>

The word "timestamp"  means two different things in WSS and XAdES

In WSS, the timestamp is just a dateTime value. It represents the time, 
the signature was created, or the time the signature expires.
But in XAdes and DSS timestamp is actually a signature which signs a 
dateTime Value and message Digest.

To avoid confusion we need to use a different name for these two 
concepts. I changed the document to use "dateTime" or "Signing time" for 
the WSS meaning of timestamp. I also added a separate section for XAdES.

http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/

Pratik

Juan Carlos Cruellas wrote:
>
> Frederick Hirsch escribió:
>> 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?
>>
> Yes....
>> 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?
>>
> I am not saying that, what I am saying is that as I read the text 
> before it did not clarify what was time-stamped by the time-stamp 
> generated before signing, and obviously, if this is the case, what it 
> may not be time-stamped is the signature.
>
> There are a number of things that we may do:
>
> Step 1: generate a nonce, time-stamp (TST-N) the nonce and/or other to 
> be signed data objects. TST-N would prove when the nonce was generated 
> and/or the to be signed data existed
>
> Step 2: sign the data objects, the nonce and TST-N.
>
> Step 3: time-stamp the signature (TST-S). This TST-S would prove when 
> the signature was created.
>
> The text dealing with nonce and time-stamp should clarify what 
> time-stamp is talking about, the TST-N or the TST-S, as each is for a 
> different purpose. In addition to that, XAdES  specifies elements able 
> to encapsulate both TSTs.
>
>
> Juan Carlos.
>> 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 Tuesday, 10 June 2008 06:42:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 10 June 2008 06:42:55 GMT