Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Informational May 28, 2009 Expires: November 29, 2009 RFC 4648 Implementation Report draft-josefsson-rfc4648-impl-report-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 29, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This is an implementation report of RFC4648, for the purpose of advancing the document to Draft Standard. Josefsson Expires November 29, 2009 [Page 1] Internet-Draft RFC 4648 Implementation Report May 2009 See for more information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Implementations Tested . . . . . . . . . . . . . . . . . . . . 4 5.1. GNU Coreutils: base64 . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Josefsson Expires November 29, 2009 [Page 2] Internet-Draft RFC 4648 Implementation Report May 2009 1. Introduction This is an implementation report of The Base16, Base32, and Base64 Data Encodings [RFC4648] document. It follows the outline suggested by [I-D.dusseault-impl-reports]. 2. Summary The "base64" encoding have a long history of being used in Internet protocols, the earliest use in the RFC series appears to be [RFC0989]. It has been widely implemented as part of MIME [RFC2045], which is already a Draft Standard. The "base64url" alphabet does not appear to be widely deployed. The "base32" encoding is not as widely used as base64, but has applications in the case insensitive systems. The "base32" encoding is used by [I-D.ietf-sasl-gs2]. The "base32hex" encoding is used by [RFC5155], and a restricted form is used by [RFC2938]. The "base16" encoding is usually referred to as hexadecimal, or hex encoding, and is used in many protocols and informally in technical documents. 3. Methodology We identified that we wanted to test the following encodings: base64, base64url, base32, base32hex, base16. The primary test is of course that basic encoding and decoding works and lead to expected results. Section 3 of RFC 4648 discuss some implementation discrepancies of base encoding. To possibly find interoperability problems, we checked and documented these corner-cases separately. In particular: how line feeds are handled during encoding and decoding [LF], whether padding is done correctly [PAD], how non-alphabetical characters are handled [NONALPHA], whether pad bits are zero or not [ZEROBITS]. A useful test case whether pad bit handling is appropriate is "YR==" which is a non-canonical encoding of "a" (ASCII 0x61) that normally is encoded as "YQ==". 4. Exceptions Encoding and decoding of data interoperate well. Josefsson Expires November 29, 2009 [Page 3] Internet-Draft RFC 4648 Implementation Report May 2009 Some tools accepted non-canonical encodings, but none appeared to ever generate them. This is consistent with the requirements in section 3.5 of RFC 4648. We acknowledge that many implementations of base64 were written for a general purpose, and thus may not follow some of the guidelines (e.g., related to line feeds) in RFC 4648 strictly. However we believe this should not be a reason against Draft Standard status because the document is clear on the issues and the minor variations does not appear to lead to any problem. 5. Implementations Tested 5.1. GNU Coreutils: base64 There is a "base64" command line tool, written in C, included in GNU Coreutils [GNU-Coreutils-Base64]. It supports the "base64" alphabet. [LF]: On encoding, it wraps output after 76 characters (same as MIME). On decoding, it accepts line-wrapped input. [PAD]: It appears to pad data properly. [NONALPHA]: It appears to return a non-zero error code if the input contains non-alphabetical characters. [ZEROBITS]: On encoding, the pad bits are zero. On decoding, it appears to accept non-zero pad bits. 6. Acknowledgements TBA 7. Security Considerations See RFC 4648 for security considerations. 8. IANA Considerations This document has no actions for IANA. 9. References Josefsson Expires November 29, 2009 [Page 4] Internet-Draft RFC 4648 Implementation Report May 2009 9.1. Normative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. 9.2. Informative References [I-D.dusseault-impl-reports] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports", draft-dusseault-impl-reports-02 (work in progress), May 2009. [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 989, February 1987. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2938] Klyne, G. and L. Masinter, "Identifying Composite Media Features", RFC 2938, September 2000. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [I-D.ietf-sasl-gs2] Josefsson, S. and N. Williams, "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-13 (work in progress), May 2009. [GNU-Coreutils-Base64] Josefsson, S., "GNU Coreutils "base64" tool version 7.2", WWW http://www.gnu.org/software/coreutils/, May 2009. Author's Address Simon Josefsson SJD AB Email: simon@josefsson.org Josefsson Expires November 29, 2009 [Page 5]