[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-tech
Subject:    Re: openssl.1 diff
From:       Ingo Schwarze <schwarze () usta ! de>
Date:       2018-02-28 22:43:22
Message-ID: 20180228224322.GB49600 () athene ! usta ! de
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]