Re: Best practices: time-stamps comments

Dear all,
For me there is an additional issue that should be mentioned: the XAdES 
(and RFC 3161) time-stamp is signed by a trusted third party, the 
Time-stamp Authority, which is trusted to provide trusted time values. 
If I sign a time indication this does not convert this "time-stamp" in 
something worth to be trusted; if this is done by a TSA acting as a 
trusted third party, the time-stamp actually proves that what was 
timestamped actually existed before the time indicated within the 
time-stamp.
I would include this mention to the trustworthiness of time.stamps 
issued by TSAs...

Regards

Juan Carlos.
Frederick Hirsch escribió:
> It is very useful to maintain this distinction, thank you for pointing 
> this out Pratik.  The WSS usage is what appeared to me in the original 
> reading.
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Jun 10, 2008, at 2:40 AM, ext Pratik Datta wrote:
> 
>> 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 13:06:32 UTC