<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 3:05 PM Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.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"><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></blockquote><div><br></div><div>If I'm understanding correctly, this would allow backdating for up to a year. That seems significantly longer than either desirable or necessary, but it wasn't clear if that was intentional, and if so, if it was merely a consistency argument or if there was a further use case beyond clock skew?</div><div><br></div><div>If I'm also understanding correctly, it would allow backdating if you stay with your current CA, but disallow backdating if you change CAs. From the EVGs, we know that this significantly disadvantages end users, by making it harder to change CAs, whether for business reasons (e.g. a better deal) or in response to CA incidents (e.g. CA X keeps screwing up validation leading to revocation, or CA Y is being phased out from root programs due to issues). <br></div><div><br></div><div>To that end, it's also unclear how relevant the "clock skew" issue is, and so data like this from ISRG is super-useful in figuring out what's a "reasonable" threshold. To be honest, 30 days felt unreasonably long, 7 days as well, and so something like an hour or two feels... closer to reasonable, if it's allowed at all? To some extent, clock skew can/should be viewed as an RP problem (i.e. similar to nameConstraints), and unless it's particularly wide-spread or egregious (i.e. with data to support the claim), it seems like even any allowance should be carefully reasoned about.</div><div><br></div><div>There are concrete issues with backdating, such as how RPs and Root Programs can verify whether or not a given CA was in compliance with the requirements, both for certificates issued "newer" (and thus subject to more requirements) and for distinguishing certificates issued after requirements have been lessened (and appropriately backdated) vs those that were inappropriately issued during a time of more rigid requirements (contemporaneously misissued).</div><div><br></div><div>Obviously, intermediates are more complex, due to the intersection of some clients wanting to use "greatest overall validity period", others wanting to use "newest notBefore", and still others wanting to use "latest notAfter". Yet those three requirements combined suggest that there's still a potential at a backdating-less future: if an intermediate has validity 0...10, you can satisfy each of those constraints with validity 5...16 when issuing a new version at T=5, rather than backdating to 1..12. The only distinction I'm aware of is around how long Issuing CAs wish to allow third-party sub-CAs to operate (e.g. the contract period, when using 3P Sub-CAs), and I'm not sure how important that is.</div><div><br></div><div>I mention all of this because while the Issue looks to sort of capture what a "minimum" backdating policy is (for profiles v1), I don't want it to be thought of backdating as indefinitely allowable (e.g. it should be fixed for profiles v2). I think the profiles work needs to say <i>something </i>about the validity periods, so tried to pick an initial "not too different from observed status quo" today, while hopefully sparking discussion like this about what the end state should be, if it's allowed at all.</div></div></div>