<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:58 PM Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.org</a>> wrote:</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"><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></div></blockquote><div><br></div><div>Yeah, I'm aware of the work Google did in the space previously - <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/04822a2487f3cd27ff92dbfddf42d947acdc4257.pdf">https://storage.googleapis.com/pub-tools-public-publication-data/pdf/04822a2487f3cd27ff92dbfddf42d947acdc4257.pdf</a> - but that explicitly excluded samples of < 24 hour of skew, and also only looked at users who encountered TLS errors (and thus not an overall percentage).</div><div><br></div><div><a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-3">TLS Delegated Credentials</a> (deployed by <a href="https://engineering.fb.com/2019/11/01/security/delegated-credentials/">Facebook</a> and <a href="https://blog.cloudflare.com/keyless-delegation/">Cloudflare</a>, as well as <a href="https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/">Mozilla</a>) uses a validity period of just 7 days for the Delegated Credentials, with an <a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-5.1">explicit acknowledgement</a> that clock skew is an operational risk, but I haven't heard of significant operational issues with it (although I haven't been following closely), so it's very likely that "less than 7 days" is entirely reasonable.</div><div><br></div><div>My assumption for CAs is going to be data based on support queries and support load, which hopefully they can provide in concrete terms (e.g. x% of support cases for Y million certs) rather than relative (i.e. "we hear some users have issues"). But this also ties back into v1 and v2 for profiles: it could be that the entirely reasonable end goal (absent evidence) is to eliminate backdating, and a v1 "common sense" profile gives CAs enough breathing room to incrementally improve their profile and gather that data. For example, an ideal outcome would be "We started with X days, then moved to Y days (where Y < X). We saw a Z% increase in support tickets initially, but after N days, those subsided", which gives operational experience data to help drive the discussion about whether X, Y, or 0 :) </div><div><br></div><div> </div></div></div>