Gervase Markham wrote: > Eddy Nigg (StartCom Ltd.) wrote: > >> So it would be fine with you, if you've received a signed document or >> email (even encrypted) and you are going to trust your VISA and other >> personal data to a spoofed email or web site, issued by such a Blackbox >> CA? >> > > It wouldn't be fine with me; my point is that (speaking as the Mozilla > Project) it's Not Our Problem. LOL.....of course it's your problem, because you know upfront that any such CA is potentially compromised right from the start. If this CA gets accepted without requiring changes to their commitment and procedures, this is exactly what Mozilla is going to approve - knowingly and willingly! In this case Mozilla will breach indirectly its own policy perhaps the first time - because adherence to various parts of the conditions put forward in that policy can't be even assumed. > When the customer finds out there's a > problem, he should revoke his cert, and our products should honour the > revocation - just as for any compromised cert. The customer is the one which hasn't cared for securing adequately in first place, the issuing CA being the one not bothering to control its intermediate CAs...and you still believe that they A) Find out about an intrusion and compromise, B) Also bother to revoke it (with all the hassle which might be involved? This makes me laugh... > > You don't need to invent a long scenario. Simply: disgruntled bank > employee steals private key and, using it, steals customer data. How is > this different to them stealing the private key for the bank's email > signing cert? Or web server cert? > That's "The One Private Key Of The One Server" compared to any kind of issued certificates, possibly without leaving a trail to whom it was issued...and most likely there isn't "The One And Only Email Cert Of The Bank", but perhaps hundreds of them... > The point is, it's not the problem of the Mozilla Foundation to make > sure that the First International Bank of Thailand has good security, as > long as any breaches of it can only affect the FIBOT and its customers. > It can affect anybody! I'm not aware that there is a limitation placed who can be a relying party... > > Yeah, life sucks, doesn't it? > Oh no, I don't think so ;-) > All of your scenario could still happen if we forced the CA to make the > FIBOT sign some contract about keeping their key safe. No, there is a contract between the two parties. However nobody is going to control and verify the implementation of that contract. That's my point here. > Just because > there's a contract doesn't mean the FIBOT would keep to it; even if they > did, that doesn't mean that no insider has a copy of the private key. > But if the CA verifies the procedures in place for securing the CA system, access control systems and regulations (preferable foolproof as possible), create the private key together with a representative of the CA together with other witnesses (called a signing party in CA jargon), than one can expect a better and more secure system out there. Of course I'm touching here only the basics of proper subordinate CA implementations hosted at an external location.
-- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
