Subject: RE: Last Call - Kerberos Cryptosystem Negotiation Extension

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 14 Jul 2005 18:09:44 -0700

Ken, I propose the following as a clarification on the list order.

Section 3, last paragraph:

OLD

  The policy by which the client or the server chooses an enctype
   (i.e., how the preference order for the supported enctypes is
   selected) is an implementation-specific local matter.

REPLACE with:

   The server MAY ignore the order indicated by the client. The policy
by 
   which the client or the server chooses an enctype (i.e., how the 
   preference order for the supported enctypes is selected) is a local 
   matter.

Would this be acceptable?

Thanks,

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Thursday, July 14, 2005 5:02 PM
To: Liqiang(Larry) Zhu; Ken Raeburn
Cc: [email-masked]
Subject: RE: Last Call - Kerberos Cryptosystem Negotiation Extension

On Thursday, July 14, 2005 03:26:19 PM -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> Ken Raeburn wrote:
>
>> [CLAR] and [GSS-CFX] references should be updated to the proper RFC
>> numbers.  (They've been assigned, though not published.  The less
work
>
>> we make for the RFC editor, the better.)
>
> Ok

They're RFC4120 and RFC4121, respectively, and were published today.

>> Probably should have an Updates: header.  It's updating the enctype
>> choice specification, and the ad-type table, in Clarifications.
>
> Ok, I have no problem to do that, Jeff (jhutz)?

If it were just registering a new ad-type, I wouldn't call it an
"update". 
But it does change the semantics of the protocol, so I agree an updates 
header is appropriate.

>> Section 3, first paragraph.  I think it should be a SHOULD or MAY,
not
>
>
>> a MUST.  (That's kind of fuzzy.  Can we assert that there will be no
>> circumstances under which the client implementation might prefer
other
>> enctypes but for other reasons chooses not to include the
>
>> AD-ETYPE-NEGOTIATION element?  Or is that rolled up in the definition
>> of "prefer", which we never really get into?)
>
> Is it ok to just remove the "MUST"?

I think it probably is - you can just say something like "... the client

sends ..."

>> In fact, while the list is sent in preference order, this spec
doesn't
>> suggest that the server should pay attention to the order.  True, it
>> could be buried in the "implementation-specific policy" clause, and
> the
>> policy may be "ignore the client's preferences, pick what the server
>> thinks is the best of the types the client supports", but there isn't
>> even a hint of a recommendation.  I think a suggestion that the
server
>
>> MAY heed (or MAY ignore) the order indicated by the client might be a
>> good idea.
>
> If the client sends an encrypte as the first item in the list, but
this
> enctype is considered too week or not supported by the server, the
> server should be allowed to skip it, right?
>
> I can add text.

IHMO, either the server should use the first thing in the client's list 
that is supported and that it considers "good enough", or we should
specify 
that the client's list order is irrelevant and the server uses its own 
preference order.

>> When did "leverage" become a verb?
> Not sure when, but it is a verb according to " The American
Heritage(r)
> Dictionary of the English Language: Fourth Edition.  2000."
> http://www.bartleby.com/61/84/L0138400.html

It's been a verb for some time; it's only recently that it seems to be 
becoming more mainstream.  Either that or we're all turning into 
pointy-haired managers.

-- Jeff