RE: No Padlock OID

A TLS extension is under the control of the user, it is the certificate issuer who wants to enforce the restriction here.

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
> Sent: Sunday, April 22, 2007 10:20 AM
> To: Hallam-Baker, Phillip
> Cc: public-wsc-wg@w3.org
> Subject: Re: No Padlock OID
> 
> 
> (Isn't that out of scope here? Anyway...)
> 
> I don't see why "no authentication" is the only, or most 
> interesting, reason to not display a padlock.
> 
> I don't see why an X.509 OID is the way to implement that, 
> vs. a TLS extension, or an anonymous D-H ciphersuite or whatever.
> 
> I do think that proposals to change what the padlock does are 
> interesting and merit discussion somewhere.
> 
> S.
> 
> Hallam-Baker, Phillip wrote:
> > One of the main problems we face with certificates is that 
> the padlock 
> > conflates encryption and authentication.
> >  
> > There are many applications where we want encryption but we do not 
> > want to authenticate the certificate subject beyond domain level 
> > assurance, in VeriSign terms a class 1 certificate, SSL is 
> normally class 3 or 3+EV.
> >  
> > Would the browser providers be prepared to support an OID 
> which would 
> > disable the padlock display? Such a certificate would 
> respond to https 
> > and turn on encryption, but without a padlock.
> >  
> >  
> > The objective here is to support embedded devices like 
> coffee pots and 
> > house cleaning robots where we want communication to the 
> device to be 
> > encrypted but not pay for the level of authentication that would be 
> > required to issue a merchant certificate.
> >  
> >  
>

Received on Monday, 23 April 2007 01:27:28 UTC