- From: Michael McIntosh <michaelm@valicert.com>
- Date: Wed, 23 May 2001 09:11:37 -0700
- To: "'John Boyer'" <JBoyer@PureEdge.com>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, w3c-ietf-xmldsig@w3.org
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:14:09 UTC