CABforum BR defines a 3-tier cert system. What does the browser do with that info?

[John Nagle]

The CA Browser Forum's "Baseline Requirements" document
defines three levels of certs:

"Domain Control Only" validated (no organizationName)
"Organization identified" (must have organizationName,
localityName, stateOrProvinceName, and countryName)
"Extended Validation" (all of the above, plus
full address and corporate identity, with
stronger checking.)

Previously, some certs had those fields, and some didn't.
There was no standardization. Often, "organizationName"
would be present, but would just be a domain name. Under
the new rules, that ends. If present, organizationName
has to be the real name of the business or individual.
See the reference below.

Browsers generally haven't done much with organization info,
and haven't distinguished between domain-control-only certs
and "Organization identified" certs. Now that the CA
Browser Forum is making this distinction, the browser
should use it, and display some visual indication of the
cert type. A cert with an identified organization behind it
is meaningful for routine transactions. With a "domain
control only" cert, you don't know who you're dealing with.

So what should the browser do? A different lock icon?
A tooltip balloon with the business address? Business
identity is a valuable feature, and should be displayed
to consumers.

John Nagle
SiteTruth
www.sitetruth.com

Ref: section 9.2.4.

9.2.4 ... organizationName (OID 2.5.4.10)
....
The organization name is OPTIONAL. If organization name is present,
then localityName, stateOrProvinceName (where applicable), and
countryName are REQUIRED and streetAddress and postalCode are OPTIONAL.
If organization name is absent, then the Certificate MUST NOT contain
a streetAddress, localityName, stateOrProvinceName, or postalCode attribute.

Contents: If the organizationName field is present, the field MUST
contain the Subject’s name or DBA and the required address fields MUST
contain a location of the Subject as verified by the CA pursuant to If
the Subject is a natural person, because Subject name attributes for
individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not
broadly supported by application software, the CA MAY use the
organizationName field to convey the Subject’s name or DBA.

[Gervase Markham]

On 25/03/12 23:11, John Nagle wrote:
> Browsers generally haven't done much with organization info,
> and haven't distinguished between domain-control-only certs
> and "Organization identified" certs. Now that the CA
> Browser Forum is making this distinction, the browser
> should use it, and display some visual indication of the
> cert type.

This logic is invalid. :-)

EV came into being because there was no meaningful definition of what OV
is and what sort of validations are done (and those that were done were
of wildly variable quality, with downward price pressure). The fact that
there's now a single paragraph in the BRs, and some OIDs, doesn't change
that significantly. Just because we can detect what a CA's marketing
department thinks their certificate qualifies as doesn't mean we should
reflect that in browser chrome.

Browsers already do display business identity to consumers - when the
business has an EV cert, whose validation and vetting are carefully
defined and standardized across CAs.

Gerv

[Eddy Nigg]

On 03/27/2012 12:23 PM, From Gervase Markham:

> The fact that there's now a single paragraph in the BRs, and some
> OIDs, doesn't change that significantly.

Yes it does change that significantly in my opinion.

> Just because we can detect what a CA's marketing department thinks
> their certificate qualifies as doesn't mean we should reflect that in
> browser chrome.

Well, that's exactly not the case anymore, there are clear requirements
now for each validation type. It's not a marketing thing anymore as it
existed up to now.

And I think you are also the only one thinking this to be still the case :-)

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Rob Stradling]

Gerv, one thing that surely needs to change is PSM's assertion "Owner:
This web site does not supply ownership information" for OV certs. This
assertion has always been misleading, in my view. (I think it would
have been better to simply omit this "Owner:" statement from the UI for
OV certs).

OV certs do contain, and always have contained, ownership information.
Whether or not this ownership information has been validated to a
standard that Mozilla recognizes is a separate issue. The fact is:
Ownership information _is_ supplied by the website, because the Subject
of the site's OV certificate contains standard attributes defined by
X.509/X.520/RFC5280.

