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 Sunday, 22 April 2007 14:19:05 UTC