Forward-date certificates?

[James R Moir]

Is it allowed to sign certificates that are 'forward dated'?

Such as a certificate with not-before set to a date in future? Any problems to issue for some vetting that is done 'now' but the certificate is 'future'?

Jim

[Ryan Sleevi]

On Tue, Jun 29, 2021 at 1:13 PM 'James R Moir' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Is it allowed to sign certificates that are 'forward dated'?

Such as a certificate with not-before set to a date in future? Any problems to issue for some vetting that is done 'now' but the certificate is 'future'?

There's some discussion about this on https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c26 (and subsequent comments)

It's also touched on https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date 

There's also discussion in the CA/Browser Forum (which is proposing to make this unambiguously prohibited). Such discussion at https://archive.cabforum.org/pipermail/validation/2021-May/001659.html and https://archive.cabforum.org/pipermail/validation/2021-June/001667.html

Do you have example certificates where the `notBefore` is being forward dated?

[Aaron Gable]

Out of curiosity, is there a meaningful difference between these two certificates:
* Validation data acquired at date X; certificate issued at date X + 397 days; certificate notBefore = X + 397; certificate notAfter = X + 397 + 397 (i.e. not forward-dated, but significant time between validation and issuance)

* Validation data acquired at date X; certificate issued at date X; certificate notBefore = X + 397; certificate notAfter = X + 397 + 397 (i.e. forward-dated, but still within the BRs 4.2.1 validation data reuse period)

In the wild, I believe that the only way to tell the difference between these certificates would be by their embedded SCTs (or by acquiring the second one before its notBefore date).

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHERm5XZKvCAY_TAaArPR7SVJ1ku1%3DL-kMG%3DT_4rjVvHjw%40mail.gmail.com.

[Ryan Sleevi]

On Tue, Jun 29, 2021 at 2:12 PM Aaron Gable <aa...@letsencrypt.org> wrote:

Out of curiosity, is there a meaningful difference between these two certificates:
* Validation data acquired at date X; certificate issued at date X + 397 days; certificate notBefore = X + 397; certificate notAfter = X + 397 + 397 (i.e. not forward-dated, but significant time between validation and issuance)

* Validation data acquired at date X; certificate issued at date X; certificate notBefore = X + 397; certificate notAfter = X + 397 + 397 (i.e. forward-dated, but still within the BRs 4.2.1 validation data reuse period)

In the wild, I believe that the only way to tell the difference between these certificates would be by their embedded SCTs (or by acquiring the second one before its notBefore date).

Correct. This is something that could only be established by virtue of pre-certificates recording the commitment to issue, or by the audit logs.

The certificate issued at date {X + 397} would clearly need to comply with the requirements in force at time of issuance.

However, issuing a certificate at date {X} creates the issue that it would need to comply with the requirements at date {X}, which may differ from those at {X+397}. We have seen, as a practical matter, CAs (intentionally or unintentionally) use this to evade requirements/prohibitions that are coming in force (e.g. at {X+1}), by claiming they were issued at date {X}, where it was still OK.

While nominally some of this is mitigated by clients enforcing "complies with the requirements at time of `notBefore`", this only goes so far: obviously, there are procedural requirements which cannot be validated based on the certificate alone.

[Aaron Gable]

Ah yeah, thanks for that perspective, that makes sense!

Aaron