W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

RE: WebID-ISSUE-19: x509v3 Independence and TLS Extensions [WebID Spec]

From: Peter Williams <home_pw@msn.com>
Date: Tue, 1 Feb 2011 09:41:27 -0800
Message-ID: <SNT143-w49A948E20C49279B6F17AC92E50@phx.gbl>
To: <benjamin.heitmann@deri.org>, <public-xg-webid@w3.org>

in windows world this is done all the time. There are probably a hundred of them, for each "variant" of https/SSL applied to some application or other. It acts as descriminator when switching and enforcing type systems security policies.
 
Its quite normal to do what you suggest.
 

> From: benjamin.heitmann@deri.org
> Date: Tue, 1 Feb 2011 16:41:42 +0000
> To: public-xg-webid@w3.org
> Subject: Re: WebID-ISSUE-19: x509v3 Independence and TLS Extensions [WebID Spec]
> 
> On 1 Feb 2011, at 10:18, WebID Incubator Group Issue Tracker wrote:
> > 
> > However, RFC 4346 "Transport Layer Security (TLS) Extensions" [1] (obsoleting RFC 3546) defines several general extension methods including "Extended Client Hello" [2].
> 
> 
> In addition there seems to be another mechanism, which might be appropriate for indicating that a certain certificate should only be used for WebIDs: 
> 
> "Extended Key Usage" in RFC 5280 [1]:

For example, a little titbit of real life not far from what we are doing here with SSL, from http://technet.microsoft.com/en-us/library/ee516808(WS.10).aspx. It shows an example of a type enforcer that requires an EKU to identity a particular validity procedure to be used to evaluate the SSL client auth-delivered claim. Intelectually, you have to "claim" the validity model (that I called a reliance trust model, not that it matters).
 
  		 	   		  
Received on Tuesday, 1 February 2011 17:42:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC