Validity period for Technically Constrained Sub-CA and validation period for Domain Namespace

[sleevi]

There's some interesting interplays for domain validation periods worth clarifying.

Section 4.2.1 limits the reuse of domain validation documents to 398 days prior to issuing a certificate, as of 2021-10-01, which limits which domains can appear within the Subject Alt Name. The validity period for certificates is similarly fixed, by Section 6.3.2, thus ensuring that the upper bound of a "stale" domain name validation is (cert lifetime + cert reuse period - 1 second); ensuring that at least every 796 days, all domain names appearing within a certificate have been revalidated.

Section 1.3.2 of the BRs

servercert/docs/BR.md

Lines 181 to 201 in cda0f92

	### 1.3.2 Registration Authorities
	With the exception of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address), the CA MAY delegate the performance of all, or any part, of [Section 3.2](#32-initial-identity-validation) requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of [Section 3.2](#32-initial-identity-validation).
	Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to:
	1. Meet the qualification requirements of [Section 5.3.1](#531-qualifications-experience-and-clearance-requirements), when applicable to the delegated function;
	2. Retain documentation in accordance with [Section 5.5.2](#552-retention-period-for-archive);
	3. Abide by the other provisions of these Requirements that are applicable to the delegated function; and
	4. Comply with
	a. the CA's Certificate Policy/Certification Practice Statement or
	b. the Delegated Third Party's practice statement that the CA has verified complies with these Requirements.
	The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA's own organization.
	The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied:
	1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise
	RA's verified Domain Namespace.
	2. If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name "XYZ Co." on the authority of Enterprise RA "ABC Co.", unless the two companies are affiliated (see [Section 3.2](#32-initial-identity-validation)) or "ABC Co." is the agent of "XYZ Co". This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.'s Registered Domain Name.
	The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.

permits CAs the use of a "verified Domain Namespace" for Enterprise RAs. An Enterprise RA is exempted from an audit report normal for Delegated Third Parties by Section 8.4

servercert/docs/BR.md

Line 2349 in cda0f92

For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in [Section 8.4](#84-topics-covered-by-assessment), that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.

Section 7.1.5 of the BRs

servercert/docs/BR.md

Lines 2171 to 2172 in cda0f92

	a. For each `dNSName` in `permittedSubtrees`, the CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control).
	b. For each `iPAddress` range in `permittedSubtrees`, the CA MUST confirm that the Applicant has been assigned the IP Address range or has been authorized by the assigner to act on the assignee's behalf.

defines the requirements for a Technically Constrained Subordinate CA Certificate, including a requirement to enumerate the verified Domain Namespace(s) for the TCSC's permittedSubtrees

This opens a few questions:

• What requirements, if any, exist for verifying the Enterprise RA's Domain Namespace? The term "verified Domain Namespace" is used, but the process for verification is not explicitly defined to be Sections 3.2.2.4 / Section 3.2.2.5
  • The CA is required to validate the domain names of the certificates themselves (the fact that 3.2.2.4 and 3.2.2.5 cannot be delegated, and MUST be performed for every certificate), but also to ensure that the validated domain name appears within the verified Domain Namespace. Is it possible for the domain to validate according to 3.2.2.4/3.2.2.5, but be outside of the verified Domain Namespace?
• What is the period that validations for the verified Domain Namespace can be used? Section 4.2.1 describes permitted reuse, but it's unclear whether the CA is performing the task of "verified Domain Namespace" on every certificate issuance, and may simply be reusing old documents, or whether the Enterprise RA's Domain Namespace is only verified once, and its only the certificates reusing old documents.
• Given that a TCSC's permittedSubtrees list the domains a CA is authorized to issue for, what is the maximum acceptable validity period for the TCSC? This is currently not specified, creating a situation where a TCSC may be created for multiple years.
  • This is further compounded by the fact that although a TCSC is expected to follow all of the obligations of Section 3.2.2.4 / 3.2.2.5, it's possible to exempt such certificates from CAA checking and they're naturally exempted from the audit requirement, so there's limited guarantee about how well and correctly this verification is performed. The closest we get to verification is seeing if any of the domains are outside of the permittedSubtrees, but if there is no CA obligation to validate that data remains correct, this seems to be an issue.
  • Section 4.9.1.1 requires revocation if "The CA is made aware of any circumstance indicating that use of a Fully‐Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);", but this is omitted from Section 4.9.1.2. For a TCSC, the closest relevant revocation requirement would be "The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;", but that does not bring an obligation to periodically revalidate the domain name.

Possible (and simple) solutions:

• Ensure that the Enterprise RA's verified Domain Namespace is re-verified annually, without dispensation to information or document reuse
• Ensure that TCSC's validity period is, at the absolute upper value, equal to (lifetime max) + (reuse max) - 1 second; for example, 796 days. However, further reductions in domain revalidation reuse periods suggest this period could be reduced to something such as 418 days (e.g. if domain validation was reduced to 30 days, as proposed as the next logical step).
• Add to 4.9.1.2 requirements regarding revocation for TCSCs that have dNSName or iPAddress constraints

Longer term, this may require a more careful rethinking of technically constrained subordinate CA certificates, primarily those used for TLS, such as not exempting from the audit requirements, and if the validity period is still allowed to exceed that of Subscriber Certificates, an obligation for regular re-validation in line with the domain reuse period (e.g. every 30 days)

[sleevi]

List discussion: https://archive.cabforum.org/pipermail/validation/2021-October/001721.html

[wthayer]

Discussed at 11/2/23 Validation subcommittee meeting. Clint said that this is on Apple’s backlog. In particular clarifying that a domain name in a technically constrained subCA needs to be revalidated on the same cadence as any other domain name. Clint said that he hopes to work in this in the next year.