Re: No Padlock OID

Seconding several of the comments I've seen here.  I agree that there  
are many real world examples where TLS certs are used to encrypt  
without it being appropriate to display user interface signals of  
"security" like the padlock.

I too have trouble, though, understanding the benefit of managing  
this via OIDs - what is the problem being fixed, and does this fix  
it?  Malicious/broken/outdated user agents will still show the  
padlock in this case, and malicious sites will work around it by  
shopping with CAs that don't offer this feature.

If this is a response to the broken-ness of the padlock as an  
indicator, then I think the larger task is on us browser vendors to  
fix that signal.  :)

Cheers,

Johnathan

---
Johnathan Nightingale
Human Shield
johnath@mozilla.com



On 23-Apr-07, at 2:28 AM, Stephen Farrell wrote:

>
>
> The (certificate) user being the TLS server here? Or user as
> in relying party?
>
> I don't see what the CA's wishes have to do with what the GUI
> should show the RP. If something helps the user, then sure,
> but not everything that the CA wants is in the RPs best
> interests.
>
> In the case in point the private key holder, if a bad guy,
> can circulate copies of the private key, so the quality of
> the authentication at the RP is under the private key
> holder's control just as much as if a TLS extension were
> used. Or if the bad guy server prefers a simple life, they
> just acquire a cert without that OID...I'm sure some CA
> with a root in the browser will do that for a few more
> (or less) €.
>
> Maybe we need to be clearer about what we're trying to
> achieve and for whose benefit.
>
> S.
>
> Hallam-Baker, Phillip wrote:
>> 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 16:02:03 UTC