BRs: Clarify policies around notBefore and notAfter for Subscriber and CA certificates

[sleevi]

During the 2021-04-22 call of the Validation Working Group, one area of discussion around certificate profiles was about what policies, if any, to express around the validity periods of certificates.

The Baseline Requirements are now unambiguous with respect to the maximum Validity Period, and that the Validity Period is in relation to the certificate's notBefore and notAfter. However, a known area of ambiguity, and which Root Programs have developed their own policies towards, is with respect to the notBefore and whether "backdating" (a notBefore less than the current datetime) is permitted, or "forward dating" (a notBefore greater than the current datetime) is permitted.

With respect to forward dating, given that a certificate is minimally an assertion that at this point in time, the information was correct, it does not seem reasonable to permit notBefore > the current time, for CA certificates or for server certificates.

However, with respect to backdating, there was some concern expressed that "some" backdating, within some reasonable bounds, should be acceptable, as a way of helping address compatibility issues with Relying Parties who are encountering mild clock skew, and for certificates that will be immediately used.

For example, if an RP's clock is off by a few hours to a few days, setting the notBefore to be the issuance time would prevent those clients from validating the certificate.

On the call, there were several options explored for server certificates:

• Allowing some "small" window (e.g. 7 days) in the past, even if the information was not validated at that point in time, because the actual certificate itself will only be usable going forward.
• Allowing some larger window (e.g. 30 days) if the information was both accurate and reusable (e.g. a previously completed domain validation within the reuse period)

One concern raised was backdating to avoid technical requirements, and so any backdating, if allowed, would still need to require compliance with the "current" certificate profile (at time of issuance), not the certificate profile allowed at the time in the past the notBefore is set to.

With respect to sub-CA certificates, backdating is often a technical necessity when multiple certificates with the same (Subject, SPKI) exist (i.e. cross-certificates), in order to ensure the "correct" certificate chain is preferred by relying parties. In general, it seemed that backdating for the purposes of Cross-Certificates SHOULD be allowed, within the validity period of the original Cross-Certificate and there remains an unbroken series of audits for that past duration. However, for new Sub-CAs that are not cross-certificates, there was no identified technical reason to permit backdating.