I share the hope that PSM will show ownership information from OV certs
that are validated in accordance with the Baseline Requirements.

On 27/03/12 11:57, Eddy Nigg wrote:
> On 03/27/2012 12:23 PM, From Gervase Markham:

>> The fact that there's now a single paragraph in the BRs, and some
>> OIDs, doesn't change that significantly.
>

> Yes it does change that significantly in my opinion.
>

>> Just because we can detect what a CA's marketing department thinks
>> their certificate qualifies as doesn't mean we should reflect that in
>> browser chrome.
>

> Well, that's exactly not the case anymore, there are clear requirements
> now for each validation type. It's not a marketing thing anymore as it
> existed up to now.
>
> And I think you are also the only one thinking this to be still the case
> :-)
>

--

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[John Nagle]

On 3/27/2012 3:23 AM, Gervase Markham wrote:
> On 25/03/12 23:11, John Nagle wrote:

>> Browsers generally haven't done much with organization info,
>> and haven't distinguished between domain-control-only certs
>> and "Organization identified" certs. Now that the CA
>> Browser Forum is making this distinction, the browser
>> should use it, and display some visual indication of the
>> cert type.
>

> This logic is invalid. :-)
>
> EV came into being because there was no meaningful definition of what OV
> is and what sort of validations are done (and those that were done were

> of wildly variable quality, with downward price pressure). The fact that

> there's now a single paragraph in the BRs, and some OIDs, doesn't change

> that significantly. Just because we can detect what a CA's marketing

> department thinks their certificate qualifies as doesn't mean we should
> reflect that in browser chrome.
>

> Browsers already do display business identity to consumers - when the
> business has an EV cert, whose validation and vetting are carefully
> defined and standardized across CAs.
>
> Gerv

That's an obsolete viewpoint. The CA Browser Forum, which includes
the CAs behind 90% of certs, is changing the rules. The new rule is
that if a cert contains identity information, the CA must have verified
it. See 7.1.2.5, Identity of Applicant:
"if the Certificate contains Subject Identity Information, the CA
(i) implemented a procedure to verify the identity of the
Applicant in accordance with Sections 9.2.4 and 11.2;
(ii) followed the procedure when issuing the Certificate; and
(iii) accurately described the procedure in the CA’s
Certificate Policy and/or Certification Practice Statement;

Section 11.2, on validation, says:

The CA SHALL verify the identity and address of the Applicant using
documentation provided by, or through communication with, at least
one of the following:
1. A government agency in the jurisdiction of the Applicant’s
legal creation, existence, or recognition;
2. A third party database that is periodically updated, which
the CA has evaluated in accordance with Section 11.6;
3. A site visit by the CA or a third party who is acting as
an agent for the CA; or
4. An Attestation Letter.

This is a lower standard than the EV standard for organizational
validation. The CA Browser Forum explains the differences at

http://www.cabforum.org/faq.html

New certs complying with the new rules should contain the
OID 2.23.140.1.2.2 in the Certificate Policy field. If a
cert has that OID, it MUST also include organizationName,
localityName, stateOrProvinceName (if applicable), and
countryName in the Subject field, and those must have
been validated in accordance with the CA Browser Forum
rules.

After all this trouble has been taken to tighten up the rules
and collect that information, better browsers should use it.

John Nagle
SiteTruth

[Kathleen Wilson]

On 3/27/12 10:39 AM, John Nagle wrote:
> http://www.cabforum.org/faq.html
>
> New certs complying with the new rules should contain the
> OID 2.23.140.1.2.2 in the Certificate Policy field. If a
> cert has that OID, it MUST also include organizationName,
> localityName, stateOrProvinceName (if applicable), and
> countryName in the Subject field, and those must have
> been validated in accordance with the CA Browser Forum
> rules.
>
> After all this trouble has been taken to tighten up the rules
> and collect that information, better browsers should use it.
>

I filed a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=740571

Kathleen

