L. David Baron wrote:
On Wednesday 2006-11-01 22:54 +0000, Gervase Markham wrote:
The guidelines have been developed via a very long and drawn-out
process, including several face-to-face meetings with competing
specifications from different groups of CAs over the past two years.
Eventually and quite recently, a Microsoft employee synthesised a
unified specification, which has now been made available for public
comment. The latest draft of this document can be found here:
http://www.cabforum.org/EV_Certificate_Guidelines_-_Draft_10-2...pdf
After skimming some parts of the draft, my biggest concern here is
the tension between B.2.a.1 and B.2.c.3, and its implications on
when certificates would be revoked.
In particular, I think misrepresentation of identity within a Web
site that uses an EV cert must be grounds for revocation.
I agree; does any part of the draft say otherwise?
For example, suppose a company is formed called "Washington Banking,
Inc.", and they apply for and obtain an EV cert under that name.
They then write a Web site that uses the name and logo of Washington
Mutual as part of a "phishing" attack. What percentage of consumers
would know that the legal entities behind the bank they know as
Washington Mutual are (based on the contents of
http://www.wamu.com/personal/default.asp ) "Washington Mutual Bank",
"Washington Mutual, Inc.", and other legal entities, but not
"Washington Banking, Inc"?
Not many, I agree. However, in order to correctly spoof WAMU (at least
in the IE 7 UI) they would need to incorporate their fake company in the
US. And, if they did that, the information gathered during the EV
process could be used to track the applicant down and prosecute them.
It seems like this spec overemphasizes the concept of "legal entity"
when the real problem here is misrepresentation of identity. So
shouldn't misrepresentation of identity, within any Web site served
using an EV cert, be grounds for revocation of that cert? In other
words, it seems to me that B.2.b.1 should be a primary purpose of EV
certificates, and B.2.a.1 should be secondary.
Also, what's the time scale of the average phishing attack? Are the
revocation guarantees in the spec (G.26.a) actually useful, or will
the attack be mostly over by the time anything is usefully revoked?
This was a matter much debated. G.26.a gives minimums; I would hope that
CAs would do substantially better in practice.
The Mozilla project as a whole needs to decide whether EV will make a
material difference to the reliability of information in certificates
and, if so, whether that warrants a different UI presentation for EV
certificates. It would also be good to have a more general discussion
about how we present security information to users.
Presumably the idea here is that we would have a process for
determining that root CAs on our list are also valid EV root CAs,
and mark them as such?
The idea would be that, as an initial position, we would list all those
CAs which have passed an EV audit as valid. We would then track that,
diverging only when we had information that a particular CA was not
meeting its EV obligations between audits.
Would we need a policy for determining which
CAs should be so marked? I'd think we should have a clear policy
for this, and for when we would *un*-mark a CA. And I think we
should have that clearly defined before we start doing anything with
EV certificates, and make it clear in advance that if CAs do any of
the things that we said would make them be kicked out of our root CA
list, we'd actually do it.
I would anticipate that the primary sanction would be removal of EV
status, rather than being completely kicked out of the root list. This
latter, nuclear, option has been theoretically available to us for
existing CAs under the current system, but we have never contemplated
using it - because removing e.g. Verisign would break half the SSL sites
on the web.
One of the advantages of EV is that it provides us with a meaningful yet
less nuclear sanction whereby the CA is the one that gets in hot water -
because their customers who forked out for EV certificates start
shouting at them because they are no longer displayed as EV in Firefox,
and their Firefox-using customers are ringing them up to ask why, and
whether they should carry on trusting their site.
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
