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]
