Re: FW: Base64

http://www.w3.org/TR/xmlschema-1/#PSVI_contributions
(Contributions to the Post-Schema-Validation Infoset)

This states that schema-normalized values contribute to the PSVI.

http://www.w3.org/TR/xmlschema-1/#key-nv

[Definition:]  The normalized value of an element or attribute information
item is an initial value whose white space, if any, has been normalized
according to the value of the whiteSpace facet of the simple type definition
used in its validation:

Reading this, I don't think that the regular infoset, as exposed
by DOM, should be modified. We might be well served by asking a
schema person.

Merlin

r/Karl.Scheibelhofer@iaik.at/2001.08.29/14:27:14
>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 =B7value space=B7 of types =B7der=
>ived=B7
>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 =B7atomic=B7 and =B7list=B7 datatypes. For =
>all
>=B7atomic=B7 datatypes other than string (and types =B7derived=B7 by =B7res=
>triction=B7
>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
>=B7derived=B7 by =B7restriction=B7 from string the value of whiteSpace can =
>be any of
>the three legal values. For all datatypes =B7derived=B7 by =B7list=B7 the v=
>alue of
>whiteSpace is collapse and cannot be changed by a schema author. For all
>datatypes =B7derived=B7 by =B7union=B7  whiteSpace does not apply directly;=
> however,
>the normalization behavior of =B7union=B7 types is controlled by the value =
>of
>whiteSpace on that one of the =B7memberTypes=B7 against which the =B7union=
>=B7 is
>successfully validated.
>
>---snip-------------------------
>
>and because CryptoBinary is defined as
>
>  <simpleType name=3D"CryptoBinary">
>    <restriction base=3D"binary">
>    <encoding value=3D"base64"/>
>    </restriction>
>  </simpleType>
>
>Xerces behave correctly.
>
>the only relatively simple solution that i found here is to define
>CryptoBinary like
>
>  <simpleType name=3D"CryptoBinary">
>    <restriction base=3D"string">
>     <whiteSpace value=3D"preserve"/>
>     <pattern value=3D"[A-Za-z0-9\+/=3D\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=3D1228
>> > >
>> > >   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=3DXerces-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=3D1228
>> >   >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


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Wednesday, 29 August 2001 11:21:34 UTC