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

[Brian Smith]

Gervase Markham wrote:
> > 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?

Cost is a big issue, because apparently Verisign and others charge for these certs *per server*. But, if the number of servers you have is a trade secret, you can't pay per server; you have to pay the "unlimited" price, which I guess is negotiated on a "How much money you got?" basis by some important CAs.

Also, we downgrade our UI from the green bar to the blue bar when we fail to get the OCSP response. That means the user can't tell the difference between a mis-issued DV cert, and a genuine EV cert that failed an OCSP fetch; but, that's the whole point of EV looking different. If I were Facebook, I would rather always have the blue bar, than usually have green but sometimes have blue. This might change for some sites if/when they decide to adopt OCSP stapling, after we support it. But, probably not, because IE and other browsers would have the same problem.

> > * 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.

I agree with you. However, it is important to distinguish our intent (which you described very well) from user's perception; I think there is a disconnect there.

Also, a green bar today in Firefox might not mean the same thing as it means tomorrow. Or, tomorrow there might not even be a green bar.

(IIRC, a year or so ago, our research team showed a report that indicated that a significant number of users think that Firefox is less secure than other browsers because Firefox doesn't have a lock icon--i.e. the lack of a lock icon is perceived by some people as "Firefox cannot make secure connections in situations other browsers do." This is another example of our good intent not matching users' perceptions.)

Cheers,
Brian

[Gervase Markham]

Your points are reasonable ones. However, I'm not certain that adding
OV-level O-fields to the Firefox UI (which I think was the original
subject of this thread) solves any of them...

Gerv

[Brian Smith]

I agree, and I also commented in the bug that the presence of the OV OID isn't enough.

The point I want to make is that I think there EV vs. OV vs. DV is not the only thing we should look at. I think there's a possibility that (OV + something new) or even (DV + something new) would be a better than what EV is now all by itself. But, I am not sure exactly what the "something new" is.

Cheers,
Brian

[ianG]

I agree :) but ... that "something new" depends on what the "something
else" is. Some think EV is about identity, others think it is about
security, yet others think of marketing, and others just see it as
franchise.

If we think about (just) identity, then there is a bit of a problem.
Identity is something that users are accustomed to thinking of as binary
- either we know or we don't. It's a little bit like being a little bit
pregnant, we either know your identity or we don't.

Which leaves us a problem when we think about EV vs. Ov vs. DV. Which
of those delivers the consumers' idea of identity? Whichever way it is,
the others are either insufficient or overkill and unnecessary. You
only get one stab at the identity standard.

Alternatively, we could think in terms of different statements. Perhaps
one statement is domain control, while another is business identity. Two
different things. The identity fans will point out that they are
proxies for the same thing. But that's only an approximation.

However, where it gets a bit looser is if we really decide that one is
domain control and the other is identity control, we also have to make
other differentiations ... such as why do we care? What do we get for
the extra stuff?

And that doesn't work. You can perhaps see where this is going with
code-signing. The identity fans will say that a code-signing cert
simply gives us the identity of the developer. But this doesn't work in
real life - Apple have shown that there is substantial merit (and costs)
in providing apps that come with more - some statement of acceptability.
Whatever the Apple app statement is, it works. Meanwhile, Android
marketplace has done the alternate (which is the correct decision if you
follow the marketing) which has resulted in more security issues. (FWIW,
there is a mozilla project elsewhere struggling to come up with its own
statement.)

So, let's assume that the differentiation between app-shop statements is
a good thing. Can we make it work in SSL certificates?

The answer is no. That's because the statement differentiations above
were found in the open market: iOS v. Android v. something from Mozilla
maybe v. a bunch of others. Whereas the certificate statement comes
from CABForum - and they will *only reinforce their existing statement
of EV* . In other words, they won't compete with themselves. So for
the identity fans, it's back to discussing how pregnant a DV cert is
compared to an EV cert...



iang

[John Nagle]

