Should the Baseline Requirements require CAs performing Method 22 to honor the ACME dns-persist-01 policy parameter (making the draft's scope restriction enforceable against publicly-trusted CAs), or is this out of scope for the BRs?
Background
The IETF draft draft-ietf-acme-dns-persist, Section 4.1 item 4 and Section 5.1 defines a policy parameter with a policy=wildcard value. When present, the CA MAY consider the validation sufficient for the FQDN, its subdomains, and wildcard certificates. When absent or set to any other value,
"the validation applies only to the specific FQDN being validated. CAs MUST NOT consider such validation sufficient for wildcard certificates or subdomains."
The draft's default is FQDN-only; wildcard and subdomain scope requires an explicit policy=wildcard gate.
The Gap
Only the CA/Browser Forum Baseline Requirements (and root program requirements) are binding on publicly-trusted CAs; the IETF draft is not unless normatively referenced.
BR Method 22 Section 3.2.2.4.22 does not contain a policy parameter.
Its item 5 states:
"The issue-value MAY contain additional parameters. CAs MUST ignore any unknown parameter keys,"
instructing CAs to ignore the policy parameter unless the CA explicitly decides to recognize it.
A BR-compliant CA performing Method 22 is therefore allowed to ignore the policy parameter. The BRs also state that Method 22 explicitly permits wildcard and subdomain issuance once the base FQDN is validated.
This leaves relying parties with inconsistent enforcement of the policy parameter across CAs.
Note: The draft introduces a mechanism that allows domain owners to control the scope of a domain validation. This would be new precedent for the BRs for which the implications should be considered.
In practice
open-mpic issue #69 noted that the reference MPIC implementation parses only accounturi and persistuntil and ignores policy. The maintainer (@birgelee, a draft co-author) confirmed that ignoring policy is currently BR-compliant, because Section 3.2.2.4.22 does not mention the parameter and instructs CAs to ignore unknown keys.
Alternative to Consider
This could also be addressed by extracting dns-persist-01 into a separate DCV method that normatively references the IETF draft.
Should the Baseline Requirements require CAs performing Method 22 to honor the ACME
dns-persist-01policyparameter (making the draft's scope restriction enforceable against publicly-trusted CAs), or is this out of scope for the BRs?Background
The IETF draft draft-ietf-acme-dns-persist, Section 4.1 item 4 and Section 5.1 defines a policy parameter with a
policy=wildcardvalue. When present, the CA MAY consider the validation sufficient for the FQDN, its subdomains, and wildcard certificates. When absent or set to any other value,The draft's default is FQDN-only; wildcard and subdomain scope requires an explicit
policy=wildcardgate.The Gap
Only the CA/Browser Forum Baseline Requirements (and root program requirements) are binding on publicly-trusted CAs; the IETF draft is not unless normatively referenced.
BR Method 22 Section 3.2.2.4.22 does not contain a policy parameter.
Its item 5 states:
instructing CAs to ignore the policy parameter unless the CA explicitly decides to recognize it.
A BR-compliant CA performing Method 22 is therefore allowed to ignore the policy parameter. The BRs also state that Method 22 explicitly permits wildcard and subdomain issuance once the base FQDN is validated.
This leaves relying parties with inconsistent enforcement of the policy parameter across CAs.
Note: The draft introduces a mechanism that allows domain owners to control the scope of a domain validation. This would be new precedent for the BRs for which the implications should be considered.
In practice
open-mpic issue #69 noted that the reference MPIC implementation parses only
accounturiandpersistuntiland ignorespolicy. The maintainer (@birgelee, a draft co-author) confirmed that ignoringpolicyis currently BR-compliant, because Section 3.2.2.4.22 does not mention the parameter and instructs CAs to ignore unknown keys.Alternative to Consider
This could also be addressed by extracting
dns-persist-01into a separate DCV method that normatively references the IETF draft.