- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 14 Apr 2009 13:22:36 +0300
- To: Thomas Roessler <tlr@w3.org>
- Cc: public-webapps <public-webapps@w3.org>
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