On 4/15/2012 12:55 AM, ianG wrote:
> On 15/04/12 06:23 AM, Brian Smith wrote:
>> Gervase Markham wrote:
>>> Your points are reasonable ones. However, I'm not certain that adding
>>> OV-level O-fields to the Firefox UI (which I think was the original
>>> subject of this thread) solves any of them...
>>
>> I agree, and I also commented in the bug that the presence of the OV
>> OID isn't enough.
>>
>> The point I want to make is that I think there EV vs. OV vs. DV is not
>> the only thing we should look at. I think there's a possibility that
>> (OV + something new) or even (DV + something new) would be a better
>> than what EV is now all by itself. But, I am not sure exactly what the
>> "something new" is.

To go back to my original point, the CA/Browser Forum has
effectively defined a 3-level system. All I ask is that Firefox
display that information in some coherent way. This is a UI issue.

There are two issues. One is the display which appears when
the user clicks on the toolbar to display cert info, and the other
is the color or icon in the toolbar.

The first issue is easier. If there's address info, it should
be displayed. Some language or indicator should indicate the level
of confidence (no OID, new OV OID, EV OID) expressed by the cert.
I have no opinion on the language other than that it should be
clear and simple.

The second issue is harder. This is worth discussing with the
CA/Browser Forum, because there should be uniformity across browsers
on this. I'd suggest, as a starting position, that if the cert
has identity info and a new OV OID, the toolbar shows the company
name, but not the green EV coloring. That's consistent with
current practice, and doesn't involve introducing a new indicator
color.

(The deeper philosophical issues of business identity are a
more difficult problem. I work on that problem, and have a
system with servers and browser add-ons devoted to it. Some of my
papers are available at "http://www.sitetruth.com/sitemap.html".
But that's another discussion.)

John Nagle
SiteTruth

[Gervase Markham]

On 15/04/12 17:59, John Nagle wrote:
> To go back to my original point, the CA/Browser Forum has
> effectively defined a 3-level system.

Well, not quite. There is DV, which is defined by a long document (the
BRs), there's EV, which is defined by a long document (the EV
Guidelines), and then there's OV, which is 'defined' by one paragraph in
the BRs, which effectively says "do make sure this info is right, chaps,
OK?".

> The first issue is easier. If there's address info, it should
> be displayed. Some language or indicator should indicate the level
> of confidence (no OID, new OV OID, EV OID) expressed by the cert.

How does a user translate this indicator of "level of confidence" into a
change in their behaviour?

> The second issue is harder. This is worth discussing with the
> CA/Browser Forum, because there should be uniformity across browsers
> on this.

The CA Browser Forum has never attempted to force browsers to
standardize their UIs, and I don't think it's about to start.

Gerv

[Eddy Nigg]

On 04/16/2012 12:39 PM, From Gervase Markham:

> Well, not quite. There is DV, which is defined by a long document (the
> BRs), there's EV, which is defined by a long document (the EV
> Guidelines), and then there's OV, which is 'defined' by one paragraph
> in the BRs, which effectively says "do make sure this info is right,
> chaps, OK?".

