[EMAIL PROTECTED] wrote: > The revival of the "Class 1 cert discussion" shows a different issue: > Further distinction based on the level of authentication is required.
Agreed - one solution would be if this wasn't a binary trusted/untrusted setting. My take on the situation is that StartCom has complied with the stated policy. Therefore, as a matter of policy they should be included. This shouldn't be a matter of whether individuals like or don't like them. Now, an RFC-period is only sensible just in case somebody wants to point out somewhere where they really don't comply with the policy. I don't see anything in the policy about requiring manual credential-checking - therefore it cannot be a hidden requirement for inclusion. In fact, once mozilla starts adding its own checks to the independant audit, it becomes more liable for issuing certs, as it is no longer just relying on a trusted outside agent. Imagine if webtrust passes somebody who turns out to be fraudulent. If mozilla has done extra checking on some CAs, but not others, then mozilla has to explain in court why they let this one slip through without the extra check. On the other hand, if mozilla just accepts webtrust as the gospel then they can simply point to best practices and explain that if webtrust missed the problems, how could they be expected to find them. I think the multiple-trust-level issue is an important one. For example, if I'm going to just visit an SSL-protected website, such as a web forum in general, my main concern is that there hasn't been a man-in-the-middle attack, and that my passwords aren't being sniffed. I don't care who owns miscwebforum.com - just that my traffic is in fact going there. An SSL cert which only indicates that the cert was issued to that domain is fine (although I would prefer that the cert is issued in a manner to ensure that somebody can't hijack the domain for 10 minutes and get a cert - there should be a waiting period to ensure control of the domain). On the other hand, if I'm about to buy something from a site then I want to know who I'm giving my money to in real life, and that requires a higher level of certification. In the web-of-trust model, if I'm just chatting with somebody via email I really don't care if their PGP key is associated with a particular human being - I might never meet the real human, so my main goal is that this digital persona I'm chatting with is the same one I've been chatting with all along. On the other hand, if I were to engage in a contract with somebody, then I'd want to do a check to ensure that the person is who they say they are if I've only known them via email. Of course, the key to getting this right is making it easy for regular users to understand. Obviously the binary trust/don't trust is as easy as it gets - but it also exposes mozilla to the most legal risk for making the determination. Maybe another model might be "ok for casual use" vs "ok for commerce" - and have a higher standard for the latter (and maybe a relaxed one for the former). You could even have warning signs pop up if the user looks like they're about to submit a credit card number using a form for a less-trusted cert. You could require that CAs have a notary verify identity on all issued safe-for-commerce certs, and that the CA check with the local government and notary to verify the seal of the notary. That would prevent the MS fiasco, or at the very least would get local law enforcement very interested in forgery of notary stamps. However, for non-commerce-oriented sites this is just a needless expense. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
