RE: Three short fixes: no padlock; text logo; member since
2007-06-20 15:29:50 GMT
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
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.
> 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.
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.
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'.
…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.
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?