[En-Nut-Discussion] [PATCH 1/2] FIX: accept certificate without expiration date

[Uwe Bonnes]

>>>>> "Krzysztof" == Krzysztof Sawicki <krzysztof.sawicki at mlabs.pl> writes:

    Krzysztof> On 24.04.2017 16:34, Uwe Bonnes wrote:
    >>>>>>> "Krzysztof" == Krzysztof Sawicki <krzysztof.sawicki at mlabs.pl>
    >>>>>>> writes:
    >> 
    >> 
    Krzysztof> RFC5280 4.1.2.5
    >> 
    Krzysztof> "In some situations, devices are given certificates for which
    Krzysztof> no good expiration date can be assigned. For example, a
    Krzysztof> device could be issued a certificate that binds its model and
    Krzysztof> serial number to its public key; such a certificate is
    Krzysztof> intended to be used for the entire lifetime of the device."
    >> 
    >> Krzysztof,
    >> 
    >> is the problem really existant? If you emit a certificate and set
    >> not_after = (time_t) 0x7fffffff, the check (tv.tv_sec >
    >> cert->not_after) will never trigger with a 32 bit time
    >> implementataion.
    >> 
    >> Otherwise the standard talks about a constant of (GeneralizedTime)
    >> 99991231235959Z as marker.

    Krzysztof> Uwe, problem really exists, I checked this again to be 100%
    Krzysztof> sure. time_t aka long is signed and both tv.tv_sec and
    Krzysztof> cert->not_after are of type time_t. So we compare two signed
    Krzysztof> ints. BTW (time_t)(-1)=0xFFFFFFFF not 0x7FFFFFFF, but this
    Krzysztof> makes no difference in the situation.

not_after = -1 is not mentioned in the RFC as indicator for a certificate
without expiration. So -1 and 0x7fffffff are both non-compliant. But by
using 0x7fffffff no code change is needed and the certificate is still valid
as long as time_t does not overrun in 2038.

I refrain to change the tls code because:
- it is based on an external project and every change here diverges us
further from the original code
- it is Ole's child

So I proposed you use 0x7fffffff as indicator in your certificate. Or do you
have external certificates where you dont have controll over them that use
-1?  Then of course the additional check for -1, or a cast of both items to
unsigned is needed.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------