RE: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00
"Stefan Santesson" <stefans@microsoft.com> Tue, 18 April 2006 18:41 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv8R-00041U-Ru; Tue, 18 Apr 2006 14:41:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv8Q-00041D-VD; Tue, 18 Apr 2006 14:41:10 -0400
Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVv8Q-00089y-Kv; Tue, 18 Apr 2006 14:41:10 -0400
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:41:09 +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:40:53 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA28D2@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <86wtdmagi7.fsf@raman.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: AcZjFWWurllNEjq/TPyS6MseVC7DIAAAC4yw
From: Stefan Santesson <stefans@microsoft.com>
To: EKR <ekr@networkresonance.com>
X-OriginalArrivalTime: 18 Apr 2006 18:41:09.0810 (UTC) FILETIME=[A90AE920:01C66317]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
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
Eric, It seems that we have a misunderstanding (or disagreement?) on the scope of this document. It is not intended to specify the UPN of Active Directory or how user account names in Active Directory are obtained. It neither intends to specify how any server environment should map this hint to any account. The scope of this document is to specify a _generic_ protocol syntax for exchanging hints. In addition to this the document specifies one specific hint type that may be used to send over a domain hint or a user@domain hint. Other hint types may be defined in future standards. Any references to use in a Microsoft environment should only be viewed as implementation examples. I've said before that I'm willing to change the name (not using "UPN" at all as variable name), keeping the same syntax, if that helps clarifying this. As a natural follow up I would certainly consider writing an informational document specifying the exact encoding and matching rules for a Microsoft UPN. But that would be a separate effort and obviously Informational. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Eric Rescorla [mailto:ekr@raman.networkresonance.com] > Sent: den 18 april 2006 11:25 > To: Stefan Santesson > Cc: Russ Housley; iesg@ietf.org; tls@ietf.org > Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft- > santesson-tls-supp-00 > > "Stefan Santesson" <stefans@microsoft.com> writes: > > >> > >> 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. > > I'm not talking about the normalization issue, primarily. I'm talking > about the fact that the UPN part of the specification is incompletely > specified. See, for instance my comments about how the client knows > the domain should get the UPN data. For that matter, the procedure > for determining whether the UPN maps to any given certificate is > unspecified. The first issue in particular makes it very unlikely > that one could interoperably implement this feature in a reasonable > kind of way. > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Comments on draft-santesson-tls-ume-04/draf… Eric Rescorla
- [TLS] Re: Comments on draft-santesson-tls-ume-04/… Russ Housley
- [TLS] Re: Comments on draft-santesson-tls-ume-04/… Eric Rescorla
- RE: [TLS] Re: Comments on draft-santesson-tls-ume… Stefan Santesson
- Re: [TLS] Re: Comments on draft-santesson-tls-ume… Eric Rescorla
- RE: [TLS] Re: Comments ondraft-santesson-tls-ume-… Stefan Santesson
- RE: [TLS] Re: Comments on draft-santesson-tls-ume… Stefan Santesson
- Re: [TLS] Re: Comments ondraft-santesson-tls-ume-… Eric Rescorla
- RE: [TLS] Re: Comments ondraft-santesson-tls-ume-… Stefan Santesson
- Re: [TLS] Re: Comments ondraft-santesson-tls-ume-… Eric Rescorla
- RE: [TLS] Re: Comments ondraft-santesson-tls-ume-… Stefan Santesson
- [TLS] Re: Comments on draft-santesson-tls-ume-04/… Russ Housley
- [TLS] RE: Comments on draft-santesson-tls-ume-04/… Stefan Santesson