- From: Jeffrey Walton <noloader@gmail.com>
- Date: Thu, 15 Jan 2015 00:33:24 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jan 14, 2015 at 10:42 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 14 January 2015 at 17:37, Brian Smith <brian@briansmith.org> wrote: >>> "The digest value MUST be encoded using the base64url >>> >>> [RFC4648] encoding, with no "=" padding characters." >> >> The specification shouldn't forbid the "=" padding characters. The >> fact that the draft specification has included the padding multiple >> times is good evidence that authors are going to include the padding >> too. It is trivial for an implementation to strip the padding. The >> specification should be changed to allow the padding and to require >> implementations to strip it. This would make the spec more "webby" and >> author-friendly. > > I know a lot of base64 libs accept the '+/' and '-_' variants > interchangeably as well. Is that something that should be accepted or > not? Those are different standards. For example, accepting '+/' is from DUDE and it expired in 2007 (https://tools.ietf.org/html/draft-ietf-idn-dude-02). It seems to be very popular though. For example, it used in email and its the default Crypto++ encoder for Base64.
Received on Thursday, 15 January 2015 05:33:51 UTC