Fwd: Issues with XML Dig Sig and XML Canonicalization; was Re: Rechartering WebApp WG

[Breno de Medeiros <breno@google.com>]

---------- Forwarded message ----------
From: John Panzer <jpanzer@acm.org>
Date: Mon, Feb 22, 2010 at 23:33
Subject: Fwd: Issues with XML Dig Sig and XML Canonicalization; was
Re: Rechartering WebApp WG
To: breno@google.com


Canonicalization.  Very dangerous.  You go first!

---------- Forwarded message ----------
From: Henri Sivonen <hsivonen@iki.fi>
Date: Monday, February 22, 2010
Subject: Issues with XML Dig Sig and XML Canonicalization; was Re:
Rechartering  WebApp WG
To: Marcos Caceres <marcosc@opera.com>
Cc: Scott Wilson <scott.bradley.wilson@gmail.com>, Jonas Sicking
<jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>, Frederick
Hirsch <Frederick.Hirsch@nokia.com>


Sorry about the slow response time.

On Feb 12, 2010, at 16:07, Marcos Caceres wrote:
> What we are discussing is if Mozilla's solution for signing Zip files (JAR-based) [1] is easier for vendors to implement/maintain and authors to deal with when compared to the W3C Widget solution of using XML Dig Sig.

I think it's clear that JAR/XPI signing is simpler than XML Dig Sig,
because JAR signing operates on a plain text / line-base manifest and,
thus, doesn't require XML canonicalization before the signing step.

I have previously listed the summary of issues in
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0178.html

> Thus far, in terms of ease of use for authors, little in the way of concrete evidence has been presented of one signing method being easier than the other (specially by looking at the complexity of using Mozilla's command line-based tool [1] compared to BONDI's SDK [2]). This is not to say that Mozilla (or anyone, given its open source nature) could not make a super easy tool for signing zip files.

FWIW, I think I haven't ever argued anything about the ease of use of
Mozilla's XPI signing tool. I have previously argued that Sun's jar
signing tools were widely available. (Previously, I was unaware that
.jar and .xpi used different crypto algorithms. Since .xpi is newer,
one might assume it has a "better" algorithm in terms of crypto
characteristics but obviously not in terms of network effects of tool
availability.)

> However, the proof is in the pudding here: By virtue that Bondi's SDK includes a tool that allows widgets to be signed with a few clicks is evidence that the W3C's Widgets Signature specification is capable of being used to produce easy to use products.

I don't think I've ever claimed that the production of easy-to-use
products weren't *possible*. My claim was that XML Canonicalization
(whether Exclusive or not) introduces enough *implementation*
complexity that previously, buggy canonicalization code has been
deployed, which has lead to signatures failing to validate with other
implementations that weren't bugwards-compatible with the signer's
implementation.

Here's evidence of bugs in just one high-profile Canonicalization
implementation:
https://issues.apache.org/bugzilla/buglist.cgi?query_format=advanced&product=Security&component=Canonicalization&cmdtype=doit

> In terms of implementation, Mozilla has previously raised concerns about XML canonicalization (which I don't fully understand, hence the growing email cc list) - but by the virtue that people have implemented the Widget signing spec, I await to see if Mozilla's concerns will materialize in practice and actually hinder interoperability - I'm not saying this is FUD, but we need proof.

The above is proof of *previous* interop-sensitive bugs in a
widely-deployed Canonicalization implementation. There's no reason to
believe that complexity-induced bugs of this kind are unique to one
implementation. Instead, I think it's fair to expect any from-scratch
implementation of Canonicalization to be prone to similar bugs *that
could be avoided by using jar signing instead*, since jar signing
omits the Canonicalization step entirely.

Unfortunately, due to confidentiality concerns of people deploying
crypto software, I can't give you concrete deployment stories where
the above-cited bugs have caused interop issues. I can only point to
the public bug list and assert that bugs in this area have had actual
interop consequences at deployment time.

(Also, having to have a Canonicalization impl. adds code bloat
compared to having a jar signing impl.)

> It's too early to make the call that widget signing is flawed. And it's important to note that no one that has implemented has come back to the WG raising any concerns or screaming bloody murder.

It could be that people don't sign widgets very often. I don't recall
ever seeing a signed Firefox extension or a signed Eclipse plug-in.

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)