Last Call - Kerberos Cryptosystem Negotiation Extension

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Last Call - Kerberos Cryptosystem Negotiation Extension

Jeffrey Hutzelman
I am beginning a Last Call on this document, which will expire at the close
of business (EDT) on June 15, 2005.


        Title : Kerberos Cryptosystem Negotiation Extension
        Author(s) : L. Zhu, et al.
        Filename : draft-zhu-kerb-enctype-nego-02.txt
        Pages : 7
        Date : 2005-5-27
       
This document specifies an extension by Kerberos to negotiate new
encryption types between the client-server peers.




-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: Last Call - Kerberos Cryptosystem Negotiation Extension

Jeffrey Hutzelman


On Wednesday, June 01, 2005 01:06:31 PM -0400 Jeffrey Hutzelman
<[hidden email]> wrote:

> I am beginning a Last Call on this document, which will expire at the
> close of business (EDT) on June 15, 2005.
>
>
> Title : Kerberos Cryptosystem Negotiation Extension
> Author(s) : L. Zhu, et al.
> Filename : draft-zhu-kerb-enctype-nego-02.txt
> Pages : 7
> Date : 2005-5-27
>
> This document specifies an extension by Kerberos to negotiate new
> encryption types between the client-server peers.



There have been NO COMMENTS in response to this.  I can't send this on to
the IESG when it does not appear to have had any review at all.  This is a
really short document, and does not take long to read and understand.
Please, let's see some comments on this.

-- Jeff



Reply | Threaded
Open this post in threaded view
|

Re: Last Call - Kerberos Cryptosystem Negotiation Extension

Kenneth G Raeburn
On Jul 11, 2005, at 23:00, Jeffrey Hutzelman wrote:
> There have been NO COMMENTS in response to this.  I can't send this on
> to the IESG when it does not appear to have had any review at all.  
> This is a really short document, and does not take long to read and
> understand. Please, let's see some comments on this.

Oops, I meant to look at this some time ago.  Okay, here goes.  
Apologies if I've forgotten some previous discussion on technical
points.

[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.)

Probably should have an Updates: header.  It's updating the enctype
choice specification, and the ad-type table, in Clarifications.

The introduction should define the term "enctype" before using it.  
Should be sufficient to say something like:  "...KDC must limit the
ticket session key encryption type (enctype)...."

Abstract: "extension to Kerberos" or "extension to the Kerberos
protocol" or "extension of...", not "extension by Kerberos".  Might
expand on the text just a wee bit; one brief sentence doesn't seems
like enough.

Section 3, second paragraph.  What's "(129)"?  (Yes, *I* know, but the
text doesn't explain it.)

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?)

In general: See RFC 2119, section 6.  I think our requirements language
is too strong overall.

Page 4, third paragraph.  Does "SHOULD consider using" make sense here?
  Shouldn't it be "SHOULD use"?

"Preserve the quality of randomness provided by the KDC...."  How
about, "to take advantage of"?  And why do we want to do that, by the
way?  Do we have a reference suggesting a way to do it safely, given
that we're talking about the session key type possibly being weak?  If
no reference, at least we should recommend caution in the approach
chosen, in the Security Considerations section.  (E.g., if it's used
directly, or used to encrypt some predictable data to get a key, it may
provide additional fodder for cryptanalysis.  It should be used in
combination with, not in place of, other randomness sources.)

Section 3, first paragraph.  The client must send a list of all
enctypes it supports.  Doesn't this give the application server the
opportunity to choose an enctype *later* in the preference list than
the KDC-provided session key type?  The client might be better off (in
its own estimation, if we continue anthropomorphizing our software) not
invoking this extension at all, in that case.  Perhaps it should (MAY?)
omit types that it likes less well than the session key type.  If they
are omitted, do we need to include the session key enctype in the list?

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.

And why "an implementation-specific local matter" -- are we suggesting
that the implementation SHOULD allow local configuration?  That would
be fine by me, but if so, I think we should say it separately;
"implementation-specific local" seems a little contradictory to me,
like the implementation dictates the policy, but wait, no, it should be
specified locally.

Page 4, first paragraph, "...it MUST be used for subsequent
communication".  What if the application protocol does something odd,
like negotiates a subkey for some purpose other than direct
communication, but uses the session key for communication?  This spec
as worded isn't compatible with such a protocol, at least not in a way
that keeps the extension transparent to the application.  The AP-REP
subkey of the negotiated enctype should be used, well, however your
application protocol says to use the AP-REP subkey.  Maybe it's for
encrypting data; maybe it's for randomizing the deck in your Kerberized
Solitaire game.

