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

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 Tuesday, 22 May 2001 20:32:27 UTC