The Base16, Base32, and Base64 Data Encodings
draft-josefsson-rfc3548bis-04
Yes
(Lisa Dusseault)
No Objection
(Brian Carpenter)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
Note: This ballot was opened for revision 04 and is now closed.
Cullen Jennings Former IESG member
(was No Record, Yes)
Yes
Yes
(2006-05-09)
Unknown
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.
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Ted Hardie Former IESG member
Yes
Yes
(2006-05-09)
Unknown
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.
Bill Fenner Former IESG member
No Objection
No Objection
(2006-05-10)
Unknown
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.]
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
(2006-05-09)
Unknown
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.