[John Nagle]

Thanks. I added some technical details about how that data
is stored, and mentioned that I'm encouraging the CA/Browser
Forum to add a technical appendix to their document.

(The storage format is weird. RFC2527 doesn't specify
the contents of that field. The CA/Browser Forum chose to
make it type OctetStream, then put another DER-encoded ASN1
tree into it, when they specified EV certs. But they
never documented that anywhere public. I and others
had to reverse engineer it.)

John Nagle
SiteTruth

[Rob Stradling]

On 29/03/12 22:14, John Nagle wrote:
<snip>

> Thanks. I added some technical details about how that data
> is stored, and mentioned that I'm encouraging the CA/Browser
> Forum to add a technical appendix to their document.
>
> (The storage format is weird. RFC2527 doesn't specify
> the contents of that field.

RFC2527 references RFC2459 (superseded by RFC3280 and now RFC5280),
which does specify the contents of the Certificate Policies extension.

> The CA/Browser Forum chose

The CA/Browser Forum did not define the Certificate Policies extension.
It was originally defined by ITU/ISO in X.509.

> to make it type OctetStream,

I think you mean OCTET STRING, and I think you're referring to the
definition of an X.509 certificate extension:

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }

> then put another DER-encoded ASN1 tree into it, when they specified EV certs. But they
> never documented that anywhere public.

The CABForum doesn't have a habit of re-documenting everything that has
been in the ITU/ISO and IETF specs for many years!

> I and others had to reverse engineer it.)
>
> John Nagle
> SiteTruth
>
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 27/03/12 13:21, Rob Stradling wrote:
> Gerv, one thing that surely needs to change is PSM's assertion "Owner:
> This web site does not supply ownership information" for OV certs.

You are right. It should say "This web site does not supply trustworthy
ownership information."

:-)

"Trustworthy" being in the opinion of Mozilla, of course.

Sorry, boys, but the BRs are not a back door into changing Mozilla's
long-standing policy on this issue. If it were possible to standardize
OV appropriately and at a decent level of validation in a single
paragraph, we wouldn't have bothered doing EV at all.

Gerv

[Eddy Nigg]

On 03/30/2012 02:23 PM, From Gervase Markham:

> If it were possible to standardize OV appropriately and at a decent
> level of validation in a single paragraph, we wouldn't have bothered
> doing EV at all.

With this attitude we'll be probably forced to work towards
lowering/changing the requirements of EV to the extend so that we can
comfortably use our OV procedures to sign EV certificates.

I'd prefer a higher standard and requirements for EV and have sane and
reasonable OV procedures in place as well, but the current "EV and all
the rest" categorization does neither reflect reality nor is it really
helpful for the relying parties.

In my and many others opinion, the BR provides reasonable requirements
and standardization of identity and organization validation. Also for
domain control validation of course.

[John Nagle]

On 3/30/2012 12:04 AM, Rob Stradling wrote:
> On 29/03/12 22:14, John Nagle wrote:
> <snip>
>> Thanks. I added some technical details about how that data
>> is stored, and mentioned that I'm encouraging the CA/Browser
>> Forum to add a technical appendix to their document.
>>
>> (The storage format is weird. RFC2527 doesn't specify
>> the contents of that field.
>
> RFC2527 references RFC2459 (superseded by RFC3280 and now RFC5280),
> which does specify the contents of the Certificate Policies extension.

RFC 5280 says, at 4.2.1.4,

"The certificate policies extension contains a sequence of one
or more policy information terms, each of which consists of an object
identifier (OID) and optional qualifiers." The syntax reads

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }

Nowhere in there is an OctetString.


That's not what the CA/Browser Forum members put there for EV certs.
They put a DER-encoded ASN1 tree in an OctetString field. It
looks like this in the Verisign-issued cert for "bankofamerica.com".

