Support for `policy=wildcard` in DNS-PERSIST validation

[lmarte78]

Hello,

while reviewing the DNS-PERSIST implementation in Open MPIC, I noticed that the DNS TXT record parser appears to validate only the following parameters:

• accounturi
• persistuntil

and ignores all other parameters.

In particular, I could not find any handling of the policy=wildcard parameter described in the DNS-PERSIST draft.

From my reading of the draft, policy=wildcard is required for a CA to treat a DNS-PERSIST authorization as valid for wildcard certificates and/or subordinate names. Without this policy, the authorization scope should remain limited to the validated FQDN.

Looking at evaluate_persistent_dns_response(), additional parameters seem to be ignored, and I do not see any mechanism for exposing wildcard authorization information to later validation stages.

Could you clarify:

1. Is support for policy=wildcard currently implemented elsewhere in Open MPIC?

2. If not, is support for wildcard policy evaluation planned?

3. How should a CA using Open MPIC distinguish between:

   • authorization for a single FQDN
   • authorization that explicitly permits wildcard issuance

Thanks!

[birgelee]

Hi @lmarte78 ,

Thanks for bringing this up. The good news is I am an author of the DNS-persist Internet-Draft and a maintainer of open MPIC, so you can expect high alignment on them.

I guess I will open by answering this question simply that currently the Open MPIC implementation was written based on the CA/Browser Forum Ballot which did not define the policy parameter. At the time of the original implementation, policy did not exist and the best practice to future-proof an implementation like this is to proceed with all unknown parameters. (This also allows CAs to support their own parameters that may not need to be MPIC checked.) Thus, the current implementation proceeds even in the presence of the parameter.

Obviously implementation is planned to maintain alignment with the Internet-Draft. We are doing RFC 8657 soon and I could see putting it in during that implementation as well.

The current strategy I am considering to put this in is to have open MPIC respond with two new fields on the dns-persist DCV check details. One that is policy_present (true or false if the user provided the policy parameter) and the other policy_value (a string that matches the policy observed by MPIC). I will have to think a bit about how policy interacts with quorum. There are also arguments for a simpler policy_wildcard that is true/false since the only policy defined is wildcard right now and all other policies are equivalent to no policy, but this approach does mean we have to update open MPIC when there is a new policy.

So (simple answer) yes, policy=wildcard implementation is coming and its more just a historical reason that its not in yet (i.e., it wasn't in the original CA/Browser Forum draft)

---

More political answer: This actually probably doesn't matter.

There are three reasons Open MPIC arguably may not need to implement this right now.

1. No reference to this I-D or RFC in the baseline requirements: The only normative guidance for public trust CAs is the CA/Browser Forum Baseline Requirements and any additional constraints imposed by root programs. Neither of these reference the ACME dns-persist Internet Draft (I-D). Until the I-D or eventual RFC is pulled into the BR by reference, nothing in the RFC is technically binding on CA behavior. Obviously its a good thing CAs do faithfully implement RFCs and it arguably supports some of the more open ended language in the BRs (e.g., around having up-to-date systems and implementing security best practices), but if an RFC is not mentioned explicitly, it technically is not binding. IETF people will often argue incessantly about this but I have seen it brought up a couple times by Forum veterans. Right now the CA/Browser Forum Baseline Requirements for TLS Server Certs Section 3.2.2.4.22 defines persistent DNS validation and makes no reference to a policy parameter (in fact it says CAs must ignore all unknown parameters).
2. No reference in MPIC specification for 3.2.2.4.22: Even if there was a policy parameter, some could argue it does not need to be checked by MPIC. The only parameter explicitly named in the MPIC check section of 3.2.2.4.22 is accounturi . The statement "demonstrates the Applicant’s control over the domain" arguably could be interpreted to include a valid policy parameter, but I don't think this interpretation is a given. I personally would not rely on this argument with an auditor (if the CA/Browser Forum mentioned the policy parameter I would MPIC check it), but this argument is honestly not unreasonable.
3. The I-D is not final and does not yet represent consensus of the IETF community: An I-D (even an adopted I-D) is a standard in progress. Obviously some are extremely mature and I feel dns-persist is one of them (particularly this part of the document). However, if I wanted to write a "henry" parameter that must be set to "greatest-software-engineer-ever" for issuance to proceed I could personally push v2 with the new "henry" parameter in it as I have write on that github repo and am an author. Once a standard matures to RFC, it has gone through the several different levels of the IETF process and had editorial and content reviews. At that point changes can only be made through errata and going through the process again. Thus, its often risky to develop features based on an I-D that is not yet an RFC. I have faith this parameter will make it through, so I am happy to implement it, but there are other parts of the draft still being debated.

So long story short, I am happy to put it in, but you are probably fine running your CA for the time being without this feature.

Best,
Henry

[lmarte78]

Hi @birgelee ,

Thank you for such a detailed and insightful response. I really appreciate you taking the time to share both the historical context and the standards-perspective background.

After discussing this internally with senior members of my team, we actually arrived at the exact same conclusion regarding the CA/Browser Forum Baseline Requirements. Since Section 3.2.2.4.22 does not currently mention the policy parameter (and explicitly instructs CAs to ignore unknown parameters), we agree that running the CA without this validation is perfectly fine and compliant for the time being.

Regarding your proposed strategy for the future implementation, providing policy_present and policy_value in the response details sounds like a very solid and flexible approach to handle quorum and future-proof any upcoming changes.

As a side note, you mentioned the upcoming alignment with RFC 8657. In our current CA setup, we already handle RFC 8657 by parsing and validating the CAA record extensions directly within our core CA software using the CAA details returned by Open MPIC.
With the planned Open MPIC update to support RFC 8657, do you intend to have Open MPIC evaluate those ACME-binding constraints directly within its own validation logic, or will it continue to just expose the raw CAA data for the CA to evaluate?

Thanks again for your feedback and for your great work on the project!

Best regards,
Luca