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 [email protected] http://hsivonen.iki.fi/
