[cabfpub] notBefore dates for certificates

[Gervase Markham]

On 02/08/17 02:13, Peter Bowen via Public wrote:
> We have a customer who has a system that does not have a persistent
> clock when it is first unboxed. 

Is there any way it can lose that clock afterwards, e.g. if it is
completely reset? In other words, is it _only_ at time of first unboxing
that it has this problem, or could it potentially have the same problem
at other times?

One solution might be for the box to be modified to not check dates, but
to check revocation, and issue from a CA which has guaranteed to
maintain revocation information for such certs indefinitely.

> You might have already spotted the problem — at some point the server
> certificate is going to get renewed and will probably have a notBefore
> date that is after 2017-01-01.  This will cause the firmware and
> configuration update to fail.

Could it get the time via non-SSL means first? Isn't this what ROUGHTIME
is for? :-)

> 1) Does anyone think setting a notBefore well before the issuance dates
> a problem, as long as the certificate includes a timestamp that
> represents the issuance date and the CA previously issued a certificate
> for the same domain name(s) to the same applicant that has a validity
> period that spans from the notBefore to issuance date?

Backdating notBefore is discouraged (and for some CAs, banned). The
trouble with saying "but there's a CT timestamp which gives the real
date" is that then all clients start to take a dependency on
understanding CT information.

> 2) What is the latest acceptable notAfter date?  39 months (or 825 days
> in the future) from the notBefore date or from the issuance date?

It's measured from the notBefore date.

Gerv