Re: FW: Base64

[cc:'d to schema comments since we need clarity on upcoming errata]

On Wednesday 29 August 2001 08:27, Karl Scheibelhofer wrote:
> i just had the same problem in signing a base64 encoded certificate. i read
> the according part of XML Schema and i think Xerxes behaves correctly here.

OK, first a summary of the issue if I can get it straight:

The xmldsig WG would like for schema validation to *not* collapse the 
whitespace of base64 data in the *normalizedValue* of element content (as 
specified in XML1.0). There are scenarios in which people validate the 
signature itself (instead of the data it signs which is served by an explicit 
transform) and this then affects the computation of the signature: the 
signature's base64 data [1] whitespace is collapsed:

   "For all *atomic* data-types other than string ... the value of 
   whitespace is collapse." [2]

[1] http://www.w3.org/TR/xmlschema-2/#base64Binary
[2] 
http://www.w3.org/TR/xmlschema-1/#section-White-Space-Normalization-during-Validation

For instance, the signature creator might create a signature with whitespace 
in the base64 element content, but the signature validator first schema 
validates (which collapses the whitespace) and consequently fails to validate 
the Signature.

The result is that I believe processors like Xerces are doing the right thing 
presently, but there's two erratum (that I'm confused about) that might 
affect this:

First erratum is a non-issue. While the schema WG reported some changes to 
the base64Binary type [3], these only apply to the permitted lexical space 
and schema-canonical form. Nothing was said with respect to its whitespace 
being collapsed.

Second erratum has to do with whether *any* changes schema validation effects 
occur over the normalizedValue or the schemaNormalizedValue. Presently, it 
appears schema validation is affecting the normalizedValue.  However, I 
believe Henry [4] indicated there might be errors in the spec that omitted 
the distinction. Consequently, my (possibly incorrect) understanding is that 
the Schema erratum will be more clear about changes applying to the 
*schemaNormalizedValue* and (if any) changes to the normalizedValue.

[3] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0085.html
[4] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0052.html

My best understanding of the Schema specifications comes by playing with the 
XSV implementation [5]. This time, I created a simple schema and instance 
(attached) containing base64Binary element content with white space, ran the 
XSV over it, and examined the Post Schema Validated Infoset (PSVI). 
Unfortunately, it *only* provided a schemaNormalizedValue; normalizedValue is 
not even present. 

      <psv:schemaNormalizedValue>XVGVzdCENCg0K</psv:schemaNormalizedValue>   

So I'm not surprised if other implementations treat the two as the same, but 
I *believe* they are distinct and that the normalizedValue should not have 
it's whitespace collapsed.

[5] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0053.html