Re: No Padlock OID

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 06:26:54 UTC