Gervase Markham wrote:
I suggest to keep the framework and the UI apart currently; Except that the first doesn't imply the second automatically. For example the UI can present only three of them in a different way should we come to that conclusion. Or the fourth level is only presented differently in mail clients and for the signing of documents. There are many ways and options possible.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.
I have the feeling you are simply trying to discredit me unnecessary! The only thing I proposed in relation to the UI is, to provide the information which mainly exists already in a more prominent and easier way. Was this *that bad*?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. :-|
I think we agreed to leave the UI implementation for now to Jonathan and his team? Maybe they find a way doing exactly that, e.g. explain to your mother the impossible...And if they do, will this convince you?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.
And it seems to me, that you have no clue about what CAs do really! It's like saying that there are browsers and there is software...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).
Many others consider it a type of verification. For example your friends from Paypal do. Many other institutions do. CAs do (Including Verisign, Thawte). It is a way to verify without meeting in person. Agreed it's not as strong as a personal meeting, but this is not always feasible, convenient, possible and the right thing to do. But perhaps exactly that's why we labeled it as the second level, compared to Level 3 or 4. There is reasoning behind everything, if you just would pause for a second and think!Perhaps not. I don't consider photocopied documents to be a verification.
Common, are you on purpose pretending you don't understand? The proposal is exactly about defining everything better, shouldn't you have realized it. It does exactly that! It is auditable! In fact, most CAs wrote their policies and practices exactly this way and were audited this way! The proposal defines exactly what is less and what is more! You pretend like everything is helplessly broken, but thanks...this is not the case. So there are problems, they are related first and foremost on the *missing definitions* at browsers!!!!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.
It's not so good, because there was never a definition and a structure as the one we proposed. The problem up to date was *never* the audit, but that the browser never could handle anything different than binary and flat SSL. The CAs offer different verification procedures for years...perhaps read some CA policies and practices for your general knowledge! Start with Verisign, than Thawte...Indeed. And the situation today is not good.
Mozilla does it, please read http://www.mozilla.org/projects/security/certs/policy/Who is going to define what this minimum level is,
and write the audit criteria?
They exist already, for example any of these:
* Annex B, "(Normative) Certification Authority Control Objectives",
of ANSI X9.79-1:2001, Part 1: PKI Practices and Policy Framework
<http://www.x9.org/catalog2.cfm?item_no=%24%23%20%2F%217%20%21O%0A&pub_item=%2334%2A%3B%0A>;
* Clause 7, "Requirements on CA practice", in ETSI TS 101 456 V1.2.1
(2002-04), Policy requirements for certification authorities
issuing qualified certificates
<http://pda.etsi.org/pda/home.asp?wki_id=vRB.0b.A2uoprrwvH-WyI>
(as applicable to either the "QCP public" or "QCP public + SSCD"
certificate policies);
* Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V1.1.1
(2002-04), Policy requirements for certification authorities
issuing public key certificates
<http://pda.etsi.org/pda/[EMAIL PROTECTED],.QCFnV>
(as applicable to any of the "NCP", "NCP+", or "LCP" certificate
policies); /or/
* "WebTrust Principles and Criteria for Certification Authorities"
in AICPA/CICA WebTrust Program for Certification Authorities,
Version 1.0
<http://ftp.webtrust.org/webtrust_public/tpafile7-8-03fortheweb.doc>.
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?Sorry? I think you got it all wrong! Who said you need to have an extra audit? Auditors audit the CA policies and practices. Nothing different here. The levels exist mostly already in practice, or the CA issues only some of the levels. The only difference will be, that the Mozilla CA policy is defining different levels and have the CAs mark certificates accordingly. I never ever said, that there is a need for a different or additional audit for the CAs. The current audits serves this purpose enough!
Exactly the opposite is the true. EV is a reinvention of *one level* of current CA practices.Surely this is just reinventing EV?
-- Regards Signer: Eddy Nigg, StartCom Ltd. Phone: +1.213.341.0390
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
