Re: [widgets] Jar signing vs. XML signatures

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?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 14 April 2009 10:23:20 UTC