[cabfpub] Ballot 121 (insurance)

Fri May 30 17:30:25 MST 2014

On 5/31/2014 2:46 AM, Ben Wilson wrote:
> Do you have a proposal that addresses the concerns about financial
> stability?
Please see ETSI TS 101 456 V1.4.3 section 7.5 specifically points d), e) 
and f) - IMO they are close to what you are looking for.

As a standardization body ETSI doesn't set its requirements in terms of 
absolute amounts, this is left to implementers - in this case to MS 
Governments.

FYI:
http://www.etsi.org/deliver/etsi_ts/101400_101499/101456/01.04.03_60/ts_101456v010403p.pdf

Given the fact that EVG is incorporated into ETSI "as is", I see 
potential conflict between the two approaches.

Thanks.
M.D.

>
> -----Original Message-----
> From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com]
> Sent: Friday, May 30, 2014 5:20 PM
> To: ben at digicert.com; 'Gervase Markham'; 'public >> CABFPub'
> Subject: RE: [cabfpub] Ballot 121 (insurance)
>
> Ben -- as I indicated to the EV Working Group in an email recently, I have
> definitely changed my mind about the EVGL insurance requirement based on my
> own experience in starting AffirmTrust in 2010.  (As a reminder to all,
> AffirmTrust was acquired by Trend Micro in 2011, and Trend is big enough and
> has a strong enough balance sheet and treasury that under the EVGL we are
> entirely exempt from the insurance requirements -- so we have no personal
> stake in this.)
>
> While starting my own company, the insurance brokers kept asking me why I
> wanted the insurance coverages -- they clearly didn't think I needed them --
> and they warned me that the E&O coverage in particular probably wasn't going
> to provide me with any meaningful protection for anything (given that it
> generally doesn't cover contractual liability for a bad cert, return of
> fees, etc.)  So it felt like a very big waste of money.
>
> Plus we now know from eight years of experience (plus the anecdotal evidence
> of Trend Micro's legal counsel from his decade at VeriSign) that there
> simply aren't claims from customers or relying parties for mis-issued certs
> and that the need for insurance (even if it did cover the mis-issuance of EV
> certs) is minimal at best.  The one case of catastrophic failure and breach,
> DigiNotar, apparently resulted in a court ruling that the insurer would be
> allowed to deny all coverage.
>
> When we collectively were brainstorming in 2005-6 to create the first EV
> Guidelines, we were trying to come up with lots and lots of requirements to
> try to set EV certs apart from other certs.  As I recall, we considered even
> more complex verification steps for EV to make it similar to the closing of
> a major corporate transaction (e.g., getting Board of Directors
> authorizations, Secretary's Certificates, etc.) -- fortunately, common sense
> prevailed and we slimmed down the requirements so they are very thorough,
> but achievable.
>
> Finally, the Forum has learned through eight years of experience that these
> insurance requirements are even harder and more expensive for
> non-US/Canadian CAs to satisfy, and that their brokers also tell them the
> coverages won't provide them with any meaningful protection.  We don't want
> the EV Guidelines to be weighted in favor of US/Canadian CAs.
>
> The Forum hasn't hesitated from changing other EVGL requirements when we
> think justified -- such as recently allowing the use of the automatic email
> verification method to upgrade domains to the EV level (using the same
> verification methods as for DV and OV certs).  For the first seven years of
> the EVGL, we were all required to do manual vetting of domains with a WhoIs
> lookup and deal with any mis-match of the registration.
>
> So for all these reasons, I think Gerv is right and it's time to drop the
> insurance requirements.   Let CAs follow any insurance requirements that
> their applicable local jurisdiction(s) may impose, but otherwise don't
> create an additional insurance requirement through the EV Guidelines.
>
> Gerv, thanks for sharing your thoughtful and well informed opinion.  It
> really helps.
>
> Kirk
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Ben Wilson
> Sent: Friday, May 30, 2014 3:15 PM
> To: 'Gervase Markham'; 'public >> CABFPub'
> Subject: Re: [cabfpub] Ballot 121 (insurance)
>
> Gerv and all,
>
> If people want to save money, they can stick to issuing DV or OV
> certificates.  EV certificates need to remain different, and this proposed
> move is contrary to the first goal we all agreed upon when we began working
> on the guidelines for issuing Extended Validation Certificates, which my
> notes indicates was to "increase online trust."
>
> If the ballot is re-introduced and passes, then CAs will not be required to
> have insurance for any negligence in issuing or maintaining EV Certificates.
> It increases the likelihood that another Diginotar won't be held
> accountable, and I believe the insurance is currently available at
> affordable cost, approximately $10,000 per $1 million coverage.  I have
> attached a sample cyber-insurance policy, which is available in similar form
> from any of top insurers internationally-- Zurich, ING, AIG, AXA, Allianz,
> etc.
>
> The reintroduction of Ballot 121 also reopens negotiations of 8 years ago,
> which took place during 2006.  For example, attached is Kirk Hall's memo to
> the group from June 2006 in which he recommends "indemnity insurance
> coverage (e.g. "errors and omissions," "cyber coverage," "network computer
> liability," "professional liability," or other similar coverage) for
> Extended Validation Certificates [in the amount of $10 million]."
>
> Opponents of insurance requirements cannot simply erase these historical
> choices without proposing viable alternatives.  (It's always easier to
> complain and to poke holes at things than to work on real solutions.)  And
> finally, if the EV Guidelines do not contain some form of financial
> responsibility, then we might as well delete the Section 7 warranties, and
> the other EV provisions to which they refer, because they will just become
> empty promises.
>
> Ben
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Gervase Markham
> Sent: Friday, May 30, 2014 12:41 PM
> To: public >> CABFPub
> Subject: [cabfpub] Ballot 121 (insurance)
>
> I talked to our lawyer this morning. Mozilla is now willing to support the
> proposal in Ballot 121 (removal of the insurance requirement from the EV
> Guidelines).
>
> We feel that this requirement provides no significant protection in practice
> for either users, for whom CAs can limit liability to $2000 anyway, or for
> browsers, for whom clause 18.2 which indemnifies them is much more relevant.
>
> We encourage other CAs and browsers to support this ballot also, and let the
> CAs put the $N,000 saved towards making their products better and/or cheaper
> for users.
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail
> or telephone and delete the original message from your mail system.
> </pre></td></tr></table>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140531/7d65aebf/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3663 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20140531/7d65aebf/attachment.bin 