Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@santuario.apache.org
Date: Mon, 30 May 2016 19:49:56 +0200
From: Marc Giger <giger@apache.org>
To: Colm O hEigeartaigh <coheigea@apache.org>
Cc: "dev@santuario.apache.org" <dev@santuario.apache.org>
Subject: Re: Base64 error?
Message-ID: <20160530194956.2297ecdc@mgi.gigerstyle.ch>
In-Reply-To: <CAB8XdGAfqykH==Ub79zE6k9-7hEvou6xkAqfQrQ4ZzUk5FLFsg@mail.gmail.com>
References: <CAB8XdGCCk7no0HciFAu6QTGq7zgKt6+Y4dd68UpcpzPbZw5EDg@mail.gmail.com>
	<574C36F5.3040906@redhat.com>
	<CAB8XdGAfqykH==Ub79zE6k9-7hEvou6xkAqfQrQ4ZzUk5FLFsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
archived-at: Mon, 30 May 2016 17:50:14 -0000

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 <coheigea@apache.org> 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 <asoldano@redhat.com>
> 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