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

Hi Henri,

On Mon, Feb 22, 2010 at 10:42 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> Sorry about the slow response time.

No problem. Thank you for taking the time to respond at all.

> 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.
>

Agreed. It is certainly simpler.

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

Issues raised are valid, IMO. But implementations thus far have shown
them not to be significant.

>> 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.)
>

Understood.

>> 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.
>

That's ok - look at the Web: it's an ever decreasing mess of
incompatibilities. Regardless, we soldier on even at the expense that
HTML 5 won't reach standardization till 2022 or later. What we are
trying to ascertain is if XML canonicalization is fundamentally broken
(i.e., cannot seriously be used and interop will not be possible
without the costs outstripping the benefits). So, tools suck, but we
can fix 'em.

> 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
>

This shows that there are bugs (like in most software). It does not
show that comparatively speaking it has more bugs than any other
random module.

>> 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.
>

I don't even think JAR has a proper spec that defines the format from
which one could build an implementation. Anyway, I understand what you
are saying.

> 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.
>

Understood.

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

This is certainly true. However, this is diminishing concern and
sometimes a necessary evil. At least the canonicalization spec is
stable, but the JAR spec can change with any release of a JRE.

>> 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.
>

I agree with you here too. Hopefully better dev tools will address
this (yikes! there I go again with the tools will save us :( ).

Thanks again Henri, this was very helpful.
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 17 March 2010 19:20:21 UTC