[cabf_validation] Backing Certificates

[Ryan Sleevi]

On Mon, Apr 26, 2021 at 3:58 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> 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.
>>
>
> 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.
>

Yeah, I'm aware of the work Google did in the space previously -
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/04822a2487f3cd27ff92dbfddf42d947acdc4257.pdf
- 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).

TLS Delegated Credentials
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-3>
(deployed by Facebook
<https://engineering.fb.com/2019/11/01/security/delegated-credentials/> and
Cloudflare <https://blog.cloudflare.com/keyless-delegation/>, as well as
Mozilla
<https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/>)
uses a validity period of just 7 days for the Delegated Credentials, with
an explicit acknowledgement
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10#section-5.1>
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.

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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210426/7afd89ba/attachment.html>