[openssl-users] Doubt regarding O-SSL and setting the duration of certificates
Erwann.Abalea at docusign.com
Wed Sep 13 17:17:21 UTC 2017
> Le 13 sept. 2017 à 17:08, Michael Wojcik <Michael.Wojcik at microfocus.com> a écrit :
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Michael Richardson
>> Sent: Wednesday, September 13, 2017 09:32
>> I suspect that the value: literal value 99991231235959Z will simply come to
>> mean "the end of time", even after the year 10,000. It has a well known
>> DER encoding, and one can memcmp() it.
> Personally, I'm really hoping we're not still using ASN.1 in the year 10000.
Why not? ;)
X.680 relies in ISO8601 for the date/time definitions. GeneralizedTime uses the Basic format from ISO8601 for the date (year on 4 digits, month on 2 starting with 01, day on 2 starting with 01), liberal time of day (minutes and/or seconds can be omitted, optional fraction of second/minute/hour depending on what is included), and a timezone from -15h to +15h with a one hour or one minute accuracy, or Z for UTC.
BER accepts pretty much everything from this definition, DER has a few restrictions:
- in ISO8601, there are 2 different midnights (00:00:00 and 24:00:00), the DER encoding requires such date/time to be transformed into 00:00:00 the day after
- DER only accepts the « Z » timezone and not the +/-HH(MM) variant
- DER requires the minutes and seconds to be present in the time of day, and no fraction of a second
In theory, the very last date/time expressed in ASN.1 is 99991231240000+1500, and it would be valid if expressed in BER. In DER, the very last date/time would have been 99991231235960Z (in case a positive leap second gets inserted that day), but something else was preferred. It’s still possible that there’s a negative leap second happening at that exact day, removing second 59 completely.
Just think of this as a magical value.
More information about the openssl-users