- From: Sean Mullan <Sean.Mullan@Sun.COM>
- Date: Thu, 18 Dec 2008 09:49:46 -0500
- To: Frederick Hirsch <frederick.hirsch@nokia.com>
- Cc: XMLSec WG Public List <public-xmlsec@w3.org>
>> 3. The Widgets 1.0: Digital Signatures specification will support the >> use of a Timestamp element. This will allow the signature to have a >> shorter lifetime than the certificate associated to it. I think it should be "longer lifetime" above, right? --Sean Frederick Hirsch wrote: > fyi > > regards, Frederick > > Frederick Hirsch > Nokia > > > > Begin forwarded message: > >> *From: *"ext Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com >> <mailto:Mark.Priestley@vodafone.com>> >> *Date: *December 18, 2008 8:03:53 AM EST >> *To: *"David Rogers" <david.rogers@omtp.org >> <mailto:david.rogers@omtp.org>>, <public-webapps@w3.org >> <mailto:public-webapps@w3.org>> >> *Cc: *"Frederick Hirsch" <frederick.hirsch@nokia.com >> <mailto:frederick.hirsch@nokia.com>>, "Thomas Roessler" <tlr@w3.org >> <mailto:tlr@w3.org>> >> *Subject: **RE: [widgets] Digital Signatures questions for discussion* >> >> Hi All, >> >> Marcos, Frederick and I met with Thomas at the recent W3C Security >> workshop and were able to answer the questions that I had put forward >> following the face-to-face discussion with the XML Security working >> group in Mandelieu. >> >> In short we agreed: >> >> 1. DSA-SHA256 will be specified as a second mandatory Signature >> Algorithm. The XML Security working group will specify the >> necessary URI as this is currently not available. >> >> 2. The Widgets 1.0: Digital Signature specification will mandate the >> use of a Usage element (in place of the profile element). This will >> allow signatures to be created that can be used for different purposes >> with different processing requirements. Exact details to be worked out. >> >> 3. The Widgets 1.0: Digital Signatures specification will support the >> use of a Timestamp element. This will allow the signature to have a >> shorter lifetime than the certificate associated to it. The timestamp >> need not be generated by a trusted time stamp authority - it will only >> be valid provided that the certificates associated to the signature >> are also still valid (not expired or revoked) >> >> 4. The Usage and Timestamp elements will be specified in a separate >> specification so that they can be used by other specifications based >> on XML DigSig. Frederick has drafted an initial proposal >> at http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/ >> >> Thomas/Marcos/Frederick - please feel free to correct or add to the above. >> >> Comments and questions welcomed. >> >> Thanks, >> >> Mark >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> *From:* public-webapps-request@w3.org >> <mailto:public-webapps-request@w3.org> [mailto:public-webapps-request@w3.org] *On >> Behalf Of *David Rogers >> *Sent:* 14 November 2008 15:59 >> *To:* public-webapps@w3.org <mailto:public-webapps@w3.org> >> *Subject:* [widgets] Digital Signatures questions for discussion >> >> Dear all, >> >> In Mark Priestley’s absence, he has asked me to forward these >> questions for discussion within WebApps, with the intention of >> this group submitting to the XML Digital Signatures group. These >> questions are in response to the discussions at TPAC: >> >> 1. While it is recognised that there is a broad move to elliptic >> curve techniques, please can you provide an explanation for >> your recommendation that DSA should not be supported even with >> 2048 bit keys? >> >> Note: We are aware that there is no published specification >> describing the use of DSA with key lengths over 1024 but there is >> a NIST draft[1] (publication process due to start before the end >> of the year). It has also been noted that there are concerns >> around licensing on elliptic curve technologies. >> >> 2. Please can you explain in more detail how you would propose to >> use the profile element? >> >> 3. Similarly, please can you explain how the addition of the >> timestamp would help with the revocation process? We assume that >> you require the timestamp to come from a Trusted Timestamp Authority >> >> [1] http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS-186-3%20_March2006.pdf >> >> >> Thanks, >> >> >> David. >> >> David Rogers >> OMTP Director of External Relations >
Received on Thursday, 18 December 2008 14:50:28 UTC