- From: <olli.immonen@nokia.com>
- Date: Fri, 21 Sep 2007 13:59:49 +0300
- To: <marcosscaceres@gmail.com>, <sysbot+tracker@w3.org>, <public-appformats@w3.org>, <tlr@w3.org>
Hello all, Some information regarding the issue: Availability of XML signature http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html There are 16 implementations including open source implementations - Apache (C++ and java) http://xml.apache.org/security/index.html - XMLSec (C) http://www.aleksey.com/xmlsec/ PKCS#7 alone would not yeat be a solution - it just defines an ASN.1 DER binary blob. One would need to design how to apply that in this case: what to sign, where to put the signature with regards to the zip archive, intermediate files (e.g. J2SE jar signing uses this approach but with quite a complex design). /Olli >-----Original Message----- >From: ext Marcos Caceres [mailto:marcosscaceres@gmail.com] >Sent: 16 August, 2007 04:12 >To: Web Application Formats Working Group Issue Tracker; >public-appformats@w3.org; tlr@w3.org >Cc: Immonen Olli (Nokia-NRC/Helsinki) >Subject: Re: ISSUE-12: Widgets: Digital signatures: XML >Signature versus PKCS#7 [Web Application Packaging] > >Hi Thomas, > >On 8/8/07, Thomas Roessler <tlr@w3.org> wrote: >> >> On 2007-08-08 08:46:13 +0000, Web Application Formats Working Group >> Issue Tracker wrote: >> >> > ISSUE-12: Widgets: Digital signatures: XML Signature versus >> > PKCS#7 [Web Application Packaging] >> >> > http://www.w3.org/2005/06/tracker/waf/issues/ >> >> > Raised by: Bernardo Sampaio >> > On product: Web Application Packaging >> >> > See minutes from 7 August 2007 discussion: >> > http://www.w3.org/2007/08/08-waf-minutes.html >> >> That's actually http://www.w3.org/2007/08/07-waf-minutes.html... >> >> Skimming through these minutes, we'd want to profile either >PKCS#7 or >> XML Signature down to a subset that gives us the functionality >> *really* needed. >> >> Using XML Signature, one would probably pin things down to a single >> canonicalization algorithm (and if you don't actually need >> canonicalization for the use case you are looking at, then you could >> even just put the identity transform in there -- it's NOT >obvious that >> every signature needs canonicalization!), a very narrow set >of crypto >> algorithms, a very narrow set of transforms to be permitted >(probably >> meaning "none at all"), and so on -- thereby ditching 90% of the >> generality and most of the overhead that is simply not >needed for the >> use case at hand. > >Yeah, this is kinda what we were thinking. Kinda like a >Digital Signatures "Lite." > >> Note that this suggestion goes far beyond what's covered by the >> current widget signing proposal, in terms of constraining the use of >> XML Signature. > >We tend to feel it is important, there seems to be significant >overhead with XML Signature. > >> Therefore, I think the performance and overhead arguments about XML >> Signature can be made moot by proper profiling, returning us to the >> XML vs. ASN.1 discussion. > >Agreed. > >> And on that discussion, since widgets are already using XML for >> configuration files, I'd +1 the use of XML Signature over going for >> PKCS#7. > >I'll also back this as long as it is possible to profile XML >Signature in such a way that it does not break. I'll also >start looking into this. > >Kind regards, >Marcos > >-- >Marcos Caceres >http://datadriven.com.au >
Received on Friday, 21 September 2007 11:00:15 UTC