ObjectIdentifier: 2.5.29.32 certificatePolicies
OctetString: (48, 59, 48, 57, 6, 11, 96, 134, 72, 1, 134, 248,
69, 1, 7, 23, 6, 48, 42, 48, 40, 6, 8, 43, 6, 1, 5, 5, 7, 2, 1, 22, 28,
104, 116, 116, 112, 115, 58, 47, 47, 119, 119, 119, 46, 118, 101, 114,
105, 115, 105, 103, 110, 46, 99, 111, 109, 47, 99, 112, 115)
Certificate Policies - special case - decoding OctetString as
DER ASN1
Sequence:
Sequence:
ObjectIdentifier: 2.16.840.1.113733.1.7.23.6
('http://www.verisign.com/repository/CPS/VeriSignCPSv3.3.pdf', 'VeriSign')
Sequence:
Sequence:
ObjectIdentifier: 1.3.6.1.5.5.7.2.1 None
OctetString: (104, 116, 116, 112, 115, 58, 47, 47,
119, 119, 119, 46, 118, 101, 114, 105, 115, 105, 103, 110, 46, 99, 111,
109, 47, 99, 112, 115)
OctetString as ASCII: 'https://www.verisign.com/cps'


Dump some real cerificates and take a look. (Not with a browser,
with an ASN1 dumper. Most browsers already know this is a special
case.)

> I think you're referring to the
> definition of an X.509 certificate extension:
>
> Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
>
> Extension ::= SEQUENCE {
> extnID OBJECT IDENTIFIER,
> critical BOOLEAN DEFAULT FALSE,
> extnValue OCTET STRING }

That's the generic format of an extension, and is what the
CA/Browser Forum relied upon to put unstandardized data into
an X.509 certificate.

> The CABForum doesn't have a habit of re-documenting everything that has
> been in the ITU/ISO and IETF specs for many years!

Point to a published specification which describes putting a second
level of DER-encoded data into an OctetString field in the
certificatePolicies extension.

John Nagle
SiteTruth

[Erwann Abalea]

The extension value itself is stored in an OCTETSTRING.

> That's not what the CA/Browser Forum members put there for EV certs.
> They put a DER-encoded ASN1 tree in an OctetString field. It
> looks like this in the Verisign-issued cert for "bankofamerica.com".

And this is standard behaviour. All the extensions are encapsulated like this, in an OCTETSTRING.

> ObjectIdentifier: 2.5.29.32 certificatePolicies
> OctetString: (48, 59, 48, 57, 6, 11, 96, 134, 72, 1, 134, 248,
> 69, 1, 7, 23, 6, 48, 42, 48, 40, 6, 8, 43, 6, 1, 5, 5, 7, 2, 1, 22, 28,
> 104, 116, 116, 112, 115, 58, 47, 47, 119, 119, 119, 46, 118, 101, 114,
> 105, 115, 105, 103, 110, 46, 99, 111, 109, 47, 99, 112, 115)
> Certificate Policies - special case - decoding OctetString as
> DER ASN1
> Sequence:
> Sequence:
> ObjectIdentifier: 2.16.840.1.113733.1.7.23.6
> ('http://www.verisign.com/repository/CPS/VeriSignCPSv3.3.pdf', 'VeriSign')
> Sequence:
> Sequence:
> ObjectIdentifier: 1.3.6.1.5.5.7.2.1 None
> OctetString: (104, 116, 116, 112, 115, 58, 47, 47,
> 119, 119, 119, 46, 118, 101, 114, 105, 115, 105, 103, 110, 46, 99, 111,
> 109, 47, 99, 112, 115)
> OctetString as ASCII: 'https://www.verisign.com/cps'

And this is a standard certificatePolicies extension, which defines only 1 certificatePolicy, with a policyId set to 2.16.840.1.113733.1.7.23.6, and a cPSUri set to 'https://www.verisign.com/cps'. Your parser is broken, the cPSUri is not encoded as an OctetString, but as an IA5String.

You should read again X.509, X.680, and X.690.

