[En-Nut-Discussion] [PATCH 1/2] FIX: accept certificate without expiration date
krzysztof.sawicki at mlabs.pl
Tue Apr 25 14:07:52 CEST 2017
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 126.96.36.199
> 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.
MLabs sp. z o.o.
ul. Kaliska 21
tel. 61 646 84 27
More information about the En-Nut-Discussion