[cabfpub] Pre-Ballot 125 - CAA Records

[Ryan Sleevi]

On Sep 7, 2014 4:42 PM, "Geoff Keating" <geoffk at apple.com> wrote:
>
>
> On 6 Sep 2014, at 7:42 pm, Ryan Sleevi <sleevi at google.com> wrote:
>
> >
> > On Sep 6, 2014 7:31 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
> > > 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.
> >
> > That is not what this Ballot proposes, which is precisely why such
concerns are unfounded.
>
> 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?

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).

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.

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.

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.

>
> 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.
>
> So, how this:
>
> - CAs SHOULD check the CAA record, but also
>
> - 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
>

This is an unauditable and unenforceable requirement.

> - 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.
>

This too is unauditable.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140907/bc5e8bdf/attachment-0003.html>