[John Nagle]

eab...@gmail.com wrote:
> You should read again X.509, X.680, and X.690.

And the four relevant RFCs, RFC2527, RFC2459, RFC3280, and RFC5280.
There's also "oid-info.com", for looking up OIDs, plus some OID lists
at IANA.

The "X.509 Style Guide", although dated, is also worth a read, as it
describes the various specs, their ambiguities, and disagreements.

http://www.clizio.com/S3/docum/X509StyleGuide.pdf

They write:
"Unfortunately on top of this there are qualifiers for the
certificatePolicies and the policyConstraints extension to muddy the
waters. As a result, a certificate policy often consists of a sequence
of things identified by unknown object identifiers, each with another
sequence of things identified by partially known, partially unknown
object identifiers, with optional extra attachments containing
references to other things which software is expected to know about by
magic or possibly some form of quantum tunnelling."

It really is a mess, which is why the people trying to solve
the sub-CA restriction problem are struggling to add restrictions
on sub-CAs without breaking something. However, the technical
problem we're discussing here isn't as hard. So we can return
to the policy discussion.

Implementation detail can be discussed at Bug 740571.

John Nagle
SiteTruth

[ianG]

On 30/03/12 22:23 PM, Gervase Markham wrote:
> On 27/03/12 13:21, Rob Stradling wrote:

>> Gerv, one thing that surely needs to change is PSM's assertion "Owner:
>> This web site does not supply ownership information" for OV certs.
>

> You are right. It should say "This web site does not supply trustworthy
> ownership information."
>
> :-)
>
> "Trustworthy" being in the opinion of Mozilla, of course.

exactly, thank you. It should say all that. Which is to say, words to
effect:

"Mozilla does not find the ownership information
that is supplied to be trustworthy."

Without saying WHO has that opinion, it is a deception to the user, and
as the user sees that remark as deceptive enough times, her faith in the
security of the product, warnings, etc, goes down. E.g., click-thru
syndrome.

> Sorry, boys, but the BRs are not a back door into changing Mozilla's

> long-standing policy on this issue. If it were possible to standardize

> OV appropriately and at a decent level of validation in a single
> paragraph, we wouldn't have bothered doing EV at all.

Yes, nod. I thought that the point of EV was to replace OV, more or less.



iang

[Brian Smith]

Gervase Markham wrote:
> On 27/03/12 13:21, Rob Stradling wrote:
> > Gerv, one thing that surely needs to change is PSM's assertion
> > "Owner:
> > This web site does not supply ownership information" for OV certs.
>
> You are right. It should say "This web site does not supply
> trustworthy ownership information."
>
> :-)

I do not see the value in telling the user what we cannot determine. If we can't determine what organization is running a website, we should just omit that field from the UI.

I think it is fine to say "You are connected to paypal.com which is operated by Paypal, Inc. (US) according to Verisign, Inc. (US)." However, it is bad to say "You are connected to mail.google.com which is operated by (unknown) Verified by Thawte Consulting (Pty) Ltd" because:

* It puts unnecessary doubt in the user's mind about whether their connection is secure. I think the original idea here was that instilling this doubt is a good thing, and that important websites should all get EV certificates. But, my understanding, from talking to people at some extremely popular sites that use non-EV certs, is that they are planning to never have EV certificates because of reasons that have nothing to do with the quality of the verification of their identity; for them, it isn't just a matter of paying a few hundred or even a few thousand dollars more. This means, effectively, that this isn't only a security indicator, but also an indicator of whether the website was able to reach a reasonable agreement with the CA regarding payment and other factors. This is not the kind of information that belongs in Firefox's UI, and it isn't something that should be mixed up with security indicators.

* It misleadingly indicates that Thawte somehow *verified* that nobody can figure out who is running google.com. In fact, I bet that that Thawte did pretty extensive verification that they issued the cert to the correct person at Google, Inc. We shouldn't mislead users like this.

