[openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj

[Victor Wagner]

On Tue, 14 Jul 2015 20:35:31 +0200
Jakob Bohm <jb-openssl at wisemo.com> wrote:

>
> Does ASN1_TIME_set_string() support dates outside the
> time_t range of the local libc?

Why do yo need time dates outside of 64-bit integer range?
Sun would explode into red giant sooner than that amount of time passes.

 
> This is important when creating root certs with expiry
> dates after 2038 (specifically, any time >= epoch+2**31).

I don't think that it is a good idea to issue certificates with 
expire dates after 2038 now.

Notice - several years ago MD5 collision was discovered, and
certificates signed with md5WithRsaEncryption was phased out.

Now browser manufacturers planning to phase out sha1 certificates, even
though there is no published collision generation for sha1, people
are thinking it is possible enough to avoid using this hashing
algorithms.

There are interesting mathematic results concerning big number
factorization, and experiments with quantum computing, so it seems that
soon we'll have to abandon RSA at all and use only EC algorithms.

So I don't think that one should issue certificates valid for more than
10 years, if he hopes to have even marginal security.

> It is also important when creating self-signed Android
> apk signing certificates (which /must/ be valid for at
> least 30 years).
  
Does android really have 32-bit time_t? And is it really signed?
I've thought that all modern systems have already switched to 64-bit
time_t or at least iterpret time_t as unsigned, which give time up to
2106.