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

That's pretty amazing. I wouldn't want to use such a Bas64 decode for
XMLDSIG or anything else either.  It sounds fundamentally broken to me.

Donald

From:  "John Boyer" <JBoyer@PureEdge.com>
Date:  Wed, 23 May 2001 09:18:09 -0700
Message-ID:  <7874BFCCD289A645B5CE3935769F0B5219624D@tigger.PureEdge.com>

>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 15:17:17 UTC