The Base16, Base32, and Base64 Data Encodings
draft-josefsson-rfc3548bis-04

[Ballot discuss]
From the top:

  Copyright Notice

  Copyright (C) The Internet Society (2006).

From the end:

  15.  Copying Conditions

  Copyright (c) 2000-2006 Simon Josefsson

  Regarding the abstract and section 1, 3, 8, 10, 12, 13, and 14 of
  this document, that were written by Simon Josefsson ... (snip) ...

I understand that code embedded with an RFC may have its
own license, but the above appears to give two conflicting
copyright statements about the actual text. It may be
that we have a procedure that allows this, but I have
not seen this before.

(Ongoing discussion in the IESG on whether current rules allow
this or not. Sam to contact Simon about it.)

[Ballot discuss]
From the top:

  Copyright Notice

  Copyright (C) The Internet Society (2006).

From the end:

  15.  Copying Conditions

  Copyright (c) 2000-2006 Simon Josefsson

  Regarding the abstract and section 1, 3, 8, 10, 12, 13, and 14 of
  this document, that were written by Simon Josefsson ... (snip) ...

I understand that code embedded with an RFC may have its
own license, but the above appears to give two conflicting
copyright statements about the actual text. It may be
that we have a procedure that allows this, but I have
not seen this before.

[Ballot comment]
Is it wise to have a character from the "reserved" [sub-delims] production
in the "URL safe" base64 alphabet (=)?  The only remaining "unreserved"
characters are ~ (already addressed) and ".", which could have its own
problems wrt "filename-safe".

[I ask because I saw a brief discussion go by from two people discussing
base64-encoded data in URLs and they were explicitly talking about
needing to percent-encode the "=" and they decided to instead discard
the padding and make the padding implicit.  RFC 1738 does imply that
"=" has to be encoded unless it's being used for a scheme-specific
purpose; RFC 3986 is more clear on this point but helper libraries
etc. are likely to be based on the older document.]

[Ballot comment]
I made several comments on this draft in IETF LC and I was pleased (and frankly, surprised) to see they were all addressed very nicely. Thank you.

[Ballot comment]
It seems that when padding is required, that multiple encodings are
possible.  For example, if the input is only one octet for a base 64
encoding, then all six bits of the first symbol are used, but only the
first two bits of the next symbol are used.  Many decoders would
presumably work with this case.  One consequence of this is that there
is not a canonical encoding.  That is, multiple base64 inputs decode
to the same value.  That's significant from a security standpoint.
I'd appreciate it if this document could mandate encoders produce a
canonical encoding (even if it cannot mandate decoders reject
non-canonical encodings) and discuss the security implications.

[Ballot discuss]
Section 3.1 says that implementations must not add line feeds but does
not describe what receivers should do.  Section 3.2 and 3.3 does
describe behavior of decoders.  If there is a good reason to leave
this unspecified I will remove the discuss.

[Ballot comment]
The author has agreed with Russ's point.  An RFC Editor note adding a reference to the LGPL is
pending other review, to see if other RFC Editor notes/revisions are needed.

[Ballot discuss]
Reported by Tero Kivinen in his SecDir Review.

  The document itself includes a C-source code of the Base64 encoding
  and decoding functions and that source code is released under GNU
  Lesser  General Public License (LGPL).  The LGPL boilerplate mentions
  that the actual copy of the GNU Lesser General Public License should
  be received along the program, but it is not included in the document.
  (and there is no reference to it in the references section).