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.
