RE: Base64 -- do we really want/need line breaks every 76 charact ers?

Hi Michael,

I suppose that's why I added the adverb 'virtually'.

Anyway, all that would mean is that one should not use the OpenSSL base
64 implementation to build an XML Dsig base64 transform.  Even if one
had to write the code from scratch, it's not rocket science.

Also, if OpenSSL is open source, then it is ripe for a patch!

John Boyer
Senior Product Architect, Software Development
Internet Commerce System (ICS) Team
PureEdge Solutions Inc. 
Trusted Digital Relationships
v: 250-708-8047  f: 250-708-8010
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	
 	


-----Original Message-----
From: Michael McIntosh [mailto:michaelm@valicert.com]
Sent: Wednesday, May 23, 2001 9:12 AM
To: John Boyer; Donald E. Eastlake 3rd; w3c-ietf-xmldsig@w3.org
Subject: RE: Base64 -- do we really want/need line breaks every 76
charact ers?


At least one widely used SDK that provides base64 encode/decode
functionality (OpenSSL) ignores characters beyond the 76th while
decoding
base64.

Thanks,
Mike

-----Original Message-----
From: John Boyer [mailto:JBoyer@PureEdge.com]
Sent: Wednesday, May 23, 2001 12:03 PM
To: Donald E. Eastlake 3rd; w3c-ietf-xmldsig@w3.org
Subject: RE: Base64 -- do we really want/need line breaks every 76
characters?




Hi Donald,

C14N doesn't remove new lines inside content.

However, line delimiters are normalized to #xA characters, so if one is
going to move a document around in canonical form, then one would have
to convert each #xA to #xD#xA before calling an RFC2045-compliant  base
64 decoder.

Seems like a royal pain considering the fact that virtually everybody
writes decoders that don't require the linefeeds at all and simply skip
CR and LF characters (regardless of whether they are in sequence).

I think that as long as we were clear that an XML-DSig compliant base 64
transform must be permissive w.r.t. the placement and context of
occurrence of CR and LF characters, then it should be fine.

John Boyer
Senior Product Architect, Software Development
Internet Commerce System (ICS) Team
PureEdge Solutions Inc. 
Trusted Digital Relationships
v: 250-708-8047  f: 250-708-8010
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	
 	


-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
Sent: Tuesday, May 22, 2001 7:42 PM
To: w3c-ietf-xmldsig@w3.org
Subject: Re: Base64 -- do we really want/need line breaks every 76
characters? 



Given the way we are going, this line break requirement should be
removed as Brian suggests. Afterall, Canonical XML removes all new
lines inside tags so, unless you have new lines in content, you get
one line out no matter how long.

I belive the email limit is 1000 characters (actually 998 not counter
the CR-LF) but in any case if you try to mail "text" that doesn't meet
the requirements of your email transport, it just gets QuotedPrintable
or Base64 encoded. (Yes, a 10,000 character long line of "Base64"
would get Base64'ed a second level if sent over normal text email.)

Thanks,
Donald

From:  Martin Duerst <duerst@w3.org>
Message-Id:  <4.2.0.58.J.20010523094402.03db42d0@sh.w3.mag.keio.ac.jp>
Date:  Wed, 23 May 2001 09:46:52 +0900
To:  "Brian LaMacchia" <bal@microsoft.com>, <w3c-ietf-xmldsig@w3.org>
In-Reply-To:
<BCDB2C3F59F5744EBE37C715D66E779CEAB6CD@red-msg-04.redmond.
	      corp.microsoft.com>

>This should be fixed in XML Schema, not in Signatures, I guess.
>On the other hand, it's not a bad idea to have line breaks in
>the Base64, just streaming out something as a very long line
>(e.g. 1000000 chars) doesn't seem like a good idea. It will
>cause problems sooner or later. For example, SOAP may be used
>over mail, and what happens then?
>
>Regards,  Martin.
>
>At 17:31 01/05/22 -0700, Brian LaMacchia wrote:
>>Folks--
>>
>>Currently, XMLDSIG references RFC 2045 (one of the MIME RFCs) for a
>>definition of Base64 encoding/decoding.  (See section 6.8 of [1].)  It
>>has been pointed out to me that RFC 2045 *requires* that
Base64-encoded
>>content have line breaks at least every 76 characters.  Paragraph 6
>>reads as follows:
>>
>>    The encoded output stream must be represented in lines of no more
>>    than 76 characters each.  All line breaks or other characters not
>>    found in Table 1 must be ignored by decoding software.  In base64
>>    data, characters other than those in Table 1, line breaks, and
other
>>    white space probably indicate a transmission error, about which a
>>    warning message or even a message rejection might be appropriate
>>    under some circumstances.
>>
>>I can't see any reason for XMLDSIG to inherit a line-length limitation
>>that appears to have been there for mail-specific reasons.  The SOAP
1.1
>>submission [2] removes the line length limitation in their use of
>>Base64; Section 5.4.3 of SOAP reads as follows:
>>
>>    The recommended representation of an opaque array of bytes is the
>>    'base64' encoding defined in XML Schemas [10][11], which uses the
>>    base64 encoding algorithm defined in 2045 [13]. However, the line
>>    length restrictions that normally apply to base64 data in MIME do
>>    not apply in SOAP. A "SOAP-ENC:base64" subtype is supplied for use
>>    with SOAP.
>>
>>I propose that XMLDSIG adopt language similar to SOAP and not require
>>applications to insert line breaks at least every 76 characters.
>>(Conforming implementation will still accept line-limited encodings
>>since they have to ignore any found whitespace in the Base64 string.)
>>
>>                                         --bal
>>
>>[1] http://www.ietf.org/rfc/rfc2045.txt
>>[2] http://www.w3.org/TR/SOAP/
>

Received on Wednesday, 23 May 2001 12:20:24 UTC