Re: [widgets] Jar signing vs. XML signatures

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

-- 
Marcos Caceres
http://datadriven.com.au

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