I'm just going to point out something that a couple of friends recently pointed out to me. The business models of commercial CAs involves what is essentially "selling trust".
If you look at the fact that they have no real accountability, no procedure in place in any of the browsers to revoke their trust as a matter of policy if they violate their CSPs, and a need to maintain a positive cash flow, you will quickly see that there are severe conflicts of interest inside the individual organizations. (If you don't believe my assertion that there is no means to remove root certificate trust as a matter of policy, I am still waiting for action on Thawte's issuing of SSL123 certificates by a root which had a CSP which stated that no SSL server certificates would be issued without at least "medium assurance" of identity. This issue was brought up before I moved to my Mac as my primary machine, so over a year and a half ago.) Frankly, this entire discussion is utterly and disgustingly ludicrous in light of this. Add to this the fact that there is no legal recourse available for "relying parties" if the CA somehow fails to live up to its CSP, and the entire argument falls completely on its face. You all seem to be frighteningly disconnected from the realities of the situation if you're still arguing the minutae of trust models allowed by CSPs. I lost my faith in the process you're trying to follow long ago. -Kyle H On Feb 9, 2008, at 6:19, "Eddy Nigg (StartCom Ltd.)" <[EMAIL PROTECTED] > wrote: > 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 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
