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

Eric Rescorla <ekr@raman.networkresonance.com> Tue, 18 April 2006 18:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVusd-0008SR-VJ; Tue, 18 Apr 2006 14:24:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVusc-0008SJ-LS; Tue, 18 Apr 2006 14:24:50 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVusb-0007E1-9q; Tue, 18 Apr 2006 14:24:50 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id DA41C1E8C1F; Tue, 18 Apr 2006 11:24:48 -0700 (PDT)
To: "Stefan Santesson" <stefans@microsoft.com>
Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-santesson-tls-supp-00
References: <BF9309599A71984CAC5BAC5ECA62994404AA28BD@EUR-MSG-11.europe.corp.microsoft.com>
From: Eric Rescorla <ekr@raman.networkresonance.com>
Date: Tue, 18 Apr 2006 11:24:48 -0700
In-Reply-To: <BF9309599A71984CAC5BAC5ECA62994404AA28BD@EUR-MSG-11.europe.corp.microsoft.com> (Stefan Santesson's message of "Tue, 18 Apr 2006 19:07:11 +0100")
Message-ID: <86wtdmagi7.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: iesg@ietf.org, tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
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

"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