- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Mon, 09 Jun 2008 23:40:49 -0700
- 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 UTC