Re: Best practices: time-stamps comments

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.


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 UTC