* The green EV bar for twitter.com and the blue non-EV bar for google.com or facebook.com indicates that your connection to Twitter is more secure than your connection to Google or Facebook. This may or may not be true, but it is not reasonable to make such an assertion. Again, I think the logic before was that all really big important sites would get EV certs, so such a distinction would be helpful. This has been proved over time to be false.

A lot has changed since the current security UI was developed. EV has proved itself to be, more or less, a failure, if only because facebook.com and google.com and similar very important sites do not use EV certs.

Accordingly, I think now is a good time to re-think if and how we should distinguish EV, OV, and DV sites in the UI. And, in particular, perhaps sites should be given the "green bar for good security" based on enhanced--maybe VERY different--criteria, such as participating in some kind of public verification mechanism (like Google's Certificate Transparency proposal) and/or by participating in some kind of cert pinning scheme (e.g. DANE or Google's HSTS-like pinning proposal) and/or by having some positive assertion of a lack of malicious content (i.e. hooking the safe browsing system into it) and/or by having stapled recent revocation information. Or, maybe we should even go the other way and show the green bar for everything that isn't plain old DV.

Basically, my point is that it we need to look at the results of the ongoing 5-year experiment we've been doing with the current security indicators, and then determine what to do to improve them.

See also this awesome blog post:
http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/

Cheers,
Brian

[John Nagle]

On 4/4/2012 11:47 AM, Brian Smith wrote:
> Gervase Markham wrote:
>> On 27/03/12 13:21, Rob Stradling wrote:
>>> Gerv, one thing that surely needs to change is PSM's assertion
>>> "Owner: This web site does not supply ownership information" for
>>> OV certs.
>>
>> You are right. It should say "This web site does not supply
>> trustworthy ownership information."

> Accordingly, I think now is a good time to re-think if and how we
> should distinguish EV, OV, and DV sites in the UI.

There's an academic paper on this, from a group that
did experimental user testing at Carleton University:

http://www.scs.carleton.ca/~paulv/papers/ccsw09.pdf

The author makes the point that there's a need to distinguish
between the privacy function of certs and the identity verification
function.

This paper has images of user-tested dialog boxes
for different types of certs. Take a look at Fig. 1.
Each has "Identity Confidence" (Low, Medium, or High),
and "Privacy Confidence" (No, or Yes.) That
distinction appears to be the correct one, and tests
well in user testing.

John Nagle
SiteTruth

[ianG]

On 5/04/12 04:47 AM, Brian Smith wrote:
> Gervase Markham wrote:
>> On 27/03/12 13:21, Rob Stradling wrote:
>>> Gerv, one thing that surely needs to change is PSM's assertion
>>> "Owner:
>>> This web site does not supply ownership information" for OV certs.
>>
>> You are right. It should say "This web site does not supply
>> trustworthy ownership information."
>>

>> :-)
>
> I do not see the value in telling the user what we cannot determine. If we can't determine what organization is running a website, we should just omit that field from the UI.
>
> I think it is fine to say "You are connected to paypal.com which is operated by Paypal, Inc. (US) according to Verisign, Inc. (US)." However, it is bad to say "You are connected to mail.google.com which is operated by (unknown) Verified by Thawte Consulting (Pty) Ltd" because:
>
> * It puts unnecessary doubt in the user's mind about whether their connection is secure. I think the original idea here was that instilling this doubt is a good thing, and that important websites should all get EV certificates. But, my understanding, from talking to people at some extremely popular sites that use non-EV certs, is that they are planning to never have EV certificates because of reasons that have nothing to do with the quality of the verification of their identity; for them, it isn't just a matter of paying a few hundred or even a few thousand dollars more. This means, effectively, that this isn't only a security indicator, but also an indicator of whether the website was able to reach a reasonable agreement with the CA regarding payment and other factors. This is not the kind of information that belongs in Firefox's UI, and it isn't something that should be mixed up with security indicators.
>
> * It misleadingly indicates that Thawte somehow *verified* that nobody can figure out who is running google.com. In fact, I bet that that Thawte did pretty extensive verification that they issued the cert to the correct person at Google, Inc. We shouldn't mislead users like this.
>
> * The green EV bar for twitter.com and the blue non-EV bar for google.com or facebook.com indicates that your connection to Twitter is more secure than your connection to Google or Facebook. This may or may not be true, but it is not reasonable to make such an assertion. Again, I think the logic before was that all really big important sites would get EV certs, so such a distinction would be helpful. This has been proved over time to be false.

