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

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/

Received on Monday, 22 February 2010 09:42:58 UTC