[cabfpub] Draft CAA motion (2)

Steve Medin Steve_Medin at symantec.com
Thu Nov 10 13:28:29 MST 2016


Sorry, I’m not citing existing BR content, I’m proposing new to give weight to a vendor/client relationship. Add a clause to Gerv’s motion that recognizes that a customer can opt out of a CA checking CAA by contract. Require that the CA indicate this choice through presence of a CABF arc CP OID at EE tier, allowing programmatic checking of CAA violation. In all other regards, business as usual without creating N generations of TCSCs for a customer every year and the server installation confusion that causes among even relatively savvy operations.

 

I’ve drowned out Jody here, but he wants to issue to his affiliates without checking their CAA. As long as we don’t make sport out of finding gaps between each other’s thinking, there are parallels to draw between affiliation and a contract. One is total, the other specific.

 

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

 

 

 

On Thu, Nov 10, 2016 at 10:56 AM, Steve Medin <Steve_Medin at symantec.com <mailto:Steve_Medin at symantec.com> > wrote:

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. 

 

Can you point to what rules you're thinking of that require the disclosure or handling? Because I can certainly think of examples with Symantec not disclosing contracts.

 

I want to allow customers to grant CAs the right to bypass CAA checking, 

 

Why? Can we move from talking about things wanted to understanding why? This was discussed at the F2F, but it's particularly helpful to understand why you object, other than it creates more work. I'm not saying that more work is not important, but I want to make sure that if there are reasons other than that it's more work, we've properly considered them.

 

and I want to publicly show that the right has been granted (response to Jeremy) so that such behavior can be inspected.

 

The problem with what's proposed is there's a significant and material difference between expressing that in a TCSC - which is technically enforcable - and a general contract proviso.

 

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.

 

I believe we must be talking past eachother, because I don't believe there is anything in the BRs to support your claim here. I'd love to be mistaken - to see actual support for this statement - but I suspect it's moreso borne out of a misunderstanding of the point I was making.

 

I'm specifically talking about better controls afforded via CAA - such as the ability to restrict issuance methods that was discussed in the F2F. If the CA/B Forum (or the IETF) introduced such controls, then it bears determining with the customer whether or not they want to continue to opt-out of CAA. Similarly, if CAA affords them more flexibility through some change in the Forum or the IETF, it bears determining with the customer whether or not they want to continue to opt-out of CAA.

 

I'm specifically objecting to the notion of 'set it and forget it' - that is, a blanket exclusion that never gets revisited. If the idea of contractual-based exclusions is countenanced, then we should take appropriate steps to ensure its scope is limited. One such way to limit that scope is require the exclusion be reauthorized any time there's a chance in the Forum/IETFs CAA policies.

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


More information about the Public mailing list