[cabfpub] notBefore dates for certificates

[Peter Bowen]

> On Aug 1, 2017, at 8:07 PM, Geoff Keating <geoffk at apple.com> wrote:
> 
>> On 1 Aug 2017, at 6:13 pm, Peter Bowen via Public <public at cabforum.org> wrote:
>> 
>> We’ve had an interesting situation come up that isn’t clearly covered in the BRs.
> …
>> So I have two questions:
>> 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?
> 
> I can’t immediately think of any reason not to allow this, but if you do this, please create a precertificate, upload it to CT, and put a SCT in the certificate as an indicator of the the actual time of issuance.
> 
> (I think it’s a good general rule that the more weird is the thing you’re doing, the more transparent you want to be about it.)

I agree.   Hence this post.  There is nothing in the BRs that says you can’t backdate, but I wanted to be transparent about it.

>> 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?
> 
> From the issuance date—in the BRs, the ‘Validity Period’ runs from issuance to expiry.  In fact I can’t find anything in the BRs about when the notBefore timestamp should be.
> 
> What people will actually check is the time between the SCT and the certificate expiry.  Make sure that’s less than 39 months/825 days.

Oct 31, 2020 is 39 months from today, so that is the actual max.

However, I thought I remembered Chrome adding some date checks.  After a little poking I found CertVerifyProc <https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.h?l=28&ct=xref_jump_to_def&gsn=CertVerifyProc>::HasTooLongValidity <https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=875&gs=cpp%253Anet%253A%253Aclass-CertVerifyProc%253A%253AHasTooLongValidity(const%2Bnet%253A%253AX509Certificate%2B%2526)%2540chromium%252F..%252F..%252Fnet%252Fcert%252Fcert_verify_proc.cc%257Cdef&gsn=HasTooLongValidity&ct=xref_usages> (https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=874 <https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=874>)

We would need to date back to March 31, 2015 to get longer than 39 months accepted by Chrome; it would then accept 60 months, which only takes one to March 31, 2020; that doesn’t really help.   

If we could backdate even further it would be pre-BRs, but that maxes out at July 1, 2019.

So it seems that if we want to go for Jan 1, 2017, then the max notAfter is March 31, 2020.

Of course none of this matters if Chrome compatibility is not an issue.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170801/28084699/attachment.html>