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

[Bruce Morton]

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/04903aac/attachment.html>