<p dir="ltr"><br>
On Sep 7, 2014 4:42 PM, "Geoff Keating" <<a href="mailto:geoffk@apple.com">geoffk@apple.com</a>> wrote:<br>
><br>
><br>
> On 6 Sep 2014, at 7:42 pm, Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br>
><br>
> ><br>
> > On Sep 6, 2014 7:31 PM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br>
> > > Several CAs (and at least one browser) have expressed concerns over the past year every time CAA was raised as a possible new requirement that it could be used improperly by some CAs in the manner I have outlined.  That is the chief impediment to broad support for CAA.  The proponents of CAA need to listen to the concerns of the companies it would most directly affect, and not ignore those concerns.   It needs to be addressed now, before the CA/Browser Forum is asked to give its imprimatur to CAA as a mandatory requirement – even as outlined in Pre-Ballot 125.  That is simple to do.<br>
> ><br>
> > That is not what this Ballot proposes, which is precisely why such concerns are unfounded.<br>
><br>
> I am not enthusiastic about adding a simple reporting requirement.  Wouldn't it be better to propose something which says how to really improve security, even if only as a recommendation?</p>
<p dir="ltr">The goal of this ballot has been to break the deadlock imposed precisely because of these concerns, since repeated F2F and discussions have demonstrated that wording such as Kirk proposes will be unacceptable (and certainly, from our view of the questionable legal practice, would be something we would have to object to).</p>
<p dir="ltr">Yes, in an ideal world, CAA is mandatory, but that's clearly not a world some CAs want, so I would at least prefer we have a system of disclosure.</p>
<p dir="ltr">The further benefit of this ballot, compared to Kirk's proposal (and your modifications) is that it cuts carte blanche for the CAs that are concerned about the (unrealistic) possibility to Dela with it as they see fit. Much like individual root store actions inform the ultimate discussion of baseline requirements (c.f. SHA-1), allowing CAs the freedom to act as they see fit helps to find where there is a common baseline of concerns and then memorialize those.</p>
<p dir="ltr">However, given the misinformation spread by some about CAA, it seems premature to suggest we establish those requirements now. I would much rather a system that forces CAs to simply understand CAA before trying to mandate certain behaviors.</p>
<p dir="ltr">><br>
> And, if we're adding a recommendation (or even just a reporting requirement, since surely the aim of that is to encourage CAs to say they do support CAA), I think Kirk's suggestion is quite reasonable, in principle.  But I don't want to discourage CAs from telling their customers to create a CAA record, or even doing it for the customer, so long as those CAA records will be accurate.<br>
><br>
> So, how this:<br>
><br>
> - CAs SHOULD check the CAA record, but also<br>
><br>
> - CAs MUST NOT request or suggest that a customer include the CA’s name in a CAA record for a domain without also making clear that the customer needs to include all CAs that the owner of the domain intends to use for any hostname in the domain; and<br>
></p>
<p dir="ltr">This is an unauditable and unenforceable requirement.</p>
<p dir="ltr">> - CAs MUST NOT act to create a CAA record that includes the CA’s name without also ensuring that the CAA record contains all CAs the owner of the domain intends to use.  For example, a CA who is also the customer's DNS and hosting operator and knows they will issue certificates for all the customer's DNS names, MAY add CAA record(s) containing only that CA, if otherwise permitted by their agreement with the customer.<br>
></p>
<p dir="ltr">This too is unauditable.</p>
<p dir="ltr">It is clear that this proposal fails to address all of the concerns with CAA, as raised by CAs. The goal of this ballot, and the language chosen, has precisely been not to solve them all and boil the ocean, merely to deftly avoid these concerns while making forward progress.</p>
<p dir="ltr">While I still think any amendments to a documentary process are harmful to the overall success of the ballot, and while we would have a hard time endorsing any measure that is effectively telling CAs what they can communicate to their customer (which this still does), I think that a much more reasonable path would be an enumeration of reasons upon which a CA MAY ignore a CAA record, along with a documentation requirement detailing why they did so.</p>
<p dir="ltr">Recall that the ultimate goal of CAA is to allow a domain operator to intentionally exclude CAs from issuing for their domain. This is of the same level of benefit as to customers' ability to tell CAs precisely who can request certificates from the CA. If a CA is going to disregard that wish - for ANY reason (because the CTO is calling the CA's CTO, because it's an emergency, because the DNS admin went rogue and is holding the domain for ransom, because the CA doesn't believe the customer knew why they were putting a CAA record in - aka just some of the reasons CAs have given as reasons to oppose CAA) - then they simply must document and provide evidence ad to why they ignore it. Then, if the affected customer finds another CA issuing certs for their domain (e.g. via cert transparency), there is a full audit trail as to why and how this came to be, and the question about negligence or misissuance can be evaluated then.</p>
<p dir="ltr">Eventually, one would hope that we establish a baseline of reasons when it is acceptable to ignore and when not. However, attempting to do so now, when so few CAs have experience with CAA (let alone understand it, as seen from the minutes of our meetings), it would be premature to attempt to enumerate them all, and it would be hostile to the success of the ballot to simply ignore those concerns entirely.</p>
<p dir="ltr">Again, to reiterate - we will vote against measures that require precisely what a CA can and can't say or do with regards to their customers and CAA - as an amendment or as a new ballot - because to do so would be to attempt to interfere at a level and scope beyond any the Forum has operated at to date.</p>