Scott,
Yes, this flag shall not affect content validity (in this case, the base64 data), and this
behavior is to be changed.
However, I noticed that in the DOM tree, the content remains unnormlized irregardless
of the flag (of course this is not correct either). I think you can set the normalization on to
get your base64 through and at the mean time still have the unnormlized data from the
DOM tree. Can you elabrate more on this? thanks.
Rgds,
PeiYong
| "Scott Cantor"
<[EMAIL PROTECTED]>
10/12/2004 10:39 PM
|
|
I've been running into problems with the way data type validation of
base64Binary is done forever, but this is hitting critical now. ;-(
If I'm understanding correctly, the 2.6.0 changes now require that datatype
normalization be on (I note the default is off) in order to get very typical
base64 content to validate. An example being signed XML, in which use of
most XMLSig libraries will almost always include extra linefeeds between
elements and the values:
<SignatureValue>
Base64stuff
</SignatureValue>
With normalization, the extra linefeeds are removed first, turned to spaces,
and then removed with the new code before the data is validated. Without it,
the new stricter code fails because it leaves the leading linefeed and then
computes the byte count as a non-multiple of 4.
The problem here is that datatype normalization often *cannot* be used if:
- you're signing content that includes base64 and the initial sign takes
place over unnormalized data
- you're intending to process the base64 with, say, OpenSSL, which chokes on
the base64 data if it's in a collapsed form without linefeeds
Basically XML-Security + Xerces 2.6.0 + schema validation is now approaching
incompatible.
The Xerces-J code works because it's much less strict about whitespace
during initial validation, so leaving normalization off is a viable
workaround for these kinds of signature issues.
I guess I'm just scrambling for advice here. I can't quite see how this
works anymore in practice. I can't exactly file a bug. This is technically
correct behavior. It's just not usable behavior.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
