Hi Eddy, I appreciate how diligent you're being about responding to everyone. And, as I've said elsewhere, I haven't believed that there's an ethical problem with offering free certs with paid revocations as a general business practice.
But I'm still not hearing you explain why an exception shouldn't be made for an unprecedented event like this. Debian weak keys was a big deal, but did not have as widespread ramifications as Heartbleed. Resist generalizing: would offering a one-time free revocation for any domain whose owner says the word "Heartbleed" be feasible *right now* for Startcom? Could Startcom get through it okay? Presumably, your CRL lists have already expanded and your bandwidth costs increased. If the number of vulnerable certificates is small enough that you haven't felt guilt-ridden about charging them for revocation, it should also be small enough that the additional marginal cost of waiving the fees for them shouldn't cost you that much. So if you can, just do it. Going forward, everyone will be much more aware of Startcom's revocation fee. If the answer is no, and Startcom has gotten itself into a position where it cannot afford to set aside its general business policy for an Internet-wide emergency, then I guess I have to conclude that yeah, it's not an ethical general business practice either. Part of having a sustainable business is having enough of a buffer so that you can weather an occasional tornado without having to lock your neighbors out of the shelter. -- Eric On Sun, Apr 27, 2014 at 6:07 PM, Eddy Nigg <[email protected]> wrote: > On 04/25/2014 08:50 PM, Jan Lühr wrote: >> >> What's your argument here? Is "crying foul" "Unjustified", because >> nobody "cried foul" the moment you published your policies? > > > It's unjustified if as a subscriber you are not willing to accept the terms > and conditions of that service, e.g. you want to accept the convenient part > of it but not commit to your obligations. > > >> Please consider: Heartbleed-scale problems have hardly happened before. > > > True - the closest would be probably the Debian weak keys. > > >> I'ven't considered any mass-key-compromise scenarios before > > > I did - I learned from the Debian weak keys a lot. > > >> Personally, I am "crying foul" because I'm re-thinking your policies >> having heartbleed in mind. > > > You can't really rethink our policies, this is something we might have to do > at some point. You can either agree or disagree with them though. > > >> Personally, I vote no. StartSSL is not revoking certificates assumed to >> be compromised, if a subscriber doesn't pay. > > > You are expecting to receive all benefits without taking responsibility for > your part? Or lets put it like this: > > As you stated before, how likely is it that such an event like this one > occurs? It might have never happened and in fact some 83% are not affected > (world-wide), which means that they will happily keep obtaining certificates > without ever paying a dime. Would you have used a different software, you > could be easily one of those 83% too. > > Now, exactly because of this and other scenarios, where revocation of a > certificate is necessary or is requested for any other reason by the > subscriber and it's not due to a failure of the CA we decided to charge a > fee in order to protect us from losses. Otherwise the current business model > would probably not work...and I'm not even talking about easy abuse that's > possible with the current model without raising a fee. > > >> -> You say it is small / low by describing the circumstances under which >> it happens and causes an impact. > > > Currently the facts show that StartCom's revocation numbers are not lower, > in fact a bit above average. And here some more interesting facts: > http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html > > > > -- > Regards > Signer: Eddy Nigg, COO/CTO > StartCom Ltd. <http://www.startcom.org> > XMPP: [email protected] <xmpp:[email protected]> > Blog: Join the Revolution! <http://blog.startcom.org> > Twitter: Follow Me <http://twitter.com/eddy_nigg> > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com | @konklone _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
