Hi, Holger Mikolon wrote on Tue, Feb 27, 2018 at 11:04:10PM +0100: > jmc@ wrote:
>> i wonder whether we could more simply just use the date format [YY]YY, >> explain the 2050 cutoff, and forget about mentioning asn.1 time >> structures. >> >> or do you think there is a practical reason why the user would need to >> know it? i suspect not. Don't forget that the openssl(1) utility is intended as a test tool for developers, in particular when they want to test whether functions documented in section 3 work correctly, and that it is *not* intended as a production tool for end users, so in general, the same level of technicality as in section 3 manual pages is adequate. > Actually the mentioning of the asn.1 time structure helped me to identify > the RFC 5280 and finally helped solve my parameter usage. If the man page > was fixed, I couldn't anymore think of a practical reason to mention the > structure. In the case at hand, removing the reference to UTCTime was apparently not only correct, but required. I didn't test myself nor inspect the code, but from the test results you report, it appears that both GeneralizedTime and UTCTime format are accepted. So what Jason committed is fine. > However (and I don't know if that's relevant to someone) the ASN.1 > structure used for dates before 2050 is always "UTCTime", no matter > if the YYYY or YY format was provided on command line. That is required by RFC 5280, paragraph 4.1.2.5. "Validity": [...] CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime. [...] The joys of X.509. Yours, Ingo