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

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