ISSUE-12: Widgets: Digital signatures: XML Signature versus PKCS#7

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

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.

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.

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.

Regards,
-- 
Thomas Roessler, W3C  <tlrw3.org>

Hi Thomas,

On 8/8/07, Thomas Roessler <tlrw3.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

Hello all,

Some information regarding the issue:

Availability of XML signature
http://www.w3.org/Signature/2001/04/05-xmldsig-intero
p.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:marcosscaceresgmail.com] 
>Sent: 16 August, 2007 04:12
>To: Web Application Formats Working Group Issue Tracker;

>public-appformatsw3.org; tlrw3.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 <tlrw3.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

>