va: Match CAA parameter tags case insensitively - #8975
Conversation
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
aarongable
left a comment
There was a problem hiding this comment.
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.
I agree with this approach as well. Would you accept such a change? I can re-purpose the current PR. |
This makes the
accounturiandvalidationmethodsCAA parameter tags match case insensitively, so a differently cased tag such asAccountURIorValidationMethodsstill 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:
That rule covers Property Tags (
issue,issuewild, and so on). For the parameter tags carried inside anissuevalue, neither RFC 8659 nor RFC 8657 defines a comparison rule.caaAccountURIMatchesandcaaValidationMethodMatchescurrently 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. Foraccounturithe Property then matches any account, and forvalidationmethodsany 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)