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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvKL-0007Ns-Il; Tue, 18 Apr 2006 14:53:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvKK-0007Nb-9v; Tue, 18 Apr 2006 14:53:28 -0400
Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvKK-0008Nx-0N; Tue, 18 Apr 2006 14:53:28 -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:53:27 +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:53:25 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA28D9@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/TPyS6MseVC7DIAAA7Q+Q
From: "Stefan Santesson" <stefans@microsoft.com>
To: "EKR" <ekr@networkresonance.com>
X-OriginalArrivalTime: 18 Apr 2006 18:53:27.0452 (UTC) FILETIME=[60B625C0:01C66319]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
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,

Just adding that I already have agreed to make changes to the
introduction to clarify the scope.


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