Subject: rfc2222bis comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jun 2003 18:18:49 -0700

I have a few technical comments for the WG to consider.
(I also have a number of editorial comments which I send
directly to the editor.)

I suggest we change the 20 character maximum length to a
higher number so that OIDs can be more easily used as mechanism
names.  I don't think this will break anyone... and it will make
GSS API mechanism specification much easier.

The "authorization identity" should clearly be described as an
an optional proxy authorization identity.  Empty and no strings
are semantically equivalent. Mechanisms should not allow both
empty and no string to be transferred (we've had interop problems
with DIGEST-MD5 and EXTERNAL because implementations didn't always
treat them as being the same).  Also, replace "entire repertoire
of Unicode Normalization form KC [UNICODE-NORMALIZATION]" with
"entire Unicode repertoire".  Also, use same repertoire here
in first paragraph of 4.2.

The last paragraph of 4.2 needs some word-smithing.

The wording of this section 5 paragraph is problematic.
>   A protocol profile MAY further refine the definition of an         
>   authorization identity by adding additional syntactic restrictions
>   and protocol-specific semantics.

Profiles MUST specify the form of the authorization identity
well as how authorization identities are to be compared.  It
may be appropriate to encourage use of simple user names here
(and, hence, SASLprep).

More later....

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 6 Jun 2003 18:35:39 -0700 (PDT)

On Fri, 6 Jun 2003, Kurt D. Zeilenga wrote:

> I suggest we change the 20 character maximum length to a higher number
> so that OIDs can be more easily used as mechanism names.  I don't think
> this will break anyone... and it will make GSS API mechanism
> specification much easier.

Eh ... it will break all those implementations that allocate a 20-char
buffer for a mech-name, won't it?

> optional proxy authorization identity.

I disagree.  Proxy is only one example of the utility of authz-id.  A
system might permit my authenticated user credential to assume several
roles, letting me specify the role via authz-id.

Your other points I agree with ... 8^)

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jun 2003 18:45:13 -0700

>buffer for a mech-name, won't it?

 From an informal poll showed sizeof("all those implementations") == 0.
If the sizeof > 0, then I'd retract the suggestion.  Is it?

>roles, letting me specify the role via authz-id.

Okay.  I was trying to figure out how to stress even more (than
the SHOULD NOT derive statement) that clients should not specify
an authzid unless the user provided one with the credentials.

Kurt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 6 Jun 2003 19:54:06 -0600

> GSS API mechanism specification much easier.

This will break any existing implementation that uses a fixed 20 octet 
array to store the mechanism name.

--lyndon

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 6 Jun 2003 20:12:14 -0600

> If the sizeof > 0, then I'd retract the suggestion.  Is it?

There is no way of knowing. You cannot possibly enumerate every 
instance of SASL that has been deployed. Therefore "20" is a constant 
until the end of time.

--lyndon

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 6 Jun 2003 23:55:35 -0400

Date: Fri, 6 Jun 2003 20:12:14 -0600
   From: Lyndon Nerenberg <[email-masked]>

I agree with Lyndon. I see no compelling reason why this should be
lifted.

Larry

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 6 Jun 2003 18:35:39 -0700 (PDT)

- RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jun 2003 18:45:13 -0700

Kurt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 6 Jun 2003 19:54:06 -0600

--lyndon

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 6 Jun 2003 20:12:14 -0600

--lyndon

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 6 Jun 2003 23:55:35 -0400

Larry