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.

See <http://josefsson.org/base-encoding/> for more information.

Table of Contents

1.  Introduction
2.  Summary
3.  Methodology
4.  Exceptions
5.  Implementations Tested
    5.1.  GNU Coreutils: base64
6.  Acknowledgements
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address

1.  Introduction

This is an implementation report of The Base16, Base32, and Base64 Data Encodings (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648] document. It follows the outline suggested by [I‑D.dusseault‑impl‑reports] (Dusseault, L. and R. Sparks, “Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard,” July 2009.).

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] (Linn, J. and IAB Privacy Task Force, “Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures,” February 1987.). It has been widely implemented as part of MIME [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.), 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] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.). The "base32hex" encoding is used by [RFC5155] (Laurie, B., Sisson, G., Arends, R., and D. Blacka, “DNS Security (DNSSEC) Hashed Authenticated Denial of Existence,” March 2008.), and a restricted form is used by [RFC2938] (Klyne, G. and L. Masinter, “Identifying Composite Media Features,” September 2000.).

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.

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] (Josefsson, S., “GNU Coreutils "base64" tool version 7.2,” May 2009.). 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

9.1. Normative References

9.2. Informative References

Author's Address