W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: XML Schema base64Binary simple type

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Tue, 12 Jun 2001 14:41:14 -0400
Message-Id: <200106121841.OAA0000052483@torque.pothole.com>
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>

>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
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications

Received on Tuesday, 12 June 2001 14:42:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC