Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

(I'm the sslcoop.org guy)

"If all the money we spent on ssl certificates..."

And thus was sslcoop.org born! I'm not sure what you mean by "opensource PKI infrastructure", exactly, but as a long time F/OSS hacker, I'm definitely planning on putting everything that's developed for the SSL co-op under an open licence.

But the software's the easy bit. The hard part is the work required to define processes and policies, get everything audited, and then getting through the inclusion process for all the browsers. That's what takes somewhat more organisation (and money) than writing some code and running openssl...



iirc the WebTrust Audit required for such a system is in the ~$100,000 range. Why abandon existing initiatives to start another undermanned community based authority.

I think the focus should really be in jumpstarting CACert (overhauling its governance model) and building on its existing infrastructure and user/assurer base (As an assurer I'm probably biased here).

Of course this would be hard work and less self fulfilling than doing the F/OSS dance and re-inventing the wheel..


(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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: