Re: Best practices: time-stamps comments

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, 3 June 2008 08:05:48 UTC