On 04/26/2014 06:45 PM, Zack Weinberg wrote:
If a business chooses to give some or even all of its services away
free, those who benefit from those services are still customers and
still in the same ethical relationship with the business as people who
paid for services (perhaps the same service, perhaps not).
We call all of them "subscribers" and we make no difference between a
"paying" subscriber and "non-paying" - the difference is only the
verification level and respective certificates according to that level.
Some of the services carry a fee and some don't - for example no
validated subscriber pays actually for the certificates, he/she pays for
the validations performed which entitles them for certain type of
certificates.
In particular, the business may *not* duck out of ethical obligations
incurred by circumstances beyond any customer's control (e.g.
catastrophic bugs in software everyone relies on ;-) just because some
of its customers are not *paying* customers.
Nobody ducks here - such a bug is not under the control of the
subscriber and not of the issuer of the certificates, nor can the
issuing instance control with which software the certificates are being
used, how the keys are handled and so forth.
This is not a one-way street and it takes at least two to tango. The
subscriber has to comply to the terms and conditions (Subscriber
Obligations) the issuer set forth. And the subscriber has to pay certain
fees when they apply.
CAs should be carrying insurance to cover exactly this sort of
low-probability-but-still-foreseeable, high-cost event.
Interestingly CAs can insure themselves for mistakes made at their end
(errors and omission, but not for mistakes of others. That's exactly the
reason why those costs can't be turned onto the insurer (otherwise we'd
have done exactly that).
--
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
