Three short fixes: no padlock; text logo; member since

Hallam-Baker, Phillip | 20 Jun 2007 17:29

RE: Three short fixes: no padlock; text logo; member since

The issue here is backwards compatibility.

Any certificate issued today must work accaptably with existing browsers. That means chaining up to an embedded root. Under the rules as they are today a cert issuer can issue a certificate with essentially no meaningful authentication and many do.

The point is to allow an issuer to differentiate between certificates that are designed to provide a meaningful degree of accountability from those which are simply designed to turn on SSL in the deployed base of a billion browsers. Over time the deployment of browsers that observe the OID would increase.

If we were designing from scratch the sensible way to do this would be to have an OID with positive semantics 'assert security to the user'. Since we don't have that luxury and since we have to deal with the billion deployed browsers we need a different approach.

I do not agree with the sentiment that a standards process should only deal with perfect situations and stick its head in the sand when it comes to tough deployment issues. Managing the constraints of the deployed base should be the first concern for a WG that has been in existence for ten years.

At least PKIX has a deployed base to worry about.

From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Manger, James H
Sent: Sunday, June 17, 2007 9:39 PM
To: pkix
Subject: RE: Three short fixes: no padlock; text logo; member since

I like the idea of reverting to an “unsecured” look-n-feel and avoiding nag screens when the security, though present, is not “perfect”.

It is bad that many clients treat unconfirmed security (eg signed, but not by a locally-trusted root) as worse than no security. This discourages attempts to improve security.

I am less sure that a “no padlock” attribute is the right way to achieve this.

>Wouldn't it be nice if a cert could say 'the correct course of action if you don't like me is to simply show the email without any indication the message is secure'.

Wouldn’t it be better to fix email clients so they always act this way, instead of only triggering this behaviour for certain certificates? Unless it is a tactical decision that software vendors are more likely to implement a new certificate feature than change existing behaviour (especially if the latter might be branded as worsening security).

For HTTPS connections, a certificate without a subjectAltName.dNSName field (and no domain name in a common name component of the subject field) should be sufficient for a browser to say “well I cannot do the URL-to-cert check so I will display the page just like an HTTP page”: no coloured address bar, no locked padlock, no nag screens, still using TLS on-the-wire though. No path to a trusted root (eg a self-signed cert) should be treated the same way. Unavailable CRLs could be treated the same way.

Other errors such as an incorrect signature, expired certificate, or a mismatch between URL & cert name imply the certificate holder has done something wrong. I don’t have a problem with nag screens (or outright refusal to connect) in these cases.

PROBLEM

> I don't see why we need to tell the user that encryption is being used unless they have explicitly said that they need confidentiality.

The problem is that the HTTPS scheme in a URL implies a “safe” connection, regardless of a padlock icon or address bar colour. If a user didn’t know if the URL was HTTP or HTTPS (eg their browser automatically went there after an HTTP 307 redirect) then treating “unconfirmed security” as “unsecured” would be reasonable. On the other hand, if I choose my HTTPS bookmark for my bank then I expect my browser not to process any (potentially-malicious) html/javascript/activex/flash for any other source. If my browser (perhaps due to a DNS attack) silently accepted content not from my bank I would be worse off.

Any visibility of an HTTPS URL to the user could be considered as them explicitly saying they need confidentiality: choosing an HTTPS bookmark; typing HTTPS into the address bar; clicking on an HTTPS link when the URL was shown in the status bar before the click; even seeing HTTPS in the address bar after receiving a page can be enough.

From: Hallam-Baker, Phillip
Sent: Tuesday, 5 June 2007 3:37 AM
Subject: Three short fixes: no padlock; text logo; member since

…

3) No Padlock Icon attribute

    This attribute would allow a certificate to say that no user indication should be specified in the chrome, nor should any nag screens. It would be an option that the issuing CA would put in at their discretion.

    The need for this is to allow a CA to support a wide range of applications which require encryption but require even less authentication than current schemes such as domain validated certs. For example self signed certificates, certificates issued to embedded hardware, etc. etc.

    What I want to do is to get us to the point where the browser authors feel comfortable with a user experience that does not contain the nag screens that disfigure current schemes. In many cases all that is required is to turn on encryption. The user does not need to be told that the certificate has expired, has been issued by an unknown CA or any of the usual nonsense. just don't tell the user that its safe in the first place and the browser does not need to say that it is dangerous.

    Clearly this attribute is unnecessary from a technical point of view. From a market point of view it is essential if we are going to ensure that applications are doing the right thing. The padlock icon has some pretty strong semantics. Many applications require less. We are not going to get everyone who currently has a padlock certificate to get a green bar cert. So lets serve the applications that require even less than the padlock without diluting the padlock semantics further.

From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Hallam-Baker, Phillip
Sent: Thursday, 7 June 2007 3:06 AM
To: Kemp, David P.; pkix

3) No Padlock Icon attribute

The point here is precisely to allow a certificate to state 'there are no security claims being made here'.

The user does not accept the certificate, the client application does. No user has ever checked a certificate path and no user ever will. The question is whether the client application should be telling the user that it is 'safe' or not.

I don't see why we need to tell the user that encryption is being used unless they have explicitly said that they need confidentiality. Telling the user that there is encryption means also telling them about a whole range of failures and other error conditions.

_____________________________________________
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, 12 June 2007 12:24 AM

…

I can give you a cast iron chain for an EUI48 MAC address. But it says nothing that should give an end user warm fuzzies.

'This cert makes no security claims that are worth display to an end user'.

…

_____________________________________________
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, 12 June 2007 3:45 AM

…The information to be encoded here relates to the issue practices of the certificate. Therefore they go into the certificate.

These are not anonymous communications, they are merely communications that do not require the level of assurance that is necessary to alert the user to tell tham that the communication is secure.

_____________________________________________
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, 12 June 2007 10:00 AM

Case in point here being your S/MIME cert which does not satisfy my Outlook chaining so give a warning.

Yet I can get mail from plenty of places without any security and without a warning either.

Wouldn't it be nice if a cert could say 'the correct course of action if you don't like me is to simply show the email without any indication the message is secure'.

Why do folk feel that the user has to be told about merely sub-standard security when 99% of the Internet has no security at all?