> Any "defensiveness" is no doubt due to the fact that trust in the system > is shared between all participants - lose faith in one CA, and you lose > faith in all CAs. In that sense, existing CAs - particularly entranced > ones - have incentives to improve the state of the trust and security in > the overall system Disagree. They don't have an incentive. In fact, it has been shown that bad behavior is acceptable, which is an implicit encouragement.
Mozilla and Microsoft (and et al) set a horrible precedent. I know its Microsoft too because I personally filed the bug report against Trustwave. Jeff On Sun, Jan 6, 2013 at 1:48 AM, Ryan Sleevi <ryan+cryptogra...@sleevi.com> wrote: > On Sat, January 5, 2013 10:10 pm, John Case wrote: >> >> Jon, >> >> Many thanks for this very informative post - really appreciated. >> >> Some comments, below... >> >> >> On Sat, 5 Jan 2013, Jon Callas wrote: >> >> > Now that $250K that I spent got an offline root CA and an intermediate >> > online CA. The intermediate was not capable of supporting workloads that >> > would make you a major business. You need a data center after that, that >> > supports the workloads that your business requires. But of course, you >> > can grow that with your customer workload, and you can buy the >> > datacenter space you need. >> >> >> You're the second person in this thread to mention hardware and datacenter >> costs ... and while I don't want to drift too far into a blood and guts >> sysadmin rundown, I am curious... Are you talking about the customer >> facing, retail side of things with the webservers and the load balancers >> and all of the things that make a "robust web presence" or are you talking >> strictly the x.509 components ? >> >> Because it seems to me (naive ?) that even a very high volume x.509 >> signing operation is ... maybe a pair of good 1u servers and a rack at a >> decent (sas70/pci/blah/blah) datacenter ... ? Ok, a firewall and maybe >> some IDS system ... but we're still only a handful of 1u boxes and a >> quarter of a rack... >> >> Perhaps it's this kind of thinking that leads to failed audits :) > > It will, it does, and the information is readily available from the > previous post. > > https://www.cabforum.org/Baseline_Requirements_V1_1.pdf Sections 14 > through 16 > > Additionally, https://www.cabforum.org/Network_Security_Controls_V1.pdf > describes a series of controls jointly developed by the browsers and CAs. > While I'm not aware of any Browser program requiring them *yet*, I think > any person concerned about the trust online would say "Yes, these are all > sensible requirements" - stuff that should be obvious for any entity > granted the ability to affect global Internet trust. > > You can further find the details of the *existing* requirements for > Physical Security by looking through the recognized Audit programs, such > as WebTrust. See http://www.webtrust.org/homepage-documents/item54279.pdf > - in particular, Sections 3.4 and 3.5 > > Is it a perfect system? No. But even if the CA/Browser Forum is not fully > open (yet?), improvements can certainly be made to and through Mozilla, > given the openness and transparency that they maintain with their root > certificate policies. > https://lists.mozilla.org/listinfo/dev-security-policy as always - where > you can discuss things such as Mozilla's proposed policy changes, > http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html > >> >> >> > There are rumors, which you've read here about how there are lots of >> > underhanded obstacles in the way of becoming a CA. My experience is that >> > the only underhanded part of the industry is that no one in it dispels >> > the rumors that there are underhanded obstacles in your path. This is >> > pretty much the first time I have, so I suppose I'm as guilty as anyone >> > else. >> >> >> That's nice to know, and I'm heartened that all the way into 2012 this is >> still the case, but ... boy oh boy does this look and smell like a >> marketplace ripe for monopolization and a cartel ... it's almost a classic >> case. >> >> I think the presence of a major browser that is a community, independent >> effort is an interesting wrinkle, and the fickleness of the browsing >> public (how fast did chrome shoot up the charts ? Safari ?) adds a >> wrinkle too, but ... there's no way the large, entrenched players aren't >> sitting around thinking "gee we have a nice thing going here..." Not a >> conspiracy theory, just common sense... > > You're disregarding the dynamics at play here. The CA's don't set the > requirements - the browsers do. > > Yes, the browsers take input from the CAs, but they also (and in > particular, Mozilla) take input from their constituents. Whether you're a > closed-source vendor listening to your customers or an open-source > organization with a public process, there's still a great desire from the > browser vendors to engage the community. Nor is it in the browser vendors' > interests to ignore their users or their users' security. I don't think > any browser wants to be known as the *less* secure browser - we're all > jockeying to be *more* secure, especially where it matters most. > > Any "defensiveness" is no doubt due to the fact that trust in the system > is shared between all participants - lose faith in one CA, and you lose > faith in all CAs. In that sense, existing CAs - particularly entranced > ones - have incentives to improve the state of the trust and security in > the overall system - the same thing users and browsers want most as well. > If the cost of improving the controls and security of the system is that > it means excluding CAs that are not prepared for the solemn public trust > that comes from being in the root stores, then that seems like a win for > all concerned parties. > > I'm not trying to write an apologetic for the process or the system we > have - I think there's real room for improvement, and I think the system > that we have now is hardly the best that we can do. And while I share more > than my fair share of paranoia - which is why I think proposals such as > Sunlight/Certificate Transparency are so important - I don't think it's > fair to wildly speculate. > > Hopefully, you'll take the information presented here as the basis for > further research - and as you see opportunities for improvements to the > process, share them. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
