- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Tue, 12 Jun 2001 14:41:14 -0400
- To: "Gregor Karlinger" <gregor.karlinger@iaik.at>
- cc: "XMLSigWG" <w3c-ietf-xmldsig@w3.org>
Hi Gregor, These are very interesting observations and I agree we need to do something about this...(see comments below) From: "Gregor Karlinger" <gregor.karlinger@iaik.at> To: "Joseph M. Reagle Jr." <reagle@w3.org> Cc: "XMLSigWG" <w3c-ietf-xmldsig@w3.org> Date: Sat, 9 Jun 2001 12:18:31 +0200 Message-ID: <LBEPJAONIMDADHFHAEAOGEHECGAA.gregor.karlinger@iaik.at> >Joseph, > >I think the current Schema definition at least of the >DigestValueType leads to severe problems: > >DigestValueType is derived by restriction from the XML Schema >simple type base64Binary. The *FIXED* value of the "whitespace" >facet is "collapse" for all atomic types other than string [1]. > >A value of "collapse" means that a validating parser normalizes >whitespaces in the string content of the DigestValue element. > >This behaviour could break the signature, if the signer produces >a digest value containing sequences of whitespaces, and the verifier >schema validates the signature. It may be helpful to think about reference validation and siganture validation separately. White space in DigestValue and modifications to white space there should have no effect on reference validation. If it does not yet, we should be sure our document specifies that the DigestValue check is a numeric check, not a string comparison between the DigestValue content and a newly calculated base64 digest. (And the same for SignatureValue check) >Since the "collapse" value for the "whitespace" faced is *FIXED* we >cannot derive our DigestValueType from "base64Binary". Instead we >could derive the type by restriction from "string" since then we >are allowed to change the value of the "whitespace" facet to >"preserve" [1]. Signature verification, on the other hand, is a different matter. You are quite right that it is absolutely essential that signature generators and verifiers serialize SignedInfo, including any white space in DigestValue or anywhere else in SignedInfo, in exactly the same way. >This issue is vital with respect to DigestValueType, but maybe it also >makes sence to change the definition of SignatureValueType, CryptoBinary, >X509SKI, ... since this elements are also likely to be covered by a >signature, and then the same problem applies there. If we are staying with preserving white space, we need to point this out and be sure that our typing supports it. We could change to stripping all white space but I don't see any reason for such a change. Presumably the current interoperability is all based on preserving white space. >--- >[1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#rf-whiteSpace > >Liebe Gruesse/Regards, >--------------------------------------------------------------- >DI Gregor Karlinger >mailto:gregor.karlinger@iaik.at >http://www.iaik.at >Phone +43 316 873 5541 >Institute for Applied Information Processing and Communications >Austria >--------------------------------------------------------------- Thanks, Donald
Received on Tuesday, 12 June 2001 14:42:23 UTC