Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard

Russ Housley <housley@vigilsec.com> Tue, 28 February 2006 16:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE845-0003sD-O7; Tue, 28 Feb 2006 11:51:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE844-0003rz-Nd for tls@ietf.org; Tue, 28 Feb 2006 11:51:08 -0500
Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FE843-0001fB-Gp for tls@ietf.org; Tue, 28 Feb 2006 11:51:08 -0500
Received: (qmail 26608 invoked by uid 0); 28 Feb 2006 16:21:06 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.126.156.113) by woodstock.binhost.com with SMTP; 28 Feb 2006 16:21:06 -0000
Message-Id: <7.0.0.16.2.20060228111255.04c9b688@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 28 Feb 2006 11:18:58 -0500
To: EKR <ekr@networkresonance.com>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard
In-Reply-To: <86r75n7a8n.fsf@raman.networkresonance.com>
References: <BF9309599A71984CAC5BAC5ECA629944044457A0@EUR-MSG-11.europe.corp.microsoft.com> <861wxn8qhc.fsf@raman.networkresonance.com> <7.0.0.16.2.20060228102346.04c9f6e8@vigilsec.com> <86r75n7a8n.fsf@raman.networkresonance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Ari Medvinsky <arimed@windows.microsoft.com>, ietf@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:

> > I can see many situations where the information in this is not
> > sensitive.  In fact, in the primary use case, the use mapping
> > information is not sensitive.  An enterprise PKI is used in this
> > situation, and the TLS extension is used to map the subject name in
> > the certificate to the host account name.
>
>But then we're left with the performance rationale that the user has
>some semi-infinite number of mappings that makes it impossible to send
>all of them and too hard to figure out which one. In light of the fact
>that in the original -01 proposal there wasn't even any negotiation
>for which type of UME data should be sent, is there any evidence that
>this is going to be an important/common case?

This requires a crystal ball....  Apparently yours is different than 
mine, as the negotiation that you reference above was added to 
resolve comments from my AD review.

We all know that there is not going to be a single name form that is 
useful in all situations.  We also know that you cannot put every 
useful name form into the certificate.  In fact, the appropriate 
value can change within the normal lifetime of a certificate, so 
putting it in the certificate will result in high revocation rates.

This is the reason that I believe this TLS extension will be useful 
in environments beyond the one that was considered by the Microsoft 
authors.  Your perspective may differ ....

Russ


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