Page 4, second paragraph, "MUST NOT be used when the client does not
expect the subkey in the AP-REP message".  How about "SHOULD NOT", or
"MAY omit..."?  This requirement means that in, oh, one "typical"
implementation, the library on the client side will have to be informed
whether the server is expected to send a subkey, rather than doing the
exchange and then letting the application look and see if one was
provided.  (Consider also a protocol where the subkey is used if
provided, and the server chooses whether to provide it, but in the most
common case -- perhaps determined by implementation issues -- the
server does not.  The client could then be said not to expect to
receive a subkey; must it then not send the list?)  It might be
desirable sometimes (keeps messages shorter), but do we want to require
it?

Section 3, paragraph 2, "[X60]" should be "[X690]".

When did "leverage" become a verb?  What does it mean in the title of
appendix A, and is there a non-ManagerSpeak word that could be used
instead?  Remember, this is for engineers, not managers or marketers.  
(Yes, one of the online dictionaries I checked did list it as a verb as
well as a noun.  However, the definitions I ran across didn't seem to
work here.)

Appendix A can be reduced to a few sentences.  (W2K/XP/2K3 SPNEGO has a
bug, it's got security impact, it's been fixed, but for backward
compatibility the fix is turned off unless....  And what's this "SSPI"
thing anyways? :)  I don't think it's even particularly important to
this document; at best, if it's kept in this document, it should be
explicitly marked as informative, not normative.  But I think it should
probably go.  Maybe get published separately as an informative RFC, if
you want to discuss Microsoft GSSAPI/Kerberos interoperability issues
in general.

That's everything I've come up with in the last few hours.  Sorry I
didn't get to this sooner... :-(

Ken



Reply | Threaded
Open this post in threaded view
|

Re: Last Call - Kerberos Cryptosystem Negotiation Extension

hartmans
>>>>> "Ken" == Ken Raeburn <[hidden email]> writes:

    Ken> "Preserve the quality of randomness provided by the KDC...."
    Ken> How about, "to take advantage of"?  And why do we want to do
    Ken> that, by the way?  Do we have a reference suggesting a way to
    Ken> do it safely, given that we're talking about the session key
    Ken> type possibly being weak?  If no reference, at least we
    Ken> should recommend caution in the approach chosen, in the
    Ken> Security Considerations section.  (E.g., if it's used
    Ken> directly, or used to encrypt some predictable data to get a
    Ken> key, it may provide additional fodder for cryptanalysis.  It
    Ken> should be used in combination with, not in place of, other
    Ken> randomness sources.)

Jeff Schiller tends to be the root source of all the recommendations
about reusing KDC entropy.  I tend to agree with his reason.  You know
the KDC has a strong PRNG (or at least you know you're in big trouble
if not).

As such, you want to reuse your KDC key data when generating keys.

We could take the combine keys function from Ken's SAM draft as an
example of how to do this.

--Sam



Reply | Threaded
Open this post in threaded view
|

Re: Last Call - Kerberos Cryptosystem Negotiation Extension

Kenneth G Raeburn
On Jul 12, 2005, at 17:22, Sam Hartman wrote:
> Jeff Schiller tends to be the root source of all the recommendations
> about reusing KDC entropy.  I tend to agree with his reason.  You know
> the KDC has a strong PRNG (or at least you know you're in big trouble
> if not).
> As such, you want to reuse your KDC key data when generating keys.

Yes, I know and agree with his argument.  I meant to imply that the
draft should've answered the question.

> We could take the combine keys function from Ken's SAM draft as an
> example of how to do this.

(Which draft has expired.)

I just took a look, it looks good to me.  Appendix A, that is, using
the PRF.

Ken



Reply | Threaded
Open this post in threaded view
|

RE: Last Call - Kerberos Cryptosystem Negotiation Extension

Larry Zhu
In reply to this post by Jeffrey Hutzelman
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

> 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)?


> The introduction should define the term "enctype" before using it.  

> Should be sufficient to say something like:  "...KDC must limit the
> ticket session key encryption type (enctype)...."

Sounds good

>Section 3, second paragraph.  What's "(129)"?  (Yes, *I* know, but the
> text doesn't explain it.)

I can add one


