Subject: RE: sasl-gssapi questions: base32 and context flags

From: "John Brezak" <[email-masked]>
Date: Thu, 7 Jun 2001 12:52:27 -0700

Thanx for pointing out the limit.

So the base32 is to avoid the need for a registration authority? It
still seems that this base32 encoding is over-kill to avoid the use of
names. Keeping the names at least makes it consistent with the other
authentication mechanism names. Why not just register the GSSAPI
mechtype names with IANA (like the other SASL names)?

Maybe define a different type like "GSS-OID" and put the full OID after
the name section.

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Monday, June 04, 2001 7:34 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: sasl-gssapi questions: base32 and context flags
> 
> 
> John Brezak wrote:
> 
> > Is the base32 encoding method used for anything other than the 10 
> > bytes used in the suffix for the gssapi mechanism encoding? 
> If so why 
> > go through all of this complexity - why not just use the 
> text version 
> > of the OID for the mechtype?
> 
> IMHO, there are two reasons:
> 
> 1). Allowed characters for mechanism name are uppercase 
> letters, digits, "-" and "_" (thus "." is not allowed) 2). 
> There is a limit of 20 characters for mechanism name. Having 
> prefix "GSS-" this leaves 16 characters.
> 
> __________________________________________
> Alexey Melnikov
> R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
> phone 780.424.4922 x357
> 
> I speak for myself only, not for my employer. 
> __________________________________________
> 
> 
>

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 18 Jun 2001 15:03:28 -0700

John Brezak wrote:
> So the base32 is to avoid the need for a registration authority?

The base32-MD5 is to use the existing GSS mechanism registrations.

> It

Then it would not be possible to implement GSS mechanisms under SASL
using only the GSS API.  With the current draft, it is possible to write
generic GSS/SASL mechanism glue code, querying the GSS API for available
mechanism OIDs and algorithmically generating a list of corresponding
SASL mechanisms names from that.  Once such glue code is written, any
GSS mechanism later installed into the GSS API will automatically be
available through SASL.

With a separate SASL GSS mechtype registry, such glue code would have to
have a table mapping OIDs of known GSS mechanisms to SASL mechanism
names.  A newly installed GSS mechanism could not be made available
through SASL until it had its SASL mechanism name installed into the
SASL glue code's table.

> Maybe define a different type like "GSS-OID" and put the full OID after

After the name section?  Which field are you talking about?

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 18 Jun 2001 15:03:28 -0700