The point is that the messages & UI are set up to reward the EV cert.
This is why the older certs are now shown as equivalent in UI candy
terms to no cert at all. Once viewed from that lens, everything else
makes sense.

If however it is viewed as saying something meaningful to the user, it's
a lost cause... We now have a trivial downgrade attack from any white
cert to no cert because white certs aren't rewarded.

> A lot has changed since the current security UI was developed. EV has proved itself to be, more or less, a failure, if only because facebook.com and google.com and similar very important sites do not use EV certs.

Yes, EV was a failure, but only if you examine it from a user
perspective. That was never the mission. You have to recall that
CABForum was born out of a fear that someone would do something about
phishing to change the way certs were dealt with ... recall the yellow
bar? That came before the green bar?

The task of CABForum was to regularise "best practices" and preserve the
industry structure. This has been done. Very well. It has met all its
targets. EV was a success.

> Accordingly, I think now is a good time to re-think if and how we should distinguish EV, OV, and DV sites in the UI. And, in particular, perhaps sites should be given the "green bar for good security" based on enhanced--maybe VERY different--criteria, such as participating in some kind of public verification mechanism (like Google's Certificate Transparency proposal) and/or by participating in some kind of cert pinning scheme (e.g. DANE or Google's HSTS-like pinning proposal) and/or by having some positive assertion of a lack of malicious content (i.e. hooking the safe browsing system into it) and/or by having stapled recent revocation information. Or, maybe we should even go the other way and show the green bar for everything that isn't plain old DV.
>
> Basically, my point is that it we need to look at the results of the ongoing 5-year experiment we've been doing with the current security indicators, and then determine what to do to improve them.

The only way you are going to change things is the same way as before -
just go ahead and do it.

> See also this awesome blog post:
> http://blog.johnath.com/index.php/2007/03/13/revisiting-security-ui-part-1-of-2/

Yep. Don't slow down, do it!


iang

[Gervase Markham]

On 04/04/12 19:47, Brian Smith wrote:
> I do not see the value in telling the user what we cannot determine.
> If we can't determine what organization is running a website, we
> should just omit that field from the UI.

A reasonable point of view.

> I think it is fine to say "You are connected to paypal.com which is
> operated by Paypal, Inc. (US) according to Verisign, Inc. (US)."
> However, it is bad to say "You are connected to mail.google.com which
> is operated by (unknown) Verified by Thawte Consulting (Pty) Ltd"

Right - there's no point in saying that Thawte verified that it's
operated by (unknown). That makes little sense.

> should all get EV certificates. But, my understanding, from talking
> to people at some extremely popular sites that use non-EV certs, is
> that they are planning to never have EV certificates because of
> reasons that have nothing to do with the quality of the verification
> of their identity; for them, it isn't just a matter of paying a few
> hundred or even a few thousand dollars more.

What are those reasons, if not cost?

> * The green EV bar for twitter.com and the blue non-EV bar for
> google.com or facebook.com indicates that your connection to Twitter
> is more secure than your connection to Google or Facebook.

No, it doesn't. It indicates that the information in the green bar (a
company name and location) is a different thing to the information in
the blue bar (a domain name).

EV is about identity, not security. Sadly, the CAB Forum is not in a
position to control CA marketing programs, so this message is not as
clear to users and site owners as it would ideally be.

Gerv