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.
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. It should be defined so
that we can later add levels, though, and not only on the top and bottom.
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.
Agreed.
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.
Agreed.
Eddy *explicitly* said the definition of the levels can be changed based
on what Mozilla wants.
Eddy's current proposal simply accepts what CAs do. Advantage: Fast
implementation. Disadvantage: Letting them define the standards, missing
a good positive argument for them to change.
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.
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.
I think the webtrusty audit includes adhering to their own standards.
And the standards for each level for each CA are public. What changes is
that right now, they make up the levels and can change them at any time.
With Eddy's proposal, they would be bound to *our* definition of the
level (which may or may not conveniently match *current* CA definition).
If they fail to adhere to their own standards, webtrust and co would
probably fail. If they change their published standards, we should notice.
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?
It's *already* part of webtrust audits, as far as I know, and it's not
reinventing EV. For both, see above.
--
When responding via mail, please remove the ".news" from the email address.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
