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

Fri Apr 9 18:07:51 UTC 2021

Speaking as someone who has implemented it in the past, CAA isn’t tough to implement in a script—particularly for your own domains—and it can also be checked manually using various DNS tools. If there’s someone out there who falls into that category, I would think three months isn’t too egregious a timeline to figure out at least something rudimentary. I like the thought, but I lean more towards a tighter timeline on this.

-- 
Jos Purvis (jopurvis at cisco.com)
.:|:.:|:. cisco systems | Cryptographic Services
PGP: 0xFD802FEE07D19105 | Controls and Trust Verification

From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of CABF Server Cert WG <servercert-wg at cabforum.org>
Reply-To: Bruce Morton <Bruce.Morton at entrust.com>, CABF Server Cert WG <servercert-wg at cabforum.org>
Date: Thursday, 8 April, 2021 at 17:13
To: Ryan Sleevi <sleevi at google.com>
Cc: CABF Server Cert WG <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Seeking endorsers: Draft ballot to sunset the CAA exception

No I have nothing specific. I was just concerned that there might be an unconstrained third-party subCA, which did not do CAA based on the exception. If the fix is to implement CAA, then my thinking was the effective date may be too short.

Thanks for doing the research.

Bruce.

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, April 8, 2021 1:33 PM
To: Bruce Morton <Bruce.Morton at entrust.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [EXTERNAL] [Servercert-wg] Seeking endorsers: Draft ballot to sunset the CAA exception

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

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/20210409/7a31b924/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3699 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210409/7a31b924/attachment-0001.p7s>