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
