RE: FW: Base64

hi all,

i just had the same problem in signing a base64 encoded certificate. i read
the according part of XML Schema and i think Xerces behaves correctly here.
XML Schema says:

---snip-------------------------
4.3.6 whiteSpace

[Definition:]   whiteSpace constrains the ·value space· of types ·derived·
from string such that the various behaviors specified in Attribute Value
Normalization in [XML 1.0 (Second Edition)] are realized. The value of
whiteSpace must be one of {preserve, replace, collapse}.

preserve
No normalization is done, the value is not changed (this is the behavior
required by [XML 1.0 (Second Edition)] for element content)
replace
All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return) are
replaced with #x20 (space)
collapse
After the processing implied by replace, contiguous sequences of #x20's are
collapsed to a single #x20, and leading and trailing #x20's are removed.
NOTE: The notation #xA used here (and elsewhere in this specification)
represents the Universal Character Set (UCS) code point hexadecimal A (line
feed), which is denoted by U+000A. This notation is to be distinguished from

, which is the XML character reference to that same UCS code point.
whiteSpace is applicable to all ·atomic· and ·list· datatypes. For all
·atomic· datatypes other than string (and types ·derived· by ·restriction·
from it) the value of whiteSpace is collapse and cannot be changed by a
schema author; for string the value of whiteSpace is preserve; for any type
·derived· by ·restriction· from string the value of whiteSpace can be any of
the three legal values. For all datatypes ·derived· by ·list· the value of
whiteSpace is collapse and cannot be changed by a schema author. For all
datatypes ·derived· by ·union·  whiteSpace does not apply directly; however,
the normalization behavior of ·union· types is controlled by the value of
whiteSpace on that one of the ·memberTypes· against which the ·union· is
successfully validated.

---snip-------------------------

and because CryptoBinary is defined as

  <simpleType name="CryptoBinary">
    <restriction base="binary">
    <encoding value="base64"/>
    </restriction>
  </simpleType>

Xerces behave correctly.

the only relatively simple solution that i found here is to define
CryptoBinary like

  <simpleType name="CryptoBinary">
    <restriction base="string">
     <whiteSpace value="preserve"/>
     <pattern value="[A-Za-z0-9\+/=\n\r\t ]*"/>
    </restriction>
  </simpleType>

then it works. (ensure that you told Xerces not to ignore ignorable white
space when parsing or serializing).

regards

  Karl

--

Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Graz University of Technology , Austria, http://www.iaik.at and
http://jcewww.iaik.at
Phone: (+43) (316) 873-5540


> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Gregor Karlinger
> Sent: Wednesday, August 29, 2001 7:47 AM
> To: reagle@w3.org; merlin@baltimore.ie
> Cc: XMLSigWG
> Subject: RE: FW: Base64
>
>
> Joseph,
>
> > [Henry, we could use your help in getting Xerces to adopt the
> > erratum with
> > respect to normalized values (not schema normalized values):
> >
> >
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0052.html
> > What's the status of the XML Schema Errata?
> > ]
>
> <Gregor>
>   I do not understand. In the email cited above it is stated that
> XML Schema
>   does not provide default attributes as normalized values, but only as
>   PSVI normalized attribute values. This is a problem different from what
>   I have described, isn't it?
> </Gregor>
>
> > On Tuesday 28 August 2001 09:51, Gregor Karlinger wrote:
> > > <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?
> >
> > If you are using a Transform such as schema validation, and you aren't
> > confident in its conformance, then (unfortunately) you shouldn't
> > use it for
> > now.
>
> <Gregor>
>   The problem I have results rather form using schema validation
> during the
>   signature processing rather than using it as a Transform:
>
>   In our implementation, when verifying a signature, we perform as a first
>   step a schema validating parsing using Xerces to check the syntax of the
>   signature.
>
>   What we expect as the result of this parsing from Xerces are the
> normalized
>   values. Xerces fulfills these expectations, with one exception:
> The value
>   of base64 types is presented in schema normalized form.
> </Gregor>
>
> > >   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?
> >
> > I'm game but I've never submitted a report to Xerces -- do I need
> > to set up
> > an account?
>
> <Gregor>
>   It is quite simple:
>     1. Create an account (specify your name and email address) on page
>        http://nagoya.apache.org/bugzilla/createaccount.cgi
>     2. Submit bug at page
>        http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Xerces-J
> </Gregor>
>
> > Did you respond to the resolution, it's pretty
> > obvious they don't
> > understand our issue:
> >
> >   http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1228
> >   >whiteSpace facet value is collapsed for base64Binary.
> >   >Thus, xerces does the  right thing.
>
> <Gregor>
>   No, unfortunately not. I mixed up things at that time and thought they
>   are right.
> </Gregor>
>
> 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
> ---------------------------------------------------------------
>
>
>
>