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

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