11.2 Verification of Subject Identity Information
If the Applicant requests a Certificate that will contain Subject
Identity Information comprised only of the
countryName field, then the CA SHALL verify the country associated with
the Subject using a verification process
meeting the requirements of Section 11.2.5 and that is described in the
CA’s Certificate Policy and/or Certification Practice Statement. If the
Applicant requests a Certificate that will contain the countryName field
and other Subject Identity Information, then the CA SHALL verify the
identity of the Applicant, and the authenticity of the Applicant
Representative’s certificate request using a verification process
meeting the requirements of this Section 11.2 and that is described in
the CA’s Certificate Policy and/or Certification Practice Statement. The
CA SHALL inspect any document relied upon under this Section for
alteration or falsification.
Forum Guideline CA / Browser Forum Baseline Requirements, v. 1.0 15
11.2.1 Identity
If the Subject Identity Information is to include the name or address of
an organization, the CA SHALL verify the
identity and address of the organization and that the address is the
Applicant’s address of existence or operation.
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.
The CA MAY use the same documentation or communication described in 1
through 4 above to verify both the
Applicant’s identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not
the identity of the Applicant) using a utility
bill, bank statement, credit card statement, government-issued tax
document, or other form of identification that
meets the requirements of Section 11.6.
11.2.2 DBA/Tradename
If the Subject Identity Information is to include a DBA or tradename,
the CA SHALL verify the Applicant’s right to
use the DBA/tradename using at least one of the following:
1. Documentation provided by, or communication with, a government agency
in the jurisdiction of the
Applicant’s legal creation, existence, or recognition;
2. Documentation or communication provided by a third party source that
meets the requirements of Section
11.6;
3. Communication with a government agency responsible for the management
of such DBAs or tradenames;
4. An Attestation Letter accompanied by documentary support that meets
the requirements of Section 11.6; or
5. A utility bill, bank statement, credit card statement,
government-issued tax document, or other form of
identification that meets the requirements of Section 11.6.
11.2.3 Authenticity of Certificate Request
If the Applicant for a Certificate containing Subject Identity
Information is an organization, the CA SHALL use a
Reliable Method of Communication to verify the authenticity of the
Applicant Representative’s certificate request.
The CA MAY use the sources listed in section 11.2.1 to verify the
Reliable Method of Communication. Provided
that the CA uses a Reliable Method of Communication, the CA MAY
establish the authenticity of the certificate
request directly with the Applicant Representative or with an
authoritative source within the Applicant’s
organization, such as the Applicant’s main business offices, corporate
offices, human resource offices, information technology offices, or
other department that the CA deems appropriate.
In addition, the CA SHALL establish a process that allows an Applicant
to specify the individuals who may request
Certificates. If an Applicant specifies, in writing, the individuals who
may request a Certificate, then the CA
SHALL NOT accept any certificate requests that are outside this
specification. The CA SHALL provide an
Applicant with a list of its authorized certificate requesters upon the
Applicant’s verified written request.
11.2.4 Verification of Individual Applicant
If an Applicant subject to this Section 11.2 is a natural person, then
the CA SHALL verify the Applicant’s name,
Applicant’s address, and the authenticity of the certificate request.
Forum Guideline
CA / Browser Forum Baseline Requirements, v. 1.0 16
The CA SHALL verify the Applicant’s name using a legible copy, which
discernibly shows the Applicant’s face, of
at least one currently valid government-issued photo ID (passport,
drivers license, military ID, national ID, or
equivalent document type). The CA SHALL inspect the copy for any
indication of alteration or falsification.
The CA SHALL verify the Applicant’s address using a form of
identification that meets Section 11.6, such as a
government ID, utility bill, or bank or credit card statement. The CA
MAY rely on the same government-issued ID
that was used to verify the Applicant’s name.
The CA SHALL verify the certificate request with the Applicant using a
Reliable Method of Communication.
11.2.5 Verification of Country
If the subject:countryName field is present, then the CA SHALL verify
the country associated with the Subject
using one of the following: (a) the IP Address range assignment by
country for either (i) the web site’s IP address, as indicated by the
DNS record for the web site or (ii) the Applicant’s IP address; (b) the
ccTLD of the requested
Domain Name; (c) information provided by the Domain Name Registrar; or
(d) a method identified in Section
11.2.1. The CA SHOULD implement a process to screen proxy servers in
order to prevent reliance upon IP
addresses assigned in countries other than where the Applicant is
actually located.
11.5 High Risk Requests
The CA SHALL identify high risk certificate requests, and conduct such
additional verification activity, and take
such additional precautions, as are reasonably necessary to ensure that
such requests are properly verified under these Requirements.
The CA MAY identify high risk requests by checking appropriate lists of
organization names that are most
commonly targeted in phishing and other fraudulent schemes, and by
automatically flagging certificate requests that match these lists for
further scrutiny before issuance. Examples of such lists include:
internal databases maintained by the CA that include previously revoked
Certificates and previously rejected certificate requests due to
suspected phishing or other fraudulent usage.
The CA SHALL use information identified by the CA’s high-risk criteria
to flag suspicious certificate requests. The
CA SHALL follow a documented procedure for performing additional
verification of any certificate request flagged
as suspicious or high risk.
11.6 Data Source Accuracy
Before relying on a data source to verify Subject Identity Information,
the CA SHALL evaluate the data source’s
accuracy and reliability. The CA SHALL NOT use a data source to verify
Subject Identity Information if the CA’s
evaluation determines that the data source is not reasonably accurate or
reliable.

