Subject: Re: SASL/GSSAPI proposed change of base32 alphabet

From: Simon Josefsson <[email-masked]>
Date: Tue, 2 Apr 2002 11:45:15 +0200 (CEST)

On Thu, 21 Mar 2002, John Myers wrote:

> I have been requested to replace the base32 specification in the 
> (expired) SASL GSSAPI internet draft with a reference section 3 of 
> draft-josefsson-base-encoding-03.txt.  This would mean a change in the 
> encoding alphabet, breaking any implementations of the existing draft 
> which use mechanisms other than Kerberos or SPNEGO.

Perhaps I am being dense here, but I do not see any incompatibility
between the description in my draft and draft-ietf-cat-sasl-gssapi-05.txt.  
In fact, I stole the base32 description from your draft, corrected a few
cut'n'paste errors in the text describing how encoding works and added an
alternative base32 alphabet that is being used in some other protocols.  

Naturally, it could be indicated in the SASL/GSSAPI document that the
"canonical" and not the alternative alphabet is to be used.

Can you elaborate on what the incompatibilities are?

---

From: [email-masked] (John Myers)
Date: Tue, 02 Apr 2002 16:07:46 -0800

> between the description in my draft and draft-ietf-cat-sasl-gssapi-05.txt.  

When I first scanned the document, it didn't occur to me that there 
would be two different definitions of base32 in it.  The current 
document is hard to reference because it defines two different 
encodings, naming them both "base32".  It doesn't even give the two 
encodings different section numbers.

Then there's a third base32 encoding, defined by 
draft-ietf-pkix-okid-01.txt.  This raises the question as to whether 
sasl-gssapi should switch to the pkix-okid alphabet, vice versa, or we 
should keep three different alphabets.  If we have three alphabets, I'm 
not sure of the value of defining one of them as being "canonical".

I would be much more comfortable with the Joseffson document if it only 
defined one alphabet for each encoding.  I also don't see the point of 
defining hexadecimal or a variant hexadecimal alphabet.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 3 Apr 2002 10:34:17 +0200 (CEST)

> encodings different section numbers.

The document give names to the alphabets, so making the reference to the
"Base32 with the canonical alphabet" should be sufficient.  The encoding 
is the same, only the alphabet differ.

> not sure of the value of defining one of them as being "canonical".

The only use of base32 in a IETF standards track document is in RFC 2938,
so I chosed that alphabet as the "canonical" one.

The description in RFC 2938 is not complete though (e.g., no padding), so
I doubt it can be used as reference for base32.  The RFC 2938 alphabet is
used by some IDN proposals as well, but other than that I haven't found
any major real world use of base32.  I have not seen the alphabet in
draft-ietf-pkix-okid-01.txt before.

> defined one alphabet for each encoding.

I'd rather drop the "Extended hex" version as well, but it seems to be in
use.  Right now, I'm not sure if the base encoding document should
document current practice or suggest best future practices.  For Base64
both alphabets have useful and distinct properties, and warrant inclusion.  
For base32, which isn't commonly used, perhaps it is not as clear.

Regards, Simon

---

From: [email-masked] (John Myers)
Date: Thu, 04 Apr 2002 15:58:07 -0800

> is the same, only the alphabet differ.

If the alphabets differ then the encodings are not the same.

Names that require qualification are awkward and invite ambiguous 
references.  The term "Base64" refers to the encoding and alphabet 
defined in MIME.  If an encoding uses a different alphabet, then that is 
a variant of base64 and needs to go by a different name.

> so I chosed that alphabet as the "canonical" one.

The -03 version of your document uses the sasl-gssapi alpahabet as the 
"canonical" one.  The RFC 2938 alphabet is given the name "Extended Hex".

> For base32, which isn't commonly used, perhaps it is not as clear.

I don't see any references in the document to uses of the "Canonical 
Base 16" alphabet.  I have strenuous objections to inventing a new 
variant of hex.

The request I've received is to make the sasl-gssapi document have a 
normative reference to the base-encoding document.  The current state of 
the base-encoding document does not make me comfortable about adding a 
dependency on it.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 22 Apr 2002 17:15:56 +0200

I now have an updated base encoding document based on comments below,
and from Chris Newman and others, changes relevant here include:

- Alternative alphabets moved to separate section.
- Alternative alphabets marked as not being the same as the original
  ones.
- Canonical base16 dropped.

I am considering dropping the RFC 2938 compatible Base32 version as
well, in favor of only the SASL-GSSAPI alphabet.  It might send a
mixed message having two different base32 alphabets defined in RFCs,
but RFC 2938 seem to be for a limited audience and does not describe a
general base32 encoding.  The SASL-GSSAPI alphabet also seems better.
The SASL-GSSAPI alphabet was compatible with draft-ietf-pkix-okid-00,
but not draft-ietf-pkix-pkid-01 which isn't compatible with RFC 2938
either.  I don't remember the situation for the various IDN proposals
completely (there seem to be many and I'm not sure which are valid),
but I believe they either used the RFC 2938 alphabet or (more
commonly) the SASL-GSSAPI alphabet.  I think it would be nice to go
for the SASL-GSSAPI alphabet everywhere.

I'll submit this to the I-D editor within a week or so unless someone
has comments.

Thanks.

[email-masked] (John Myers) writes:

>> "Base32 with the canonical alphabet" should be sufficient.  The
>> encoding is the same, only the alphabet differ.
>
> defined in MIME.  If an encoding uses a different alphabet, then that
> is a variant of base64 and needs to go by a different name.
>
>> both alphabets have useful and distinct properties, and warrant
>> inclusion.  For base32, which isn't commonly used, perhaps it is not
>> as clear.
>
> normative reference to the base-encoding document.  The current state
> of the base-encoding document does not make me comfortable about
> adding a dependency on it.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 2 Apr 2002 11:45:15 +0200 (CEST)

---

From: [email-masked] (John Myers)
Date: Tue, 02 Apr 2002 16:07:46 -0800

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 3 Apr 2002 10:34:17 +0200 (CEST)

Regards, Simon

---

From: [email-masked] (John Myers)
Date: Thu, 04 Apr 2002 15:58:07 -0800

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 22 Apr 2002 17:15:56 +0200

Thanks.