> Abstract: "extension to Kerberos" or "extension to the Kerberos
> protocol" or "extension of...", not "extension by Kerberos".  Might
> expand on the text just a wee bit; one brief sentence doesn't seems
> like enough.

Fair enough


> 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"?

>Page 4, third paragraph.  Does "SHOULD consider using" make sense here?

>   Shouldn't it be "SHOULD use"?

Good


> "Preserve the quality of randomness provided by the KDC...."  How

> about, "to take advantage of"?  And why do we want to do that, by the
> way?  Do we have a reference suggesting a way to do it safely, given
> that we're talking about the session key type possibly being weak?  If

> no reference, at least we should recommend caution in the approach
> chosen, in the Security Considerations section.  (E.g., if it's used
> directly, or used to encrypt some predictable data to get a key, it
may
> provide additional fodder for cryptanalysis.  It should be used in
> combination with, not in place of, other randomness sources.)

I can add more text.


> Section 3, paragraph 2, "[X60]" should be "[X690]".

Ok

> 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.


> Page 4, second paragraph, "MUST NOT be used when the client does not
> expect the subkey in the AP-REP message".  How about "SHOULD NOT",

Fine with me

> 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

> Appendix A can be reduced to a few sentences.  ... But I think it
should
> probably go.  

Sure, I can remove this appendix.




-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Ken Raeburn
Sent: Tuesday, July 12, 2005 2:43 AM
To: Jeffrey Hutzelman
Cc: [hidden email]
Subject: Re: Last Call - Kerberos Cryptosystem Negotiation Extension

On Jul 11, 2005, at 23:00, Jeffrey Hutzelman wrote:
> There have been NO COMMENTS in response to this.  I can't send this on

> to the IESG when it does not appear to have had any review at all.  
> This is a really short document, and does not take long to read and
> understand. Please, let's see some comments on this.

Oops, I meant to look at this some time ago.  Okay, here goes.  
Apologies if I've forgotten some previous discussion on technical
points.

[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.)

Probably should have an Updates: header.  It's updating the enctype
choice specification, and the ad-type table, in Clarifications.

The introduction should define the term "enctype" before using it.  
Should be sufficient to say something like:  "...KDC must limit the
ticket session key encryption type (enctype)...."

Abstract: "extension to Kerberos" or "extension to the Kerberos
protocol" or "extension of...", not "extension by Kerberos".  Might
expand on the text just a wee bit; one brief sentence doesn't seems
like enough.

Section 3, second paragraph.  What's "(129)"?  (Yes, *I* know, but the
text doesn't explain it.)

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?)

In general: See RFC 2119, section 6.  I think our requirements language
is too strong overall.

Page 4, third paragraph.  Does "SHOULD consider using" make sense here?
  Shouldn't it be "SHOULD use"?

"Preserve the quality of randomness provided by the KDC...."  How
about, "to take advantage of"?  And why do we want to do that, by the
way?  Do we have a reference suggesting a way to do it safely, given
that we're talking about the session key type possibly being weak?  If
no reference, at least we should recommend caution in the approach
chosen, in the Security Considerations section.  (E.g., if it's used
directly, or used to encrypt some predictable data to get a key, it may
provide additional fodder for cryptanalysis.  It should be used in
combination with, not in place of, other randomness sources.)

Section 3, first paragraph.  The client must send a list of all
enctypes it supports.  Doesn't this give the application server the
opportunity to choose an enctype *later* in the preference list than
the KDC-provided session key type?  The client might be better off (in
its own estimation, if we continue anthropomorphizing our software) not
invoking this extension at all, in that case.  Perhaps it should (MAY?)
omit types that it likes less well than the session key type.  If they
are omitted, do we need to include the session key enctype in the list?

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.

And why "an implementation-specific local matter" -- are we suggesting
that the implementation SHOULD allow local configuration?  That would
be fine by me, but if so, I think we should say it separately;
"implementation-specific local" seems a little contradictory to me,
like the implementation dictates the policy, but wait, no, it should be
specified locally.

Page 4, first paragraph, "...it MUST be used for subsequent
communication".  What if the application protocol does something odd,
like negotiates a subkey for some purpose other than direct
communication, but uses the session key for communication?  This spec
as worded isn't compatible with such a protocol, at least not in a way
that keeps the extension transparent to the application.  The AP-REP
subkey of the negotiated enctype should be used, well, however your
application protocol says to use the AP-REP subkey.  Maybe it's for
encrypting data; maybe it's for randomizing the deck in your Kerberized
Solitaire game.

Page 4, second paragraph, "MUST NOT be used when the client does not
expect the subkey in the AP-REP message".  How about "SHOULD NOT", or
"MAY omit..."?  This requirement means that in, oh, one "typical"
implementation, the library on the client side will have to be informed
whether the server is expected to send a subkey, rather than doing the
exchange and then letting the application look and see if one was
provided.  (Consider also a protocol where the subkey is used if
provided, and the server chooses whether to provide it, but in the most
common case -- perhaps determined by implementation issues -- the
server does not.  The client could then be said not to expect to
receive a subkey; must it then not send the list?)  It might be
desirable sometimes (keeps messages shorter), but do we want to require
it?

Section 3, paragraph 2, "[X60]" should be "[X690]".

When did "leverage" become a verb?  What does it mean in the title of
appendix A, and is there a non-ManagerSpeak word that could be used
instead?  Remember, this is for engineers, not managers or marketers.  
(Yes, one of the online dictionaries I checked did list it as a verb as
well as a noun.  However, the definitions I ran across didn't seem to
work here.)

Appendix A can be reduced to a few sentences.  (W2K/XP/2K3 SPNEGO has a
bug, it's got security impact, it's been fixed, but for backward
compatibility the fix is turned off unless....  And what's this "SSPI"
thing anyways? :)  I don't think it's even particularly important to
this document; at best, if it's kept in this document, it should be
explicitly marked as informative, not normative.  But I think it should
probably go.  Maybe get published separately as an informative RFC, if
you want to discuss Microsoft GSSAPI/Kerberos interoperability issues
in general.

That's everything I've come up with in the last few hours.  Sorry I
didn't get to this sooner... :-(

Ken





Reply | Threaded
Open this post in threaded view
|

RE: Last Call - Kerberos Cryptosystem Negotiation Extension

Jeffrey Hutzelman


On Thursday, July 14, 2005 03:26:19 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

RE: Last Call - Kerberos Cryptosystem Negotiation Extension

Jeffrey Hutzelman


On Thursday, July 14, 2005 08:01:54 PM -0400 Jeffrey Hutzelman
<[hidden email]> wrote:

> 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.

Actually, thinking about it...  The existing text says the client's list is
in preference order; to me, the implication (even though it isn't spelled
out) is that the server is supposed to pick the first thing in the list
that it is willing to use.  Therefore, I believe that making the client's
list unordered and having the server pick its most preferred enctype would
be a substantive change, and would require a consensus call.




Reply | Threaded
Open this post in threaded view
|

RE: Last Call - Kerberos Cryptosystem Negotiation Extension

Larry Zhu
In reply to this post by Jeffrey Hutzelman
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Thursday, July 14, 2005 5:02 PM
To: Liqiang(Larry) Zhu; Ken Raeburn
Cc: [hidden email]
Subject: RE: Last Call - Kerberos Cryptosystem Negotiation Extension



On Thursday, July 14, 2005 03:26:19 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

RE: Last Call - Kerberos Cryptosystem Negotiation Extension

Jeffrey Hutzelman
In reply to this post by Jeffrey Hutzelman


On Thursday, July 14, 2005 08:16:25 PM -0400 Jeffrey Hutzelman
<[hidden email]> wrote:

>
>
> On Thursday, July 14, 2005 08:01:54 PM -0400 Jeffrey Hutzelman
> <[hidden email]> wrote:
>
>> 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.
>
> Actually, thinking about it...  The existing text says the client's list
> is in preference order; to me, the implication (even though it isn't
> spelled out) is that the server is supposed to pick the first thing in
> the list that it is willing to use.  Therefore, I believe that making the
> client's list unordered and having the server pick its most preferred
> enctype would be a substantive change, and would require a consensus call.


And now I get to reverse myself again...  After talking to Larry and
rereading the text in question, I am convinced that the original intent
always was to allow the server to pick any enctype it pleased, using the
client's preference order as input but not being bound by it.  Still, the
mere fact that I was able to interpret it the other way suggests that the
text is not sufficiently clear.

I've told Larry that unless he hears objections, he should go ahead and
incorporate Ken's suggested clarifications.

This is the only item which I felt could have been a substantive change, so
unless there are other comments with substantive issues, we won't do
another WGLC.

-- Jeff