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

[Jakob Bohm]

On 15/07/2015 11:13, Victor Wagner wrote:
> 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.
It's all about 32 bit ints, not 64 bit ints.
>   
>> 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.
On the other hand, many of the new SHA-2 root certificates
also exist as cross certificates issued by (otherwise
disabled) old SHA-1 and MD5 root CAs that were deployed
into browsers and mobile devices before SHA-2 support was
added to most browsers and operating systems.  This only
works because those old SHA-1/MD5 CAs were issued with
long lifetimes that outlast their actual active use.

At least one major CA made the mistake of originally
issuing their old root cert with a lifetime that
expired a few years ago, while the difficult to
update mobile devices that trust that cert remains
functional (hardware hasn't died).

Thus an update signed by a competing CA is needed to
provision those devices with the new extended lifetime
of that root cert, so those devices can then trust new
certificates issued with longer keys (close to the limit
of the crypto libraries embedded in ROM images).

A more widespread problem of this kind is that Windows 8
and Windows 8.1 do not include most of the Microsoft
accepted SHA-2 roots out of the box, but will instead
download those one by by one from Microsoft if and only
if the system has been configured to implicitly trust
any and all future changes to Microsoft's list of trusted
CAs.

> 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.
I have yet to see any convincing arguments why QC doesn't
break EC too.  So far the only argument I have seen is
that one published QC algorithm is most easily applied
to DL and RSA keys, which says very little about the
applicabilityof QC speedups to other NP problems.
> 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.
I haven't checked the local code on Android for this,
except that it does work very well with post-2038
expiry dates when validating certs.  Note that most
Android devices use 32-bit CPUs with 32-bit int.

However the Linux/OSX/Windows workstations that are
used to generate the self-signed end certificates
that identify Android software packages will often be
32 bit systems with 32 bit signed time_t.  And the
Android Market (Google Play) upload requirements
insist that the expiry is after 2038, in order to
recognize future App updates as being the same app
with access to previous version data.

If and when the QC disaster happens, Android will
presumable start requiring double signatures (the
file format supports this) with both the original
App cert and a new stronger cert.  The specific
way such a requirement will be formulated (e.g.
should the new cert be issued by the old cert or
not, in which relative order should it be placed
in the signature collection etc.) has not yet
been defined.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded