womble

Little known fact: "Pulumi" is a Zulu word for "unusually large pile of elephant droppings."

I'm not developing the co-op based on the assumption that domain validation can be wholly automated -- but it can be automated for the 99+% of domains that don't try to phish people. I'd say the degree of phishing certificate requests made via the co-op will be lower than the "general population", simply because only members can request certificates. That isn't to say that the CA's policies will be any less stringent because of that, but I don't expect to be spending all of my day clicking "reject" on shady CSRs.

(disclosure: I'm the SSL co-op guy)

Organisations aren't code, so trying to make analogies to "forking" CAcert isn't something that stands up to scrutiny.

Yes, audits for WebTrust compliance are quite expensive -- $100k is within the range I've been quoted. However, CAcert has never (to my knowledge) even attempted to engage in one of those audits, and my understanding is that CAcert is attempting to create a system whereby they can operate without requiring a WebTrust audit -- so it's hardly reasonable to bring up the cost of an audit that's never been done, and will never be done.

It would be extremely hubristic of me to try and "take over" CAcert with the intention of trying to get it well-trusted by browsers. Either the organisation as it currently stands doesn't want to be in the trust stores (in which case, I'd essentially be destroying the organisation as it currently exists in order to make a new one from its ashes) or the organisation does want it, but the people currently working on the problem haven't worked out how, within the constraints the organisation has willingly placed on itself -- in which case, why do you think I'm that much smarter than the collective wisdom and experience of everyone, past and present, who has been involved with CAcert? Why would I have the silver bullet to work out how to satisfy the inclusion criteria of the browsers, within the boundaries the organisation has chosen to operate within?

My reasons for investigating the SSL co-op model have nothing to do with CAcert's governance -- from the outside, CAcert appears to be quite reasonably governed. They're to do with the feasibility of becoming a widely-trusted (by browsers, etc) root CA, given the current operational model. Given that I think the operational model needs to be completely different, the value of the existing infrastructure and user/assurer base to a root CA with a completely different operational model is, to be blunt, zero.

The SSL co-op will also explicitly not be an "undermanned community based authority". It will be operated on a solid commercial basis (please bear in mind that "commercial" does not equal "for profit"), and its budget will include funds to pay for staff to operate the CA and all the associated bumf. If the co-op cannot be run on a commercial basis, it will not be run, at least with my involvement.

And finally, I don't want CAcert to go away. I feel there is a strong need for more diversity in how CAs are operated, and the SSL co-op is merely the first step in that direction. I'd like to leverage the co-op's success to make it easier for alternatives like CAcert to be a part of the "in crowd" in the future.

(disclosure: I'm the SSL co-op guy)

CAcert's goal is to issue certificates for free, by implementing an alternate identity validation model. The SSL co-op's goal is to issue a subset of certificates for free, by having those who take advantage of that service share in the costs of running the infrastructure required to do so.

CAcert's determination to stick to its guns on doing everything "on the cheap" is admirable, and I'd quite honestly much prefer it if they succeeded (it'd be a lot less work for me, for one thing). However, looking at the browser inclusion landscape as it currently exists, I have doubts that CAcert has much hope of ever being widely accepted in the browsers. Worse, you can only change the rules about inclusion if you're already in the club... it's a nasty chicken-and-egg problem.

"No one should have to sacrifice security because they don't want to fork over that sort of cash"

It's a bit long to be the SSL co-op's tagline, but as a motto, you've pretty much hit the nail exactly on the head.

Anything that includes a trademark (like info-secure-apple.com) or "risky" term (like atlanta-usbank.com) typically ends up getting manually verified, even for domain-validated certs. Not saying that plenty of dodgy stuff doesn't slip through the cracks, but it isn't quite a wild-west free-for-all...

I'm a little surprised that so many people deliberately mangle URLs to see if there's anything listening on :443, myself. I might just pull SSL off the other domain on IPv4, and put it on a separate IPv6 address...

I'm not averse to that idea, in principle. Heck, that sounds like a nice complementary business idea -- you run a DNS registrar that offers a free domain-validated wildcard certificate with every domain sold, and get your certs from the co-op. The costs would be minimal -- there's bugger-all required to start a domain name reselling business, and SSL co-op membership is shaping up to be more on the "consumer" end, rather than "retailer" cost structure, so there wouldn't be significant costs there, either. I don't think it would need crowdsourced funding to get started, honestly.

The game-changing of the SSL co-op has already started! New business models are taking shape! (grin)

Revocation for X509 certs is a very different matter to that of revoking PGP keys. For X509, the CA can revoke the cert unilaterally, or at the request of the subscriber without the need for the subject private key. In fact, I'm not aware of the existence of a subject-side revocation process that doesn't involve the cooperation of the CA.

(disclosure: I'm the SSL co-op guy)

All of Google's free services (CDN, DNS, Chrome, etc) are centred around improving the experience of using the web, so more people use it for longer (and, hopefully, do more searches with Google and/or visit more webpages with AdSense ads on them). I'm not sure how more SSL-secured traffic feeds into that, exactly, but if anyone at Google wants to talk sponsorship, I'm all ears...

All we have to do is get all certs flagged with must-staple and have all webservers handle stapling, and we're set!

(Sarcasm? Moi?)