Eddy Nigg (StartCom Ltd.) wrote:
Before you can do anything with the UI, there needs to be an underlying
framework and policy defining it. In this proposal it's actually more
than that, it's a re-definition (or definition which exists mostly in
practice at CAs, but not at the software) of how SSL certificates should
be treated from now on. Once this is part of the Mozilla CA policy (and
hopefully other vendors might follow the lead) an eventual UI proposal
could be worked out. The UI can take many colors and shapes, but without
the underlying framework no UI can do much...Please note, this is not
about code, but about policy shaping...
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.
You explain the levels well in terms of the validation performed.
However, as this is at heart a UI proposal, how do you suggest (in
terms of concepts, rather than in terms of pixels) these levels should
be presented to the user?
No idea yet...and as it was suggested previously, that there are some
smart people on board for this, however once we get to it, I'll make my
recommendations...trust me on that one ;-)
With all due respect, Eddy, having read your UI proposals in the past,
I'm far from willing to trust that you have something incredibly usable
up your sleeve. :-|
For example, my mother is considering using her credit card at a shop,
and the UI indicates (in some way) that it is level 2 secured. Should
she shop there?
I've visited a site that I think is my bank, and it has a level 4
certificate. Should I be concerned, given that level 4 is normally for
individuals? How concerned?
As I indicated in the proposal, this is something we will have to work
on and define exactly what we want.
But this is the entire point of the proposal. If it's impossible to
explain to my mother why there are four levels, and what the differences
are between them, and what she should do in each case, then there's no
point in having four levels.
Why four levels, rather than six? Or two? Or ten?
Good question! The current proposal has been more or less common
practice at many CAs (including Verisign and StartCom) and I view it as
an almost de facto standard.
It seems to me that current CA practice is that there are two levels -
domain-validated, and "something better" (which varies from CA to CA).
Except that, I think that two levels is not enough, specially as the
second level is expected to be for a small minority of subscribers, as
in the case of EV, this is currently for registered organizations,
server certificates only.
But that will change soon.
The identity is validated by various means, such as verification of
the identity via scanned, photocopied or photographed photo ID
documents (passport, identity card, driving license) and company
registry, which is then further verified by a lookup at a third
party source, such as phone directories and phone call or sending of
a registered mail to the address found in the documents provided by
the subscriber. This kind of verification is not done in person.
Ownership of the domain name, resp. email account is performed
according to Level 1. The certificate must state the subscriber
name/organization name, locality, state (where applicable) and country.
So for individuals, the certificate contains address information which
is unverified?
Who said that it's unverified? Perhaps read it again? Or I might have
been not clear enough here?
Perhaps not. I don't consider photocopied documents to be a verification.
How does your proposal ensure that the CAs stick to what they have
promised - i.e. that the OID they put in the certificates corresponds
to the level of validation done? Do we just have to trust them?
Actually yes.
Then we will have exactly the same problem as now - without an auditable
standard of verification, CAs will do less and less of it while claiming
to adhere to the letter of the standard.
In my proposal this is exactly the case, the same as today
Indeed. And the situation today is not good.
Mozilla trusts the CAs, that they adhere to the Mozilla Ca policy, which
defines in that respect also a minimum level of verifications for
example (confirmed by a third part audit).
Who is going to define what this minimum level is, and write the audit
criteria? How are we going to persuade CAs to pay for the audit we want,
when they already have to pay for WebTrust and EV audits? Surely this is
just reinventing EV?
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
