[cabf_validation] Backing Certificates

[Ryan Sleevi]

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

> 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:
>
> Section 4.2.2, or Section 4.3.1:
> 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.
>
> 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?".
>

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?

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

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.

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

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.

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