W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

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

From: Brian LaMacchia <bal@microsoft.com>
Date: Tue, 22 May 2001 19:22:22 -0700
Message-ID: <BCDB2C3F59F5744EBE37C715D66E779CEAB6D1@red-msg-04.redmond.corp.microsoft.com>
To: <duerst@w3.org>, <w3c-ietf-xmldsig@w3.org>
Whether one needs line breaks seems to me to be a function of the
particular network protocol and, I guess, any desire for
"pretty-printedness".  If you're sending and XMLDSIG over MAIL then
there very well may be special formatting requirements imposed by SMTP,
but why make XMLDSIG abide by those specific restrictions for every
protocol over which it's transported?  We stream long, binary content
all the time in HTTP, of course, so I see no reason to force, e.g., an
XMLDSIG-signed SOAP message over HTTP to do extra formatting that is
only necessary if the same message is sent over SMTP.


-----Original Message-----
From: Martin Duerst [mailto:duerst@w3.org] 
Sent: Tuesday, May 22, 2001 5:47 PM
To: Brian LaMacchia; w3c-ietf-xmldsig@w3.org
Subject: Re: Base64 -- do we really want/need line breaks every 76

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:
>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
>    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 02:14:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:35 UTC