Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: security-dev@xml.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: "Scott Cantor" <cantor.2@osu.edu>
To: <security-dev@xml.apache.org>
Subject: RE: base64 elements linebreak
Date: Wed, 25 Jan 2006 20:48:45 -0500
Organization: The Ohio State University
Message-ID: <001401c6221a$a4b2e780$6501a8c0@oit.ohiostate.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AcYiFMU2Kik03O/OSpqs69fh5nWlIwAA/AYw
In-reply-to: <20060126010615.25073.qmail@web36705.mail.mud.yahoo.com>

> So, for example, if the original base64 encoded data
> comes through SMTP, we will have to decode and encode
> it again if we have to put the same value in an XML?

No, precisely the opposite. Anything you get that's legal base64, whatever
the line length, is "legal" XML, and moreover is valid with respect to the
rules for base64Binary in XSD. So saying that it should look a certain way
is only advisory.

In other words, xmlsec producing the line feeds is legal. That's all I was
trying to say. Requiring them would not be, obviously.

I must have said something that confused you or that I didn't say clearly. I
wasn't trying to argue anything else.

> What I am driving at is that having new lines in
> base64 encoded data is not restricted by any spec - in
> fact it is deemed necessary by at least one spec.
> And also that you can make your decoder flexible by
> checking and setting the flag as I mentioned earlier.

Sure. All I was saying in the thread was that one reason why the linefeeds
were useful was because that flag was either not known, not implemented,
etc, so without them, using OpenSSL's decoder was a problem. And the
workaround was to not use OpenSSL's decoder, which is really the better
solution...yeah, the flag's there, but why bother when you can just do it in
one pass without examining the data first?

> But normalization is a real problem for signature
> validation, as you mentioned earlier - looks like
> whitespace facet for signed content must always be
> preserve - particularly if you have schema validators
> before signature verification.

Correct, and of course this isn't allowed by XSD, which requires collapse
for base64Binary. So you have to turn the normalization off to get it to
work.

In practice, what makes things tend to work is that schema validation and
signature-oriented applications aren't all that overlapping in practice,
something I had to learn the hard way.

-- Scott