--
Regards

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

[John Nagle]

On 4/16/2012 4:29 AM, Eddy Nigg wrote:
> On 04/16/2012 12:39 PM, From Gervase Markham:
>> Well, not quite. There is DV, which is defined by a long document (the
>> BRs), there's EV, which is defined by a long document (the EV
>> Guidelines), and then there's OV, which is 'defined' by one paragraph
>> in the BRs, which effectively says "do make sure this info is right,
>> chaps, OK?".
>
> 11.2 Verification of Subject Identity Information
> If the Applicant requests a Certificate that will contain Subject
> Identity Information comprised only of the

> countryName field, then the CA SHALL verify...

(More from the CA/Browser Forum about what CAs shall verify clipped.)
What the CA/Browser Forum hasn't done is to provide a consumer-oriented
description of what this means.

From a consumer perspective, the message I'd suggest is

- a DV cert is enough for a blog/forum login.
- If the site wants your money or a credit card number,
it should have at least an OV cert.
- If it's a financial institution or wants to retain
your full credit card info (including CVC), it
should have an EV cert. (Holding onto the CVC code
triggers the most stringent Visa merchant security rules.)

John Nagle
SiteTruth

[Peter Kurrasch]

Why all this talk about colors? Expecting an end user to keep track of
what behavior is best for which color--to say nothing about color blindness
or rendering issues--seems like it should be a non-starter. Instead, I
think a numerical scoring system would solve a lot of the problems/concerns
that have been raised.

Let's face it, when we are browsing around we expect a certain level of
protection or security or privacy or whatever you want to call it. If that
level can not be met, we expect to be informed. We know there are cases
where we will allow "less security" and other cases where we won't. We
know that we skip around from site to site and our focus is on what we're
doing and maybe where we're doing it but rarely how it's getting done.

I don't want to turn this into a rambling email so let me just conclude by
asking: Wouldn't a numerical score be a better conveyance of security from
the software to the user?

On Mon, Apr 16, 2012 at 1:08 PM, John Nagle <na...@sitetruth.com> wrote:

> On 4/16/2012 4:29 AM, Eddy Nigg wrote:
>

>> On 04/16/2012 12:39 PM, From Gervase Markham:
>>
>>> Well, not quite. There is DV, which is defined by a long document (the
>>> BRs), there's EV, which is defined by a long document (the EV
>>> Guidelines), and then there's OV, which is 'defined' by one paragraph
>>> in the BRs, which effectively says "do make sure this info is right,
>>> chaps, OK?".
>>>
>>
>> 11.2 Verification of Subject Identity Information
>> If the Applicant requests a Certificate that will contain Subject
>> Identity Information comprised only of the

>> countryName field, then the CA SHALL verify...
>>
>
> (More from the CA/Browser Forum about what CAs shall verify clipped.)
> What the CA/Browser Forum hasn't done is to provide a consumer-oriented
> description of what this means.
>
> From a consumer perspective, the message I'd suggest is
>
> - a DV cert is enough for a blog/forum login.
> - If the site wants your money or a credit card number,
> it should have at least an OV cert.
> - If it's a financial institution or wants to retain
> your full credit card info (including CVC), it
> should have an EV cert. (Holding onto the CVC code
> triggers the most stringent Visa merchant security rules.)
>
> John Nagle
> SiteTruth

> ______________________________**_________________
> dev-security-policy mailing list
> dev-security-policy@lists.**mozilla.org<dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-security-policy<https://lists.mozilla.org/listinfo/dev-security-policy>
>

[ianG]

On 17/04/12 08:35 AM, Peter Kurrasch wrote:
> Why all this talk about colors? Expecting an end user to keep track of
> what behavior is best for which color--to say nothing about color blindness
> or rendering issues--seems like it should be a non-starter. Instead, I
> think a numerical scoring system would solve a lot of the problems/concerns
> that have been raised.
>
> Let's face it, when we are browsing around we expect a certain level of
> protection or security or privacy or whatever you want to call it. If that
> level can not be met, we expect to be informed. We know there are cases
> where we will allow "less security" and other cases where we won't. We
> know that we skip around from site to site and our focus is on what we're
> doing and maybe where we're doing it but rarely how it's getting done.

