PROD Support for RFC8657 CAA constraints for accountURI and validationmethods

It's more that two CAA records create a union, the options within a validationmethods are also a union, but having multiple validationmethods are an intersection (assuming that @aarongable's reading and mine are correct).

And my questions are mainly around if a CAA record has unacceptable syntax, in what cases does that mean that no issuance is allowed and in what cases does it mean that any issuance is allowed.


Yeah, to be clear, I'm guessing/interpreting here just as much as everyone else. I don't have any magic insight.

Two separate CAA records must be treated as a union because there's no other reasonable interpretation: for example, the two separate CAA records might specify two different CA URLs, allowing two different CAs to issue for that name. Basically the interpretation is "if there is any CAA record that allows this issuance, then you're good".

It's only within a single CAA record that the questions arise. And that's where my supposition of "treat it like accounturi" becomes relevant. For that parameter, we are explicitly told that the set of valid account URIs is the intersection of the values of multiple accounturi parameters within a single record. So it seems reasonable to do the same for validationmethods.


You both make fair points yet I favor other options. TL; DR I think retaining only the last validationmethods is fine. My second favorite is to fail to issue if more than one exists on the same CAA regardless of their values (gasp, I know, read on).

accounturi can only have a single value. The spec needs to describe how to specify multiple values and that is done with multiple CAA records (see Examples section). It makes clear not to use multiple accounturi on one CAA. It actually says: A Property with multiple "accounturi" parameters is unsatisfiable. So, a strict reading means multiple parameters should fail even if the values are identical. That is, fail due to syntax failure and not because of an intersection. But, for me this is of lesser importance and the primary key is that accounturi is a single-value parameter.

validationmethods allows multiple values for one parameter. The spec also says multiple CAA records may be used. A discussion of what happens with two parameters on one CAA is not needed to describe practical usage. I don't think there is a compelling reason for doing any one particular thing. Multiple on one CAA is not an explicitly approved syntax so, for me, falls into section 5.8 about Misconfiguration Hazards and is CA discretion.

5.8. Misconfiguration Hazards

Because the "accounturi" and "validationmethods" parameters express restrictive security policies, misconfiguration of said parameters may result in legitimate issuance requests being refused.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.