Subject: RE: [TLS] The TLS User Mapping Extension draft is available

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 14 Jan 2006 02:51:42 -0000

Thanks Jan for your quick and good review.

We have discussed these comments and agree to most of them.
I address them in-line below.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: Jan Mikkelsen [mailto:[email-masked]] 
Sent: den 9 januari 2006 18:33
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: [TLS] The TLS User Mapping Extension draft is available

Hi,

I just had a quick look at your ID, and I have some minor comments.

In the introduction, you say that if the server doesn't understand this 
extension, it will respond with a non-extended ServerHello.  The server 
could respond with an extended ServerHello that doesn't include this 
extension;  other extensions may be supported.

[Stefan] Agree. Editorial issue that will be fixed in next draft.

The UpnDomainHint field "user_principle_name" should probably be 
"user_principal_name".  It is correct elsewhere in the document.

[Stefan] This is an error that has survived through the development
process of this extension. It will be corrected.

Having an enum name and a struct name both be "UpnDomainHint" is 
confusing.  Perhaps the enum value could be "upn_domain_hint".

[Stefan] Agree, this will be fixed in the next draft.

The UserMappingData struct only allows a single hint type.  Could it be 
useful to allow multiple hint types in a single session setup?

[Stefan] This is a tricky issue but I agree that it could be useful. On
one hand we want to limit the complexity if decisions the server has to
make upon receiving a hint and that complexity increases if multiple
hints are allowed. On the other hand, if a new version of a hint is
created in the future then it would be very hard to manage a transition
with legacy servers and clients if you can't send both hint types in a
single handshake. We will look into this and probably provide a solution
for providing multiple hints. 

The requirement that UpnDomainHint should have at least one member 
populated could also be met by separating the domain and principal hints

and allowing multiple hints in UserMappingData.

[Stefan] We definitely don't want to allow multiple hints of the same
type. Even though you probably could figure out a use case for this, it
is not worth the extra complexity. I suggest that any such needs will
have to be addressed in definition of future hints, if there is a need
for it. In such case a new hint could have a more comprehensive
structure.

This is just from a quick reading;  I haven't thought about the issues 
in any more detail.

I hope this helps.

[Stefan] It certainly does. Thanks.
Regards,

Jan Mikkelsen

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls