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

RE: FW: Base64

From: Gregor Karlinger <gregor.karlinger@iaik.at>
Date: Tue, 28 Aug 2001 15:51:47 +0200
To: <merlin@baltimore.ie>
Cc: "Joseph M. Reagle Jr." <reagle@w3.org>, "XMLSigWG" <w3c-ietf-xmldsig@w3.org>
Message-ID: <LBEPJAONIMDADHFHAEAOAEJCCIAA.gregor.karlinger@iaik.at>
Merlin & Joseph,

I send my answer to the list in cc: because I think this matter is of
general interest.

-----Original Message-----
> From: merlin@baltimore.ie [mailto:merlin@baltimore.ie]
> Sent: Tuesday, August 28, 2001 2:47 PM
> To: Gregor Karlinger
> Cc: Joseph M. Reagle Jr.
> Subject: Re: FW: Base64

[...]

> I believe that Xerces is in error if it performs any
> normalization on the values returned by DOM; it seems
> to provide no API for obtaining the augmented infoset.
>
> I haven't solved this problem, other than a release
> note stating that Xerces isn't fully conformant with
> all requirements of xmldsig.

<Gregor>
  But this means that you cannot verify correctly a signature that
  (for instance) has produced the base64 of a DigestValue in a way
  that is different from the schema-normalized form, doesn't it?
  Or do skip schema validation before verifying a XML signature?

  I think this problem is quite a severe one, since many implemen-
  tations rely on the Xerces parser. I have reported the Xerces
  behaviour on schema-validating base64 text as a bug a while ago
  ([1]), but unfortunately I have not convinced them.

  [1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1228

  I suggest that we should try a bug report once again, maybe in
  the name of the Signature WG. Joseph?
</Gregor>

[...]

> >> -----Original Message-----
> >> From: Gregor Karlinger [mailto:gregor.karlinger@iaik.at]
> >> Sent: Thursday, August 16, 2001 10:16 AM
> >> To: merlin; Gregor Karlinger
> >> Cc: Joseph M. Reagle Jr.; XMLSigWG
> >> Subject: RE: Base64
> >>
> >>
> >> Merlin,
> >>
> >> > Hi Gregor,
> >> >
> >> > As far as I (possibly we) understand it, schema-normalized values are
> >> > *not* exposed as part of the standard XML infoset (and thus probably
> >> > not DOM), but as part of the post schema-validation infoset, which is
> >> > an augmentation, not a replacement, of the XML infoset.
> >> >
> >> > So, any canonical form for base64 should not affect signature
> >> processing.
> >>
> >> As far as I know you are using Xerces as parser for your
> toolkit. How do
> >> you deal with the related behaviour of Xerces? Xerces does not provide
> >> an interface for "exposing the post-schema validation infoset , beyond
> >> that provided by DOM or SAX;".
> >>
> >> So this means that if I turn on validating parsing in Xerces I
> get a DOM
> >> document with schema-normalized base64Binary values. It seems
> that Xerces
> >> does this validation not on all types. For instance, no
> normalization is
> >> done for an integer type. Currently I have not found a way to
> avoid this
> >> behaviour.
> >>
> >> > Also, there is a proposal that schema validation be an *explicit*
> >> > transform, so the possibility of sender/recipient schema validation
> >> > conflict (defaulted values) may be reduced. Of course, this won't
> >> > really help in the case of same-document references.
> >>
> >> As you state, this does help neither for same-document
> references nor for
> >> getting the octets that form the input of cryptographic signature
> >> validation.
> >>
Received on Tuesday, 28 August 2001 09:52:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC