Boulder ignores RFC 8657 accounturi

Even though RFC 8657 does state in section 5.2 that

Domains configuring CAA records for a CA MUST NOT assume that the restrictions implied by the “accounturi” and “validationmethods” parameters are effective in the absence of explicit indication as such from that CA.

I would like you to consider failing the validation process in boulder when unrecognized parameters are present in the CAA issue and issuewild properties.

Or go all out and amend RFC 8659 so that the Issuer MUST deny the issuance of certificates if it does not understand any of the optional parameters for issue and issuewild properties.

This would, IMO, improve the user experience in a meaningful way by avoiding nasty surprises.

Cheers!

4 Likes

Seems like a solid idea for Let’s Encrypt to treat parameter names as “critical”.

It would stop a typo in validationmethods from going unnoticed, for example. Though, in the same vein, implementing might require reviewing existing CAA records to see how many domains it would break.

What do you think @jsha?

4 Likes

This seems like a decent idea. RFC 8659 says:

The semantics of parameters to the issue Property Tag are determined by the Issuer alone.

So we have the freedom to reject parameters that are unsupported.

Note that we would probably launch this alongside ACME-CAA support, which is not currently live.

4 Likes

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