[Servercert-wg] [EXTERNAL] Seeking endorsers: Draft ballot to sunset the CAA exception

[Ryan Sleevi]

Hi Bruce,

Could you explain more about the enterprise CA scenario? Were you thinking
technically-constrained sub-CA, or independently operated sub-CA (since you
can't delegate domain validation to an enterprise RA, and the validation
has to be performed by the CA)

For a TCSC, this doesn't change the requirements, so that should be fine.

For an independently operated third-party CA, in order to take advantage of
this exception, they have to implement an even *more* complex validation
flow than CAA. This was meant to provide an escape hatch for organizations
who were using DNS libraries that didn't support CAA, but doesn't absolve
them of at-issuance verification (to determine they're the DNS Operator).

>From examining CP/CPSes (where CAs need to disclose this), I'm only aware
of a very small list of CAs that rely on this, and they already support CAA
(this is largely just a fallback mechanism for them).

So that's the rationale for the window being July, even though all
indications (including from those CAs) is that this could be effective
immediately, if not for the CPS update requirement.

That said, if you're aware of things being overlooked or concerned about
other impact, totally open for discussion on that technical merit.

On Thu, Apr 8, 2021 at 8:49 AM Bruce Morton <Bruce.Morton at entrust.com>
wrote:

> No objection to sunsetting the CAA exception.
>
>
>
> Although this change will not impact Entrust, I would be concerned if the
> exception is being used by an dedicated enterprise CA which has not
> implemented CAA. In this case the 3 months give or take, which is really
> about 1 month after IPR, would probably not be sufficient for this type of
> CA to implement CAA.
>
>
>
> I would consider giving a more than generous period to implement. This
> would allow the ballot discussion to be based on its technical merit and
> eliminate the debate on time to implement.
>
>
>
> Bruce.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Servercert-wg
> *Sent:* Wednesday, April 7, 2021 5:29 PM
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL] [Servercert-wg] Seeking endorsers: Draft ballot to
> sunset the CAA exception
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
> I'm looking for endorsers to a draft ballot to sunset the CAA exception
> afforded to DNS operators.
>
>
>
> You can see the proposed language is available at
> https://github.com/cabforum/servercert/compare/main...sleevi:caa_exception
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/main...sleevi:caa_exception__;!!FJ-Y8qCqXTj2!I_8LQ0eTPSBoT_3giJUD1Eb3uHqVjOAibYmX61fOZBfUFcoXqBpkX57XaeoXnC-FpUA$>
>
>
>
> The motivation is fairly simple: In looking at CA practices and CA
> incidents, the current implementation introduces significant risk in terms
> of CA's understanding the requirements and appropriately implementing them.
>
>
>
> The logic involved in determining whether or not the CA is the DNS
> Operator is quite complex, and requires a thorough knowledge of DNS
> protocols. In practice, what we've seen is CAs simply self-attesting that
> they are the DNS Operator, and not implementing those checks as required,
> which then further leads to non-compliance incidents that CAA can and would
> have prevented.
>
>
>
> Given that it's now been several years of CAA, and we've seen it already
> used to enhance and improve our validation methods, requiring a consistent
> checking of CAA (with the exception of technically-constrained sub-CAs or
> when the CA has already logged a pre-certificate) seems like a reasonable
> balance.
>
>
>
> The CT Log exception is also tricky, and so it may be worth revisiting
> whether it's necessary, but this ballot doesn't do that yet.
>
>
>
> The sunset proposed is three months from now (give or take), which was
> chosen because the actual use/reliance upon this exception is quite rare,
> and the CAs that currently rely on it already have some form of CAA
> checking implemented, to the best of my knowledge. If there are concerns
> with the timeline, concrete details, as always, are welcome.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210408/b39a8406/attachment.html>