Re: [widgets] Jar signing vs. XML signatures

On Apr 17, 2009, at 13:19 , Henri Sivonen wrote:
> On Apr 17, 2009, at 13:24, Robin Berjon wrote:
>> Trying to separate the discussion from the change request: would  
>> you be satisfied if requirements to perform C14N were removed and  
>> reliance on XSD data types for definition purposes were replaced  
>> with something less scary (though in this case this is a bit of a  
>> FUD argument Henri, the referenced types aren't overwhelming)?
>
> However, if that's not feasible, my next preferred option would  
> indeed be removing the requirement to perform canonicalization (i.e.  
> sign XML as binary with a detached traditional binary signature  
> block).

I will let the digsig experts comment on the feasibility of this.

> As for the data types, I'd be satisfied if the datatypes were  
> defined in such a way that attribute value parsing algorithms and  
> conversion methods that a browser engine has to contain anyway were  
> reusable. This should include well-defined behavior in the case of  
> non-conforming input.

That's reasonable.

> XSD which even allows leap seconds!

I like leap seconds, they're nice!

> (Is it a FUD argument that XSD dates deviate from the value space  
> that is typically used in Posix date conversions between multi-unit  
> tuples and epoch seconds?)

No, that's not what I said. I know XSD painfully enough to know the  
monsters that lurk there, and generally support defining things  
without it if possible. I was referring to statements such as "unless  
widget impls are supposed to bring in huge off-the-shelf XSD  
machinery" when we're talking about ID, anyURI, string, integer,  
base64Binary, dateTime. These certainly have issues, but they can  
nevertheless be operated while drunk :)

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Friday, 17 April 2009 13:17:05 UTC