W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] Jar signing vs. XML signatures

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 14 Apr 2009 13:38:20 +0200
Message-ID: <b21a10670904140438g4aa85f66rea477d068303d00b@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Thomas Roessler <tlr@w3.org>, public-webapps <public-webapps@w3.org>
Hi Henri,
On Tue, Apr 14, 2009 at 12:22 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Apr 14, 2009, at 13:01, Thomas Roessler wrote:
>> On 14 Apr 2009, at 11:42, Henri Sivonen wrote:
>>> XSD datatypes are too vague, allow whitespace where the spec writer
>>> didn't mean to allow whitespace or allow surprising values (like "0" and "1"
>>> when the spec writer though (s)he'd be allowing "true" and "false"). It is
>>> much safer to define datatypes in precise English prose like HTML5 does than
>>> to expect XSD to match what is really meant.
>> There's an interesting discussion to be had here; however, I doubt it's in
>> scope for this WG.  (In other words, this strikes me as a rathole.)
> I don't see why widgets need to depend on XML signatures at all.
>>>>> When you need to reserialize XML, you import all the troubles of
>>>>> serializing XML (see e.g.
>>>>> https://issues.apache.org/bugzilla/buglist.cgi?query_format=advanced&product=Security&component=Canonicalization&cmdtype=doit ).
>>>> The only place where you actually need canonicalization is when hashing
>>>> the SignedInfo element inside the signature file (i.e., once per signature
>>>> verification).
>>>> Given that the signature format is profiled down pretty heavily in the
>>>> widget signing spec, I'd dare a guess that most of the complexity isn't ever
>>>> used, so a careful implementation might be able to write a c14n
>>>> implementation that bails out on anything that doesn't look like a signature
>>>> that follows the constraints in this format.
>>> If you need to do canonicalization even in one place, you need a properly
>>> debugged implementation of it. If the signature format is profiled heavily,
>>> doesn't it mean you can't even use an off-the-shelf implementation of XML
>>> signatures?
>> Much of the complexity of canonicalization (and signature in general)
>> comes from the need to deal with pretty arbitrary nodesets generated by
>> transform chains.  The widget signature profile does not use (i.e., it's a
>> MUST NOT) any transform chains.
>> Since the use of transforms is a choice of the signature application, you
>> shouldn't have any trouble using existing toolkits.
> This all seems like needless complexity to me. To sign a zip archive, one
> needs a manifest file that contains digests for all the other zip entries
> and a signature for the manifest file. Even if widgets use an XML manifest
> instead of a jar-style plaintext manifest (which would be supported by
> existing jar signing tools; analogously to the zip format itself having been
> chosen due to pre-existing tool support), why would one want to sign the
> manifest XML with the XML signature machinery instead of signing it as a
> sequence of bytes using a well-established detached signature format for
> signing a file of bytes?

Although I agree that it was probably a short-sightedness mistake on
our part to not have looked at JAR signing at the start of this
process, I think it is too late for you to ask us to dump over a year
worth of work on this spec - especially as we are about to go to Last
Call and have significant industry support (BONDI) for using XML
Signatures. Although I also agree that there are issues with
canonicalization, I find it hard to believe that JAR signatures are
not without their own problems. I think it would be more productive to
help us address the issues that you mentioned, instead of asking us to
dump everything and start again.

Kind regards,

Marcos Caceres
Received on Tuesday, 14 April 2009 11:39:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:25 UTC