Re: [widgets] Jar signing vs. XML signatures

On Apr 15, 2009, at 15:00, Marcos Caceres wrote:

> On Tue, Apr 14, 2009 at 4:19 PM, Henri Sivonen <hsivonen@iki.fi>  
> wrote:
>> On Apr 14, 2009, at 14:38, Marcos Caceres wrote:
>>
>>> 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.
>>
>>
>> So the issues were:
>>  1) The complexity of canonicalization/reserialization of XML.
>
> I think this is an issue that needs to be taken up with XML Security
> WG or whoever is working on the canonicalization spec.

That's not the point. The point is that XML signatures try to solve a  
more complex problem than what needs solving for signing a zip file.  
It would be useless to tell people who do want to solve the complex  
problem that they should solve it without canonicalization.

But widgets don't really need to solve the problem XML signatures  
solve. Widgets could get away with signing a manifest traditionally  
without the signing method knowing that what is being signed happens  
to be XML.

This would result in having to reserve one file name for the manifest  
(either in a jar-ish text format or in a W3C-ish XML format) and a  
range of file names for detached signatures in traditional binary  
formats that off-the-shelf crypto libraries support. The cost of  
putting the signatures inside the manifest XML file is that you end up  
importing complexity like canonicalization.

The above approach won't quite work without a bit of elaboration you  
really want the distributor to sign the author signature and not just  
sign the same manifest. (What's the purpose of "A distributor  
signature MUST have a ds:Reference for any author signature, if one is  
present within the widget package." Why does it matter for the widget  
engine that the distributor signed the author signature if both sign  
the same manifest?)

>>  2) Spec dependency on XSD.
>
> We can probably address this and use prose as you suggested. So you
> recommend we follow HTML5 here, right?

Yes, I think the HTML5 approach to defining syntax is better.

> Given that you understand the problem, can you maybe propose some  
> text?

I'm not sure I understand the problem that the spec is solving. :-)  
For example, I don't know where the code for actually parsing  
CreatedType is supposed to come from. However, my wild guess is that  
unless widget impls are supposed to bring in huge off-the-shelf XSD  
machinery, it would be better to use English to define a more  
constrained date format here the way HTML5 does than to defer to XSD.  
Of course, that doesn't help much if you import XSD deps otherwise  
from XML signatures. If you are bringing in XSD machinery anyway,  
defining things without XSD might even hurt. What's the expected  
software reuse scenario here?

>> Instead of canonicalizing the manifest XML and using XML signature,  
>> you
>> could treat the manifest XML as a binary file and sign it the  
>> traditional
>> way leaving a detached binary signature in the format customary for  
>> the
>> signing cipher in the zip file. This would address issues #1 and #2.
>
> That is our intention.

Do you mean that's the existing plan (that's not what it looks like)  
or that that's a new intention?

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

Received on Wednesday, 15 April 2009 14:26:43 UTC