Draft Language for CAA accounturi and validationmethods Processing Requirement

[Wayne Thayer]

In November we discussed the issue titled "Define standard CAA semantics for limiting cert issuance" and I volunteered to draft TLS BR language for this new requirement. Here is my proposal:

https://github.com/cabforum/servercert/pull/567

Under this proposal, CAs must process the RFC 8657 accounturi and validationmethods parameters when performing CAA checks. Furthermore, CAs must document the semantics that they recognize in their CPS.

I will appreciate everyone's feedback on this proposal.

Thanks,

Wayne

[Roman Fischer]

Dear Wayne,

 

Thanks for the proposal. It is clear, that some customers want /need these CAA enhancements. But does it have to be a MUST requirement? Can we rephrase it so that CAs must be able to parse CAA entries that contain these enhancements but don't have to offer them for their customers?

 

If that is not an option, then I must say that the suggested effective date of 2025-09-15 is very tight for a change in such a critical component as the CAA processing. I would then suggest to at least change the effective date to 2026-03-15.

 

Kind regards
Roman

--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk-AA%3DyT8dcXs%2Bv9VV%2BKC72MM60GUfvZpuyozReV_H5ynQ%40mail.gmail.com.

[Wayne Thayer]

Thank you for the feedback Roman. On today's Validation WG call we discussed merging this with a ballot requiring DNSSEC for CAA lookups. Since that is also a significant change I would support a longer implementation period, such as what you have proposed.

- Wayne

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/ZR0P278MB017039DB659908BA46B56C00FA132%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Doug Beattie]

Hi Wayne,

 

We also discussed perhaps making this a SHOULD vs. a MUST.  Setting standards for how to define the acccounturi and validation method is a great idea and something we need to standardize on, but I’d recommend making this a SHOULD for the time being.  It doesn’t seem like a mandatory/security related feature that all CAs need to support immediately, unless I missed something in the preamble around the need for this.

 

Doug

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk93UKP0Tu4zVOBsaLzB8tdxk4bhkZk3RvFxSxm8BrDp6w%40mail.gmail.com.

[Dimitris Zacharopoulos]

Apologies for missing the recent validation meeting. I'm very interested to read the minutes about this DNSSEC requirement for CAA lookups because in my understanding this has always been a requirement in the BRs.


Dimitris.

Jan 9, 2025 20:54:04 Wayne Thayer <wth...@gmail.com>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk93UKP0Tu4zVOBsaLzB8tdxk4bhkZk3RvFxSxm8BrDp6w%40mail.gmail.com.

[Wayne Thayer]

For discussion at tomorrow's Validation SC meeting, I've updated the proposal: https://github.com/cabforum/servercert/pull/567/files

- Incorporated Clint's DNSSEC language and renamed the ballot

- Specified the format for the validationmethods label for non-ACME methods

- Proposed a March 15, 2026 effective date. We should also discuss the alternative of making this a SHOULD as Doug and others have suggested.

Thanks,

Wayne

[Rob Stradling]

> - Specified the format for the validationmethods label for non-ACME methods

Hi Wayne.

Your proposed text is:

"* If the CA accepts certificate requests via any protocol other than the ACME protocol defined in RFC 8555, the CA MUST recognize validationmethods labels formed by concatenating the string ‘ca-dv-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-dv-7’ represents the DNS method described in TLS BR 3.2.2.4.7."

Please could you explain what real world problem this is trying to solve?

This GitHub comment explains that this proposal was discussed on a recent "Validation SC call and consensus was that we should define the format for the validationmethods label, e.g. 'ca-tlsbr-<method #>' One argument for this was that a standardized format would be more likely to result in automation support."

What sort of automation support is envisaged by this argument?

Automation requires interoperability.  Whereas RFC8555 defines clear, interoperable DCV methods (ACME http-01 and dns-01), the TLS BRs mostly don't (see my GitHub comment here).

Additionally, RFC8657 reserves the "ca-" prefix for labels that "are defined to have CA-specific meaning".  Therefore, I don't see how CABForum can mandate a shared meaning across all CAs for labels of the form "ca-tlsbr-<method #>".  Surely "CA-specific" means that each CA individually gets to choose what any label with the "ca-" prefix means?

If there is a legitimate use case here, then I'd like to find a way to accommodate it without violating RFC8657.

---

From: Wayne Thayer <wth...@gmail.com>
Sent: 22 January 2025 16:49
To: valid...@groups.cabforum.org <valid...@groups.cabforum.org>
Subject: Re: [cabf_validation] Draft Language for CAA accounturi and validationmethods Processing Requirement

 

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk8DKHTz3oBLbMcY6TQTHeq6ky3myEL77pzNc%3DVGnwT%2BNg%40mail.gmail.com.

[Wayne Thayer]

Hi Rob,

We discussed this again on Thursday and consensus was that defining the format for validationmethods parameter in the TLS BRs does not violate the RFC.

I updated the PR with my interpretation of the outcome of Thursday's discussion: https://github.com/cabforum/servercert/pull/567 - feedback appreciated.

Thanks,

Wayne

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/MW4PR17MB47297BC9EAFE6D35A630EC86AAE12%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Wayne Thayer]

I have incorporated most of the discussion from today's Validation SC call into the PR at https://github.com/cabforum/servercert/pull/567

Regarding the need for adding an effective date to the second paragraph of 3.2.2.8.2, after further review I do not believe this is necessary or even desirable. The first paragraph in that section makes the processing of the accounturi and validationmethods parameters a SHOULD immediately and a MUST on March 15, 2027. The paragraph in question is qualified with the statement "if the CA processes the accounturi and validationmethods parameters". Taken together, the desired result is achieved: CA's MUST adhere to the requirements in the second paragraph whenever they process these parameters.

In a previous discussion, I was asked to relax the requirement for documenting the accounturi format in section 3.2.2.8 of the CA's CPS because that specific subsection and preceding subsections might not exist. While reviewing this I realized that other CAA information is required to be placed in CP/CPS section 4.2, so I've updated this proposal to match.

I welcome more review and comments on this, but I do think it's about ready to proceed to a ballot. If anyone would like to endorse,please let me know.

Thanks,

Wayne

[Aaron Gable]

On Thu, Feb 6, 2025 at 4:23 PM Wayne Thayer <wth...@gmail.com> wrote:

 Taken together, the desired result is achieved: CA's MUST adhere to the requirements in the second paragraph whenever they process these parameters.

The concern, as I understood it at least, was that some CAs *already* process these parameters. Therefore their CPS would need to be updated immediately upon the ballot going into effect. Maybe that's fine -- updating a CPS isn't particularly arduous, and they have the IPR period to do so -- but it does seem like a legitimate cause for concern.

Aaron 

[Ben Wilson]

See below.

On Thu, Feb 6, 2025 at 5:23 PM Wayne Thayer <wth...@gmail.com> wrote:

In a previous discussion, I was asked to relax the requirement for documenting the accounturi format in section 3.2.2.8 of the CA's CPS because that specific subsection and preceding subsections might not exist. While reviewing this I realized that other CAA information is required to be placed in CP/CPS section 4.2, so I've updated this proposal to match.

In requiring it in section 4.2, we created ourselves a mess. Maybe it should say "in either section 3.2.2.8 or 4.2" and indicate a timeframe for when putting it in one or the other is deprecated. It would be good to somehow migrate to a point where all CAs have all of their CAA explanations in the same section.

[Doug Beattie]

Hi Wayne,

 

There is some very good information here.  On a somewhat tangential note, I have a question.  I noticed that we removed 2 of the required  checks regarding CAA failures in the ballot, specifically:

*if  the failure is outside the CA's infrastructure; and

* if the lookup has been retried at least once;

 

If MPIC is being used to validate CAA records in a mode that is at least as strong as the September 15, 2025 MUST requirement, can we assume that these checks are inherently satisfied because of MPIC?   I’m thinking yes, but wanted to get that confirmed with others.

 

Thanks!

 

Doug

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk-T_GiOhkdx3XxShO863rrzN-FeHWeJbHROEb6fW2JvnA%40mail.gmail.com.

[Wayne Thayer]

Ah, that makes sense. I added an effective date of March 15, 2026 for that paragraph as a compromise - I don't think it should take long for a CA in this situation to comply by updating their CPS, but I didn't want to add a third effective date into this ballot.

- Wayne

[Wayne Thayer]

It makes some sense to incorporate this change because it affects the same section, but it's outside the current scope of the ballot. I'd like to get some feedback from others before adding it.

- Wayne

[Wayne Thayer]

Hi Doug,

On Fri, Feb 7, 2025 at 7:24 AM 'Doug Beattie' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org> wrote:

Hi Wayne,

 

There is some very good information here.  On a somewhat tangential note, I have a question.  I noticed that we removed 2 of the required  checks regarding CAA failures in the ballot, specifically:

*if  the failure is outside the CA's infrastructure; and

* if the lookup has been retried at least once;

By my reading of the ballot language, the entire exception for CAA lookup failures would be removed:

CAs are permitted to treat a record lookup failure as permission to issue if:
* the failure is outside the CA's infrastructure; and
* the lookup has been retried at least once; and
* the domain's zone does not have a DNSSEC validation chain to the ICANN root.

I copied this change over from Clint's draft, but I don't believe it is directly related to the DNSSEC clarification. I'd like to discuss this change and would consider reverting it because it seems to be out of scope.

 

If MPIC is being used to validate CAA records in a mode that is at least as strong as the September 15, 2025 MUST requirement, can we assume that these checks are inherently satisfied because of MPIC?   I’m thinking yes, but wanted to get that confirmed with others.

I don't think the interaction between this exception and MPIC is clear. If there is a record lookup failure on the Primary Network Perspective meeting the requirements for the exception, what does MPIC corroborate? Must the same failure occur from all perspectives? Can MPIC corroboration also rely on this exception if the Primary Network Perspective performs a successful CAA record lookup?

- Wayne

[Roman Fischer]

Hi Wayne,

 

I can share how our supplier has implemented it (maybe others can share too?):

 

We have scheduled jobs to do domain validation. Validation is retried several times. On every try:

• First ask the primary perspective
• If and only if the primary perspective successfully validates the domain, the remote perspectives are contacted (in parallel)
• Consolidate all responses from remotes
• If there are not enough successful answers (quorum rules), the validation is not successful and is scheduled for retry
• If there are enough answers, the answers are checked for corroboration

So, the way it's implemented right now (not audited yet!) is that all the checks have to pass during the same try.

 

Rgds
Roman

 

From: Wayne Thayer <wth...@gmail.com>
Sent: Mittwoch, 12. Februar 2025 00:51
To: valid...@groups.cabforum.org
Subject: Re: [cabf_validation] Draft Language for CAA accounturi and validationmethods Processing Requirement

 

Hi Doug,

--

You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to

validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk_m5Nj80ou%2BtdCE29OkBjqYhaaWXn48Zypc3U8EER6c1A%40mail.gmail.com.

[Aaron Gable]

I would preserve the existing language ("are permitted to treat a record lookup failure... if:...") at the top of the new Section 3.2.2.8.3, preceded by a "Until March 15, 2026,". I think it is important to preserve that language until the new DNSSEC-validation language kicks in on that effective date.

However, once the new DNSSEC validation language becomes effective on March 15, 2026, the existing language becomes irrelevant and can be removed. The first bullet point can be removed because any failure inside the CA's infrastructure is, of course, a failure to comply with the requirements, and so this statement is redundant. The second bullet point can be removed because DNSSEC validation requires a successful lookup (at least of the NSEC record), so the CA must either give up or retry until that lookup is successful, not just retry once. The third bullet point is replaced by the majority of the new language detailing how to check for a DNSSEC validation chain.

None of these interact with MPIC. Each MPIC perspective must satisfy these requirements independently, and return a "issuance allowed/disallowed" statement, which must then corroborate the primary perspective's determination.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/ZR0P278MB0170ADAEE61B16313196F9C0FAFF2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Roman Fischer]

Wouldn't it be more "robust" to omit the requirement for a specific section altogether? Just require it to be in the CP/CPS without any section.

 

Cheers
Roman

 

 

From: Wayne Thayer <wth...@gmail.com>
Sent: Dienstag, 11. Februar 2025 23:24
To: valid...@groups.cabforum.org
Subject: Re: [cabf_validation] Draft Language for CAA accounturi and validationmethods Processing Requirement

 

On Thu, Feb 6, 2025 at 5:54 PM 'Ben Wilson' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org> wrote:

--

You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk-nhE3NHyiCWTFat_qopqzS%3DopznfoAK4te2PS6wE8Yug%40mail.gmail.com.

[Adriano Santoni]

Hi all,

surely this has already been widely discussed, so I beg your pardon for putting it on the table again :)

The transition to mandatory DNSSEC-support will have its drawbacks, as it introduces overhead at various levels (larger size of DNS responses, need for multiple DNS queries to build the trust path, signature verifications). This increased protocol overhead, combined with the progressive reduction in certificate lifetime which means a significant increase in the volume of domain validations, I fear could lead to a huge increase in the workload that CAs, CT logs, Firewalls, etc. will have to sustain. 

I am /not/ saying that mandatory DNSSEC support in domain validation is wrong, but only that it will also lead to problems...

Adriano

Il 07/02/2025 01:23, Wayne Thayer ha scritto:

NOTICE: Pay attention - external email - Sender is validation+bncBDTOBIEW...@groups.cabforum.org

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAPh8bk-T_GiOhkdx3XxShO863rrzN-FeHWeJbHROEb6fW2JvnA%40mail.gmail.com .

[Wayne Thayer]

I've updated the PR based on discussion at the last two Validation Subcommittee meetings: https://github.com/cabforum/servercert/pull/567/files

* Moved the entire CAA section to 4.2.2.1 to align with the S/MIME BRs and existing requirements for publishing CAA information in section 4.2 of the CA's CP/CPS

 * I left section 3.2.2.8 in place with a reference to 4.2.2.1 to avoid breaking section numbering

* Removed the DNSSEC requirements from this ballot

 * I made the assumption that this ballot would pass before the new separate DNSSEC ballot (https://github.com/cabforum/servercert/pull/571)

 * I included an explicit exception to the RFC 8657 section 5.6 DNSSEC requirement

I think this draft is ready to become a ballot. Please let me know if you are willing to endorse it.

Thanks,

Wayne

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/f2c0473d-3921-4154-b7c9-f197b7c8847f%40staff.aruba.it.