Hi Henri, On Mon, Feb 22, 2010 at 10:42 AM, Henri Sivonen <[email protected]> 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
