[cabfpub] Draft CAA motion (2)

Steve Medin Steve_Medin at symantec.com
Thu Nov 10 18:56:49 UTC 2016

I’m suggesting that contracts like what we’re discussing gain material impact on the BRs through BR mention of them and their associated handling and disclosure of existence rules. I want to allow customers to grant CAs the right to bypass CAA checking, and I want to publicly show that the right has been granted (response to Jeremy) so that such behavior can be inspected.


If stricter rules about CAA are imposed and they have contractual impact because, given the above, contracts become a constraint and a compliance tool in the BRs, then it would follow that inadequate or out of date contracts would put a CA at risk of non-compliance.



From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Thursday, November 10, 2016 1:39 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Gervase Markham <gerv at mozilla.org>; Steve Medin <Steve_Medin at symantec.com>
Subject: Re: [cabfpub] Draft CAA motion (2)




On Thu, Nov 10, 2016 at 10:29 AM, Steve Medin via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org <mailto:gerv at mozilla.org> ]
> Sent: Thursday, November 10, 2016 12:40 PM
> To: Steve Medin <Steve_Medin at symantec.com <mailto:Steve_Medin at symantec.com> >; CA/Browser Forum Public
> Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
> Subject: Re: [cabfpub] Draft CAA motion (2)
> But here's another suggestion. Instead of mandating CAA in Mozilla policy,
> we'll just say that issuing in the face of an adverse CAA record is a
> serious
> misissuance. Then, you'd be free to not check it as often as you liked,
> relying
> on your systems and contracts to save you - and the first time they went
> wrong, we'd untrust your intermediate or remove your EV indicator or some
> other sanction. How would that be? :-)
> Gerv

Well, that depends on the validity of a contract from the customer that
absolves the CA from the requirement to check CAA within their service.


I don't really understand why you feel this way - that is, the validity of the contract doesn't seem to have any material impact on the BRs. Or, put differently, contracts neither replace nor reduce the scope of the BRs. So if Gerv put forward a ballot that said "caveat CA", and even if you had a contract that said you didn't have to, if the customer - or anyone else who checked the CAA record -  pointed out to the contrary, then it would be treated as a serious misissuance. 


So how does the contract matter?


Let customers opt out when they trust their CA and its audits and it's no
longer CA policy or browsers trusting CAs. Let customers adopt CAA to block
other CAs that do not hold such a contract.


Let's imagine we accept this argument. Would you be open to requiring that the contract must be renegotiated any time there is a change in CAA, to ensure that, at all times, the customer is making an informed decision? Quite frankly, sometimes it takes browsers to protect users from predatory CAs, and so if say there was a change that affected or improved the security of CAA checking, the customer should be informed. Such a renegotiating-of-agreement clause would help prevent CAs from misrepresenting CAA (as some have), allow the customer flexibility, and put a burden of effort on the CA in order to replace the stronger technical guarantee. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161110/87fad45c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5744 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161110/87fad45c/attachment-0001.p7s>

More information about the Public mailing list