[cabf_validation] Backing Certificates

[Aaron Gable]

On Mon, Apr 26, 2021 at 12:23 PM Ryan Sleevi <sleevi at google.com> wrote:

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

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.


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

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.


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

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210426/94590bec/attachment-0001.html>