Ben Bucksch wrote:
Gervase Markham wrote:
Right. But if you have four levels in the infrastructure, that sort of
implies four levels in the UI. And if it turns out that four levels in
the UI is impossibly confusing, then having four levels in the
infrastructure is unnecessary.
Not really, you may want to treat some levels (including self-signed and
plain HTTP, which kind of makes it 6 levels with this proposal) the
same. Or you may want to show the difference on request. Or, as Mike
Beltzner said, may simply want to add indications, e.g. show
'encrypted', a higher level adds real name, an even higher level adds
street address etc. - this is very clear and understandable for users.
It's understandable in the sense that yes, a user can understand what a
real name is. But it's not understandable in terms of translating it
into what the user is supposed to do or not do.
For your average person on the web, "security" means one or more of:
- Can I shop here without my credit card number being sniffed/stolen?
- Is this my bank or not? Can anyone else see what I'm doing or get my
password?
Now, we may not be able to provide cast-iron guarantees - just as, even
though Gap is a reputable clothing store, it can't guarantee that a
rogue employee hasn't cloned my credit card if I walk into one and buy
something. I think that's understood.
But our UI needs to be focussed on helping them answer those questions.
And our backend needs to support that UI.
Yeah, this would need to sort of reflect back on the policy, so it's
hard or useless to talk about such info in a void, without use-case,
much less UI. Eddy, maybe you can add use-cases, both from side of cert
applicant and end-user, and *maybe* even browser. I.e. for what would I
get which cert, or for what would I trust which cert. However, I
nevertheless think that Eddy has a strong point when saying that his
proposal reflects current use, which means that we can implement it
without too much trouble changing CAs around.
Except that it would be an enormous amount of effort. There are 44 CAs
currently in Firefox, and 20 more in the queue. Each may have between
one and ten different products. All these products would need to be
allocated levels, and the CAs would need to change their issuing systems
to add the new OIDs. And, as I believe I'm going to get to further down
the thread, there is no auditing to make sure the CA was honest in terms
of doing the correct amount of verification anyway.
Eddy's proposal is anything but "not too much trouble".
The core idea of Eddy's proposal was not that, though, but to introduce
the *concept* of different levels of certs, with current technical
standards, and more generically than EV.
But EV is backed up by audit. Eddy's proposal is not.
(Note: as you probably know but others may not, the standard WebTrust
and similar audits only verify that the CA does what they say they are
going to do. They do not audit the _level_ of verification performed. If
I say I'm going to do no verification, and do none, I pass the audit.
This is one of the big drivers behind EV.)
I think the webtrusty audit includes adhering to their own standards.
And the standards for each level for each CA are public.
Except that analysing and classifying all those products from all those
CAs, and keeping up with changes, is a Herculean job. The Mozilla
Foundation neither has the manpower, the time nor the inclination to pay
CA Cop. This is one reason EV is good. One standard, high level, audited
by third party auditing firms. We just have to ask: "Do you have a valid
EV audit?"
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