Yes, indeed. But can you say what the above means? "a certain level of
.. whatever" ?

Try this test: You supply me that. Now I ask for double that! How do
you supply two times?

> I don't want to turn this into a rambling email so let me just conclude by
> asking: Wouldn't a numerical score be a better conveyance of security from
> the software to the user?

I'd say not, but it is worthy of debate.

The problem with numerical scores is they have to mean something - more
random than words. And CAs are extremely bad at describing what things
mean. (Go ask what DV means ... or EV. By this I don't mean what they
do, but what it means to the consumer...) If the CAs cannot describe
what something means, they can't put it into a numerical score, because
numbers automatically impose relative improvements but also semantics.

From this perspective, colours work far better. Green doesn't mean
anything - so therefore it means everything that the owners of the brand
can make it mean. This is more or less what we want, a colour-branding
approach, because fundamentally it is a semantics-free marketing
problem. Sorry to drag marketing in, you probably have to do some time
in that field or school or whatever to relate.

Certainly your point on colour blindness is an important issue.

But I think it is counterbalanced by brands being typically very strong
with colours. Quick question - what colour is Virgin? your national
flag? your favourite sports team? McDonalds arches ... I read
somewhere recently that some study claimed that 3 year olds were already
able to remember 100 brands, which might count as child abuse to some,
but it only gets better or worse as we get older.

Colours are good precisely because they are semantics-free so the brand
manager of EV can mold the brand to create the meaning over time, with
far less limits imposed.



iang

> On Mon, Apr 16, 2012 at 1:08 PM, John Nagle<na...@sitetruth.com> wrote:
>
>> On 4/16/2012 4:29 AM, Eddy Nigg wrote:
>>

>>> On 04/16/2012 12:39 PM, From Gervase Markham:
>>>
>>>> Well, not quite. There is DV, which is defined by a long document (the
>>>> BRs), there's EV, which is defined by a long document (the EV
>>>> Guidelines), and then there's OV, which is 'defined' by one paragraph
>>>> in the BRs, which effectively says "do make sure this info is right,
>>>> chaps, OK?".
>>>>
>>>
>>> 11.2 Verification of Subject Identity Information
>>> If the Applicant requests a Certificate that will contain Subject
>>> Identity Information comprised only of the

>>> countryName field, then the CA SHALL verify...
>>>
>>
>> (More from the CA/Browser Forum about what CAs shall verify clipped.)
>> What the CA/Browser Forum hasn't done is to provide a consumer-oriented
>> description of what this means.
>>
>> From a consumer perspective, the message I'd suggest is
>>
>> - a DV cert is enough for a blog/forum login.
>> - If the site wants your money or a credit card number,
>> it should have at least an OV cert.
>> - If it's a financial institution or wants to retain
>> your full credit card info (including CVC), it
>> should have an EV cert. (Holding onto the CVC code
>> triggers the most stringent Visa merchant security rules.)
>>
>> John Nagle
>> SiteTruth
>> ______________________________**_________________
>> dev-security-policy mailing list
>> dev-security-policy@lists.**mozilla.org<dev-secur...@lists.mozilla.org>
>> https://lists.mozilla.org/**listinfo/dev-security-policy<https://lists.mozilla.org/listinfo/dev-security-policy>
>>

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

[Rob Stradling]

On 17/04/12 08:55, ianG wrote:
> On 17/04/12 08:35 AM, Peter Kurrasch wrote:

<snip>

>> I don't want to turn this into a rambling email so let me just
>> conclude by asking: Wouldn't a numerical score be a better conveyance
>> of security from the software to the user?
>
> I'd say not, but it is worthy of debate.

Reminds me a bit of this...
https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[John Nagle]

On 4/17/2012 3:03 AM, Rob Stradling wrote:
> On 17/04/12 08:55, ianG wrote:
>> On 17/04/12 08:35 AM, Peter Kurrasch wrote:
> <snip>
>>> I don't want to turn this into a rambling email so let me just
>>> conclude by asking: Wouldn't a numerical score be a better conveyance
> >> of security from the software to the user?
>>
>> I'd say not, but it is worthy of debate.
>
> Reminds me a bit of this...
> https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf

There's not enough information available in a CA cert to provide
a numerical value. D&B business credit scores provide a numerical
value with a probability of getting paid, but they have extensive
data from creditors. CAs don't have such data.

I propose this for the toolbar:

DV cert: (no change)
EV cert: Business name in toolbar, green background (no change)
OV cert: Business name in toolbar, white background.

John Nagle
SiteTruth

[ianG]

On 17/04/12 20:03 PM, Rob Stradling wrote:
> On 17/04/12 08:55, ianG wrote:
>> On 17/04/12 08:35 AM, Peter Kurrasch wrote:
> <snip>
>>> I don't want to turn this into a rambling email so let me just
>>> conclude by asking: Wouldn't a numerical score be a better conveyance
> >> of security from the software to the user?
>>
>> I'd say not, but it is worthy of debate.
>
> Reminds me a bit of this...
> https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf

Yep. Common scientific problem - you can measure all these things, and
you can force everyone to run around chasing the measurements, and it is
really easy to say 256 is better than 128 ... and and and

but does that achieve anything?

Possibly, such projects are good for forcing laggards to upgrade, but
there are all sorts of side-effects. There are for example some tools
out there that refuse to allow MD5 in a root certificate, because
they've heard that NIST has deprecated MD5 and therefore all use of MD5
must disappear ... even vanity uses succumb to NIST's jihad on small
numbers.

Better value in those projects has been found from others examining the
certs and coming to varied conclusions that are subject to peer-review.

Has anyone been following the recent SHA2 v. SHA3 debate where people
are having second thoughts? What are we going to do when NIST declares
SHA3 ... and the cryptographers know it isn't any worthwhile improvement
over SHA2?



Perhaps we ought to run a CA semantics measurement project :) Cat, meet
pigeons....



iang

[Peter Gutmann]

ianG <ia...@iang.org> writes:

>Has anyone been following the recent SHA2 v. SHA3 debate where people are
>having second thoughts? What are we going to do when NIST declares SHA3 ...
>and the cryptographers know it isn't any worthwhile improvement over SHA2?

>From experience in sitting in on decision-making meetings in large
organisations over this sort of thing in the past, I have the feeling that if
NIST decrees we're all going to be wearing paisley this year then paisley it
is. "The USG sez so" carries a lot more weight than... actually the sorts of
people who make these decisions probably don't even know that the
cryptographers exist, let alone that they're suggesting we can still stick
with SHA2. At the mgt./decision-making level it's a fashion show, not an
engineering issue.

Peter.

[Kyle Hamilton]

On Tue, Apr 17, 2012 at 10:10 AM, John Nagle <na...@sitetruth.com> wrote:
> There's not enough information available in a CA cert to provide
> a numerical value.  D&B business credit scores provide a numerical
> value with a probability of getting paid, but they have extensive
> data from creditors.  CAs don't have such data.

It's not just Dun&Bradstreet, there's another credit reporting agency
which uses DUNS numbers to associate business credit reputation with
business identity. But your point is well-made, and I also made that
point last night on IRC.

> I propose this for the toolbar:
>
>  DV cert: (no change)
>  EV cert: Business name in toolbar, green background (no change)
>  OV cert: Business name in toolbar, white background.

Please, can we also consider the problem of locally-trusted CAs? I
have no problem with updating trustlist presentation, but we really do
need a different presentation for non-trustlist CAs.

The reason: There is a business case to set up strong credentials
which associate only with the business's web site. It appears that,
at least for the moment, individuals are not going to spend the time
and effort to form a new business contract with another party who
takes all of our personal information and put it into a single blob
for everywhere to see. Worse, that blob is, in current deployment,
transmitted in the clear *everywhere*, so there are no private
conversations, only secret, identity-tagged conversations.

And the sovereign states have decreed that they don't need
identity-tagged encrypted streams, and have also decreed that nobody
else can use those identity tags for any purpose not authorized by the
principal either.

Instead, why not allow e.g. slashdot.org to run its own certifier for
binding of public key to account identity? Why force everyone to use
ONLY full-validation certificates or certificates which have their
email addresses, when the users aren't going to get off their duffs to
get them? It makes no sense, and there is no business case to mandate
that users get authoritative CA certs from X.500-only shops. We don't
have to be certified by anyone in order to communicate with each other
offline, we don't have to be certified to send unencrypted email, and
we don't have to cooperate with anyone (especially CAs!) we don't want
to include in the conversation we're having.

Why has user certification not recognized and worked with reality
instead of swimming so resolutely against it? X.500 is harmful in
this sector, because it assumes that there is an "authority" which is
capable of imposing mandatory communications channels. X.509 is
useless for anything in the consumer sector because there is no
authority to impose or mandate anything, especially the creation of a
new business contract.

In the eyes of the law (at least in US), every individual is
effectively an independent sole proprietor. This means that every
consumer is a business, and every business has the responsibility to
evaluate potential offerings to ensure that they don't waste their
resources on frivolity. There is no wonder why nobody gets certified,
it's because it's a hideously unintuitive and unnatural process that
has no analogue in real life. Even our drivers licenses have more
restrictions on their usage than the data in CA-issued certs.

(Mozilla trust-list CAs are not governments, and so [in the absence of
a contract with some government] cannot claim that they issue
government credentials like the Departments of Motor Vehicles or
Secretaries of State of the various sovereign states. Nobody's going
to stand in line 3 hours at a private identify verification shop like
they will at the DMV. The mandate that "every certificate that The
Browser touches must either be Trusted For Everything Including
Authoritative Identity Information or Not Trusted At All" is the
single largest barrier to private acceptance of strong authentication,
and it simply cannot be overcome without scrapping said mandate.)

-Kyle H

[John Nagle]

Some of the UI issues in this area may simply be out and out bugs,
not policy issues. Try

https://easyabc.95599.cn/commbank/netBank/zh_CN/CommLogin.aspx

Firefox 11.0 displays a grey dashed square next to the URL.
Yet the site is presenting a Verisign EV cert. Firefox reports
no errors.

Mozilla says "This website does not supply ownership information",
which is flat wrong - the cert has O, OU, and L fields, and
a certificate policy ID of 2.16.840.1.113733.1.7.23.6, which is
the correct OID for a Verisign EV cert.

CN = easyabc.95599.cn
OU = Terms of use at www.verisign.com/rpa (c)05
OU = ABC Ebank Websites
O = Agricultural Bank of China
L = Beijing
ST = Beijing
C = CN

This situation is confusing enough that there's a discussion
on PhishTanks's mailing list over whether this is a phishing site.

John Nagle

[John Nagle]

On 4/19/2012 1:13 PM, Eddy Nigg wrote:
> Additionally for my personal
> taste such a domain doesn't give me an overly confidential feeling,

95599 is their well-known phone number within China. The
major banks in China have 955xx numbers.

John Nagle

[Peter Gutmann]

<Carsten.D...@t-systems.com> writes:

>Using the firefox Nightly after a second the UI shows the green EV bar
>(saying " Agricultural Bank of China") - but after another second it
>disappears and falls back to the situation you described. Now the UI says
>"your connection to this site is only partially encrypted".

That's what I got as well, using 3.6.28. I have no idea what this behaviour
is supposed to be conveying to users.

Peter.

[John Nagle]

What seems to be happening is that the Agricultural Bank of China is
taking their systems down for three days (!) to switch to a new system,
and we have all been looking at their site while it was partially down.
Their site is currently returning the following message:

Dear Customer:

In order to provide more convenient and efficient services, the Bank
intends April 18, 2012 (Wednesday) 20:00 to April 21 (Sat.) 20:00
electronic banking system upgrade and maintenance.
....
(A) April 18 (Wed) 20:00 to April 20 (Fri) 20:00, personal online
banking payee maintenance related services will be suspended.
....
Please make proper arrangements for the business processing time.
.... For help, please call our Customer Service Hotline: 95599.

Agricultural Bank of China
April 16, 2012


John Nagle
SiteTruth