I'd thought that the line length restriction had been overridden
somewhere for XML Sig, but I don't see where that's specified. There was
a discussion of this whole issue with the intent to change it:
https://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0195.html
XML Schema requires processors to ignore the line-length limitation and
collapse whitespace sequences to single space characters, so in schema
terms this all becomes irrelevant, and XML Sig says the schema is
normative. But it also says MIME is normative. Which is more normative
than the other?
- Dennis
On 05/31/2016 05:49 AM, Marc Giger wrote:
Hi Colm,
XMLDsig and XMLEnc referring RFC 2045 (Base64 MIME) as you
already noted. After reading many sources I also come to
the conclusion that
a) Line breaks MUST be inserted after 76 characters
b) Line breaks MUST be CRLF sequences
The Java-Doc of java.util.Base64 and
org.apache.commons.codec.binary.Base64
also confirms that statement.
To get the same output from both implementations you
can/should use
java.util.Base64.getMimeEncoder() // RFC2045
and
org.apache.commons.codec.binary.Base64.Base64(final boolean
urlSafe) // RFC2045
or other constructors while specifying explicitly the line lengths and
newline characters.
In the case of commons codec the _decoder_ should work with none/LF/CRLF
because it simply ignores unexpected values.
I can imagine that other decoder impl. do the same. Santuario
should most probably do the same for max. interoperability.
Btw, it looks like I got it also wrong (because I didn't read the RFC)
in the StAX impl. If it happens that you fix the Base64 impl. could
you also correct the new Base64OutputStream(...) call in
AbstractEncryptOutputProcessor ?
Thanks and happy coding,
Marc
On Mon, 30 May 2016 14:32:30 +0100
Colm O hEigeartaigh <[email protected]> wrote:
I did some interop testing with the Commons Codec Base64
implementation and the JDK8 java.util one, and the output is
different. I have to explicitly use new byte[] {'\n'} for the line
break to get them to work with Santuario.
Colm.
On Mon, May 30, 2016 at 1:49 PM, Alessio Soldano <[email protected]>
wrote:
I wonder which implications this could have in terms of
interoperability... ?
Il 30/05/2016 12:30, Colm O hEigeartaigh ha scritto:
Hi,
I'm doing some testing with various BASE-64 implementations and I
think there's an error in the Santuario Base64 encoder to do with
whitespace. If so though it's been there a looong time without
anyone noticing...
The BASE64 implementation is here:
https://svn.apache.org/repos/asf/santuario/xml-security-java/trunk/src/main/java/org/apache/xml/security/utils/Base64.java
In the "encode" method it's adding a newline character with:
encodedData[encodedIndex++] = 0xa;
However this is just "\n". The RFC defines a CRLF as "\r\n":
https://www.ietf.org/rfc/rfc2045.txt
It looks like a bug...but would like some feedback from others more
familiar with the RFC.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Alessio Soldano
Web Service Lead, JBoss
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
