RE: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00

"Stefan Santesson" <stefans@microsoft.com> Tue, 18 April 2006 18:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVubk-000451-JP; Tue, 18 Apr 2006 14:07:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVubj-00044k-P9; Tue, 18 Apr 2006 14:07:23 -0400
Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVubh-0006Az-Dx; Tue, 18 Apr 2006 14:07:23 -0400
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:07:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00
Date: Tue, 18 Apr 2006 19:07:11 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA28BD@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <20060417231559.1B82B222418@laser.networkresonance.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00
Thread-Index: AcZidAnbmQ8mvRlkQ/SN5fpLmrXUcgAnZMaA
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Eric Rescorla" <ekr@networkresonance.com>, "Russ Housley" <housley@vigilsec.com>
X-OriginalArrivalTime: 18 Apr 2006 18:07:16.0912 (UTC) FILETIME=[ED574B00:01C66312]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: iesg@ietf.org, tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

In line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]
> Sent: den 17 april 2006 15:10
> To: Russ Housley
> Cc: iesg@ietf.org; tls@ietf.org
> Subject: [TLS] Re: Comments
ondraft-santesson-tls-ume-04/draft-santesson-
> tls-supp-00
> 
> Russ Housley <housley@vigilsec.com> wrote:
> > >-tls-ume:
> > >Why is this draft going to Proposed? ISTM that it's pretty
> > >hard to interpret without a bunch of MS-proprietary
> > >information. There's no need for it to go to Proposed, since
> > >both extensions and Supp-data allow code points to be
> > >issued via informational.
> >
> > This is being discussed.  The reason that I would like to see it as
> > standards-track is that the structure supports more than just
> > Microsoft names.  The Microsoft names are simply the first ones that
> > are supported.
> 
> I'm sympathetic to this, but I'm also uncomfortable with having a PS
> that's not really implementable in part. That said, this is probably
> part of a higher level IETF/IESG policy discussion rather than
> a TLS one.
> 

[Stefan] What part is not implementable? If you are referring to the
fact that normalization of the user name part of the UPN hint is not
fully defined, that does not make this specification un-implementable.

Anny client/server based system that currently is using TLS for user
authentication must have an understanding of how names they use to
access accounts are formed. This standard makes it possible for them to
send that username in that form. If we enforce specific character
normalization on the user name then they may not be able to use this
standard anymore as it may conflict with how they encode usernames.

Many standards define fields that higher level protocols and apps can
use in multiple ways. That does not make those standards
un-implementable. It's just a limitation of scope.


> 
> > >S 4:
> > >You can do the UPN hint extension exchange and then NOT
> > >send supp_data? That seems wrong.
> >
> > I agree, if the negotiation is successful, then the supplemental
data
> > should be sent.
> 
> This should be a MUST, IMO. I.e., the peer can and probably
> should detect it and throw an error. If it's a SHOULD,
> then the document needs to explain how.
> 
[Stefan] No, this is not an error. Se other response.


> Best,
> -Ekr
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls