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 "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.


Reply via email to