Gervase Markham wrote: > Eddy Nigg (StartCom Ltd.) wrote: > >> But back to our issue, if a compromised server issues a certificate from >> within the name constraint and uses it to attack another user (by >> claiming to send mail from [EMAIL PROTECTED] or setting up a fake >> site for https://really.allowed-domain.com), this would be the classical >> MITM vector SSL is meant to prevent. Hence it doesn't matter really if >> there is or isn't a name constraint, just the range of possible attacks >> is limited. >> > > As I understand it, if a Blackbox customer loses control of their > private key, the only person who has a problem is that customer (their > websites and email can be spoofed). 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? Is it really, really only the problem of the customer?
So lets play with it a little bit: Take #1: The "First International Bank of Thailand" is the proud owner of a Blackbox CA root with naming constraints for only their domain names for emails . The bank hosts it's server, an oldish Pentium, in the kitchen room under the kitchen sink where the staff makes their coffee in the morning hours. Nobody cares about this little server, not the bank and not the issuing CA. The server reports every day to the issuing CA about the certificates it issued to the parent CA through the software which the bank IT stuff received over Internet downloaded and dutifully installed. Take #2: The bank also contracted a manpower company for cleaning their offices during the night. Now every night the cleaning boy, hired by the manpower company, is visiting our nice little "Kitchen Sink CA". During the day he is studying at the University of Thailand, during the night he earns some money to finance his studies....but soon he will have another nice income. Take #3: Our cleaning boy is a smart person and learns about our little CA server. He takes his time during his nightly visits and learns the system and also that there is no hardware intrusion detection. He creates a perfect image of the disk, which is btw. unencrypted and starts issuing client certificates in the name of the bank of Thailand. Once finished, he returns the server to its initial state. During the day our little server keeps ticking as usual and is dutifully sending its audit report to the issuing CA. Take #4: Gerv and Frank, both tech savvy and long standing customers of the bank are used to receive correspondence from the bank via emails signed with a digital certificate. Gerv and Frank always check the digital signature and know it's issued from a CA their software trusts. So they don't get suspicious the day they receive an email requesting some information. However they don't know that they are in fact sending their social security number and VISA number and (insert whatever you want here) to our ambitious friend, the cleaning boy. Take #5: The cleaning boy is now busy during the day with sending emails to the customers of the bank and selling the information to the hAckrz gr0up of China. And so the personal details of Frank and Gerv are floating around....After a while they realized that their information has been compromised, however they don't suspect anybody initially, certainly not their trustful bank. Only after a long time and after many affected customers of the bank, is the bank suspected. It takes even longer to suspect our cleaning boy and month pass until this successful scheme is stopped. Take #6: The issuing CA doesn't takes any responsibility, because they acted perfectly according to their own policies. They never promised auditing of the systems and customers in first place. The bank of Thailand has its "Kitchen Sink CA" suspended, the IT manager fired, but Frank and Gerv have no way to prove that their privacy was invaded and that they potentially lost some money because of the bank's actions. Also the bank has much better lawyers, so Frank and Gerv never recover the damage. Conclusion: A compromised CA can affect any party involved, even for client certificates and even with name constraints. Of course you understand that the above is just an example and can be played in many different ways.... > So it's in their best interests to > keep it secure, and I'm sure WISeKey will make that clear to them. > And what if not? There is nobody going to control and verify that. There are no guaranties given. This simply isn't how CAs work. You don't build the trust on assumptions and goodwill, but by implementing controls. Not even speaking about multiple locations for CRLs for the case the CA server is down and other issues, which is simply not worth investing the time right now... > The point is that their security destiny is in their own hands. No, not at all! It's _your_ security in _their_ hands - because you rely on it. Also note that the CA is as strong as its weakest link. NSS and the software which make use of it are as weak as its weakest CA. Mozilla has a established a policy to define exactly what the weakest link is going to be in order to protect its users. (In relation to that, there is currently an article published at Netcraft's Secure Server Survey: http://news.netcraft.com/SSL-Survey/ (Scroll down to StartCom), which was viewed back then perhaps as the weakest link ;-)) > This is > not like a root CA key compromise, where even people who aren't > customers of that CA can be affected. > For CAs which need a PKI implementation for their internal use, they should use only a self-issued CA root, which they decided to trust. If others from outside that circle should be able to trust those certificates and if the CA has a relevance for users of Mozilla products, than that root must conform to an accepted norm and security standard. There must be a line drawn between these two cases, either it has relevance for the users of Mozilla and in that case is a relying party with all its implications or it has no relevance to the users of Mozilla products and mustn't be part of NSS! It can't be both IMO. > >> CAs which issue sub CAs without taking responsible actions to control, >> verify and guide them, are suspected to being compromised right from the >> beginning. Without insisting on this, we can just stop reviewing CAs >> altogether and save us the hassle... >> > > There's a difference between "sub-CAs" (where your point is valid) and > "sub-CAs with name constraints" (where I suggest that it is not). > > In which case it perhaps shouldn't be there anyway, see above. -- 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
