<div dir="ltr"><div dir="ltr">On Mon, Apr 26, 2021 at 12:23 PM Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:</div><div class="gmail_quote"><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 class="gmail_quote"><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></div></blockquote><div><br></div><div>Yep, precisely, this is solely an argument from consistency. I too *believe* that backdating can/should be restricted to a much shorter timeframe than ~398 days, but I personally have little to no experience/grounds with which to make that argument.</div><div> </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 class="gmail_quote"><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). </div></div></div></blockquote><div><br></div><div>Oh, this is a very interesting point that hadn't occurred to me. Yes, if an end-user wants or needs a larger backdate for some reason, then yes that would provide some measure of CA lock-in. This is obviously reduced in proportion to the maximum allowable backdate, with something on the order of hours providing essentially no incentive to stay with a CA that already has your validation cached.</div><div> </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 class="gmail_quote"><div></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></div></blockquote><div><br></div><div>We unfortunately have no way to tell if our 1-hour clock skew mitigation is "sufficient". If there are subscribers who are unable to use our certificates immediately after issuance due to a clock skew greater than one hour, we have no way to detect that failure mode. But to the best of my knowledge we have also never received any complaints about a certificate being unusable due to its notBefore date.</div><div><br></div><div>Aaron</div></div></div>