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

[Krzysztof Sawicki]

On 25.04.2017 11:20, Uwe Bonnes wrote:
>>>>>> "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.

RFC mentions 99991231235959Z as no well-defined expiration date and so 
does my certificate. My opinion is that NutOS should accept certificates 
that meets standards. This value is processed by asn1_get_utc_time 
(tls/asn1.c) which casts it to time_t as -1. That is a problem.

-- 
Krzysztof Sawicki
MLabs sp. z o.o.
ul. Kaliska 21
61-131 Poznań

tel. 61 646 84 27

KRS: 0000390306
NIP: 7822533401