W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

RE: No Padlock OID

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Sun, 22 Apr 2007 18:26:54 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD370124CB12@MOU1WNEXMB04.vcorp.ad.vrsn.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Cc: <public-wsc-wg@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:47 GMT