Skip to content

va: Match CAA parameter tags case insensitively - #8975

Open
hablutzel1 wants to merge 1 commit into
letsencrypt:mainfrom
hablutzel1:caa-lowercase-parameter-tags
Open

va: Match CAA parameter tags case insensitively#8975
hablutzel1 wants to merge 1 commit into
letsencrypt:mainfrom
hablutzel1:caa-lowercase-parameter-tags

Conversation

@hablutzel1

@hablutzel1 hablutzel1 commented Aug 24, 2026

Copy link
Copy Markdown

This makes the accounturi and validationmethods CAA parameter tags match case insensitively, so a differently cased tag such as AccountURI or ValidationMethods still restricts issuance instead of being treated as an unrecognized parameter.

From https://www.rfc-editor.org/rfc/rfc8659#section-4.1, stated for Property Tags:

Matching of tags is case insensitive.

That rule covers Property Tags (issue, issuewild, and so on). For the parameter tags carried inside an issue value, neither RFC 8659 nor RFC 8657 defines a comparison rule.

caaAccountURIMatches and caaValidationMethodMatches currently compare the parameter tag with == against the lowercase literals "accounturi" and "validationmethods". A differently cased tag does not match, so it is treated as an unrecognized parameter and the restriction is dropped. For accounturi the Property then matches any account, and for validationmethods any validation method is accepted, so in both cases a domain that intended to restrict issuance gets a false positive validation.

For reference, the same case being discussed in the PR for RFC 8657 support in the Open MPIC project, open-mpic/open-mpic-core-python#71 (comment)

RFC 8659 Section 4.1 makes matching of CAA Property Tags case
insensitive, but neither RFC 8659 nor RFC 8657 specifies a comparison
rule for parameter tags such as "accounturi" and "validationmethods"
(the grammar only constrains the allowed characters). Lowercase these
parameter tags before matching, so a differently-cased tag still
restricts issuance instead of being treated as an unrecognized
parameter.

For both parameters, ignoring a differently-cased tag drops a
restriction the subscriber intended and produces a false-positive
validation. For example, an unrecognized "AccountURI" tag would make
the Property match any account, and an unrecognized "ValidationMethods"
tag would permit any validation method.

https://www.rfc-editor.org/rfc/rfc8659#section-4.1
https://www.rfc-editor.org/rfc/rfc8659#section-4.2
https://www.rfc-editor.org/rfc/rfc8657#section-3
https://www.rfc-editor.org/rfc/rfc8657#section-4
@hablutzel1
hablutzel1 marked this pull request as ready for review August 24, 2026 17:09
@hablutzel1
hablutzel1 requested a review from a team as a code owner August 24, 2026 17:09

@aarongable aarongable left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have discussed this in the past, and would prefer not to merge this change.

Yes, there is some value in the "be strict in what you produce, and liberal in what you accept" philosophy. This PR would align with being liberal in what we accept.

However, we have seen no evidence that such mis-cased labels exist in the wild. As such, we are in a position to keep it that way. Becoming more liberal in what we accept will only allow the set of all CAA records to become messier. There's no reason to allow that when the current status quo is that CAA records have the correct capitalization.

If we're going to do anything differently, we would prefer to loudly fail on CAA records containing incorrectly capitalized parameter tags.

@hablutzel1

Copy link
Copy Markdown
Author

If we're going to do anything differently, we would prefer to loudly fail on CAA records containing incorrectly capitalized parameter tags.

I agree with this approach as well.

Would you accept such a change? I can re-purpose the current PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants