<div dir="ltr">Merely as a data point, Let's Encrypt / ISRG's ACME implementation (Boulder) does not allow any forward-dating[1]. We do backdate all of our certificates[2] a small amount (1 hour) to provide leeway for clock skew, and separately enforce that certificates are not backdated[3] by more than a small amount (1 hour 5 minutes).<div><br></div><div>Speaking personally: since we do allow validation re-use (for up to 398 days, as of SC42v2), it would make sense to also explicitly limit backdating to the period in which the CA had validated the certificate data. Because a given certificate (particularly OV or EV) may contain multiple pieces of data which were validated at different times, the backdating must be restricted to the period of time when *all* certificate data was validated, not the earliest validation. And then there should be a small (on the order of hours) grace period to account for clock skew. I would propose something like:<br><br>Section 4.2.2, or Section 4.3.1:</div><div>CAs SHALL NOT issue Subscriber Certificates containing `notBefore` dates earlier than 24 hours prior to the most recent time at which certificate data was validated as per Section 3.2.</div><div><br></div><div>This has a few falings: I'm honestly not sure which section it better fits; the phrasing is awkward; and it doesn't address the scenario of "I perform this same validation every 30 days and it's always been valid for the past year; how far back can I backdate?".</div><div><br></div><div>Aaron</div><div><br></div><div>[1] <a href="https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/issuance/issuance.go#L328-L330">https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/issuance/issuance.go#L328-L330</a></div><div>[2] <a href="https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/ca/ca.go#L479">https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/ca/ca.go#L479</a></div><div>[3] <a href="https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/issuance/issuance.go#L325-L327">https://github.com/letsencrypt/boulder/blob/5457680a9c8ce34d0456ccf289ed347a8529a31e/issuance/issuance.go#L325-L327</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 22, 2021 at 3:53 PM Ryan Sleevi via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Per our call today, I filed <a href="https://github.com/cabforum/servercert/issues/266" target="_blank">https://github.com/cabforum/servercert/issues/266</a> to track the discussion had around backdating certificates, both subscriber certs and CA certificates.<div><br></div><div>Given that the concerns of backdating equally tie in to the validation of information, it seemed useful to have the discussion within the subcommittee to see if there's alignment on a path forward for reducing/prohibiting backdating.</div></div>
_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</blockquote></div>