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

From RFC 2045:
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. 

So OpenSSL is actually non-compliant (although the word MUST appears to have
not been capitalized).

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
> Sent: Wednesday, May 23, 2001 3:17 PM
> To: Michael McIntosh; w3c-ietf-xmldsig@w3.org
> Subject: 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/
> >>
> >
> >
>