Re: [PATCH 1/2] FIX: accept certificate without expiration date
Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> Tue, 25 Apr 2017 11:20:48 +0200
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "Krzysztof" == Krzysztof Sawicki <[email protected]> writes: Krzysztof> On 24.04.2017 16:34, Uwe Bonnes wrote: >>>>>>> "Krzysztof" == Krzysztof Sawicki <[email protected]> >>>>>>> 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-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion