W3C home > Mailing lists > Public > public-appformats@w3.org > September 2007

RE: ISSUE-12: Widgets: Digital signatures: XML Signature versus PKCS#7 [Web Application Packaging]

From: <olli.immonen@nokia.com>
Date: Fri, 21 Sep 2007 13:59:49 +0300
Message-ID: <ACF36FEEDA8DF84AAB8DCF72A6C0A54003F664D2@esebe103.NOE.Nokia.com>
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
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). 


>-----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 
>> 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.
>> 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 Caceres
Received on Friday, 21 September 2007 11:00:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC