base32 alphabet rant - rhaaaaa rfc3548

[Roy Arends <roy@dnss.ec>]

There exist multiple base32 alphabets. The two mostly used are
"A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938).

The problem with "A-Z2-7" is that the sort order of a set of binary values
is different than the sort order of its base32 equivalent in ascii order.

As an example, it is obvious that 1091 is lower than 26624. However, if
one would sort the base32 representations in ascii order (1091="BCD" and
26624= "2AA") then 2AA is lower than BCD.

In NSEC3, owner names contain base32 encodings of binary hash values,
while the 'next hashed owner name' contains a binary hash value.  After
adding NSEC3 and before signing, the set of NSEC3s is sorted in 'canonical
order'. When a validating resolver validates (for instance) an NXDOMAIN
response, it compares the hashed QNAME with the two values in the NSEC3
record. In all these things, order is important.

To end this ordering problem, we're not going to use the base32 alphabet
"A-Z2-7" explained in rfc3548, but use the "0-9A-V" alphabet that is
explained in for instance rfc2938.

Note that rfc3548 is informational, and that it refers to the origin of
this base32 alphabet on a work in progress. However, this work in progress
does not mention any base32 encoding. RFC3548 also refers to rfc2938, but
this rfc is using the "0-9A-V" alphabet.

I'll prolly add a section on this base "0-9A-V" alphabet. Something I
hoped wasn't necessary, but since the sort order is screwed, I have to.

Roy

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>