Re: openssl.1 diff
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 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
Re: openssl.1 diff
On Wed, Feb 28, 2018 at 08:43:34PM +0100, Holger Mikolon wrote: > > > > Index: openssl.1 > > > > === > > > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v > > > > retrieving revision 1.87 > > > > diff -u -r1.87 openssl.1 > > > > --- openssl.1 18 Feb 2018 07:43:55 - 1.87 > > > > +++ openssl.1 27 Feb 2018 21:38:06 - > > > > @@ -360,8 +360,8 @@ > > > > The number of days to certify the certificate for. > > > > .It Fl enddate Ar date > > > > Set the expiry date. > > > > -The format of the date is YYMMDDHHMMSSZ > > > > -.Pq the same as an ASN.1 UTCTime structure . > > > > +The format of the date is [YY]YYMMDDHHMMSSZ, > > > > +with all four year digits required for dates after 2050. > > > > > > "dates after 2050" reads like "2051 and later" to me, which would be > > > wrong. > > > It should rather be "dates after 31 Dec 2049". In other words: > > > You must specify 2049 as 49 and 2050 as 2050. > > > > > > > so dates *from* 2050, rather than after? > > > > but..."you *must* specify 2049 as 49": "2049" is valid, right? > > > > jmc > > I did some experiments today; you're right, "2049" works just like "49". > Sorry for the wrong claim - it's been obviously too late yesterday :- ) > > Specifying "2050", however, is not equal to "50" (==1950). > So the wording "from 2050" or "after 2049" would both work. With that > exception your above diff reads correct to me. And I checked that > -startdate and -enddate behave equally. > great. thanks for verifying that. > 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 > or YY format was provided on command line. I checked it by parsing a > certifciate with "openssl asn1parse". As already said, I don't see a value > in documenting that structure. Others might. > i am zapping the asn.1 refs, as i see no benefit in keeping it and it will keep the text from getting bigger. jmc > Holger >
Re: openssl.1 diff
> > > Index: openssl.1 > > > === > > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v > > > retrieving revision 1.87 > > > diff -u -r1.87 openssl.1 > > > --- openssl.1 18 Feb 2018 07:43:55 - 1.87 > > > +++ openssl.1 27 Feb 2018 21:38:06 - > > > @@ -360,8 +360,8 @@ > > > The number of days to certify the certificate for. > > > .It Fl enddate Ar date > > > Set the expiry date. > > > -The format of the date is YYMMDDHHMMSSZ > > > -.Pq the same as an ASN.1 UTCTime structure . > > > +The format of the date is [YY]YYMMDDHHMMSSZ, > > > +with all four year digits required for dates after 2050. > > > > "dates after 2050" reads like "2051 and later" to me, which would be wrong. > > It should rather be "dates after 31 Dec 2049". In other words: > > You must specify 2049 as 49 and 2050 as 2050. > > > > so dates *from* 2050, rather than after? > > but..."you *must* specify 2049 as 49": "2049" is valid, right? > > jmc I did some experiments today; you're right, "2049" works just like "49". Sorry for the wrong claim - it's been obviously too late yesterday :- ) Specifying "2050", however, is not equal to "50" (==1950). So the wording "from 2050" or "after 2049" would both work. With that exception your above diff reads correct to me. And I checked that -startdate and -enddate behave equally. 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 or YY format was provided on command line. I checked it by parsing a certifciate with "openssl asn1parse". As already said, I don't see a value in documenting that structure. Others might. Holger
Re: openssl.1 diff
On Tue, Feb 27, 2018 at 11:04:10PM +0100, Holger Mikolon wrote: > > hi. > > > > 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. > > 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. > good, it can probably go then. > > > > there is also "startdate" for openssl ca. we should probably do the same > > for that, assuming it applies. > > I have not checked startdate yet due to lack of time - and I did not > want to blindly assume whether it applies. I could spend some effort > on this next days. > > One remark to your diff below. > > Regards > Holger > > > > > so sth like the diff below. > > jmc > > > > Index: openssl.1 > > === > > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v > > retrieving revision 1.87 > > diff -u -r1.87 openssl.1 > > --- openssl.1 18 Feb 2018 07:43:55 - 1.87 > > +++ openssl.1 27 Feb 2018 21:38:06 - > > @@ -360,8 +360,8 @@ > > The number of days to certify the certificate for. > > .It Fl enddate Ar date > > Set the expiry date. > > -The format of the date is YYMMDDHHMMSSZ > > -.Pq the same as an ASN.1 UTCTime structure . > > +The format of the date is [YY]YYMMDDHHMMSSZ, > > +with all four year digits required for dates after 2050. > > "dates after 2050" reads like "2051 and later" to me, which would be wrong. > It should rather be "dates after 31 Dec 2049". In other words: > You must specify 2049 as 49 and 2050 as 2050. > so dates *from* 2050, rather than after? but..."you *must* specify 2049 as 49": "2049" is valid, right? jmc > > .It Fl extensions Ar section > > The section of the configuration file containing certificate extensions > > to be added when a certificate is issued (defaults to > > @@ -492,8 +492,8 @@ > > A single self-signed certificate to be signed by the CA. > > .It Fl startdate Ar date > > Set the start date. > > -The format of the date is YYMMDDHHMMSSZ > > -.Pq the same as an ASN.1 UTCTime structure . > > +The format of the date is [YY]YYMMDDHHMMSSZ, > > +with all four year digits required for dates after 2050. > > .It Fl status Ar serial > > Show the status of the certificate with serial number > > .Ar serial . > > > > >
Re: openssl.1 diff
> hi. > > 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. 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. > > there is also "startdate" for openssl ca. we should probably do the same > for that, assuming it applies. I have not checked startdate yet due to lack of time - and I did not want to blindly assume whether it applies. I could spend some effort on this next days. One remark to your diff below. Regards Holger > > so sth like the diff below. > jmc > > Index: openssl.1 > === > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v > retrieving revision 1.87 > diff -u -r1.87 openssl.1 > --- openssl.1 18 Feb 2018 07:43:55 - 1.87 > +++ openssl.1 27 Feb 2018 21:38:06 - > @@ -360,8 +360,8 @@ > The number of days to certify the certificate for. > .It Fl enddate Ar date > Set the expiry date. > -The format of the date is YYMMDDHHMMSSZ > -.Pq the same as an ASN.1 UTCTime structure . > +The format of the date is [YY]YYMMDDHHMMSSZ, > +with all four year digits required for dates after 2050. "dates after 2050" reads like "2051 and later" to me, which would be wrong. It should rather be "dates after 31 Dec 2049". In other words: You must specify 2049 as 49 and 2050 as 2050. > .It Fl extensions Ar section > The section of the configuration file containing certificate extensions > to be added when a certificate is issued (defaults to > @@ -492,8 +492,8 @@ > A single self-signed certificate to be signed by the CA. > .It Fl startdate Ar date > Set the start date. > -The format of the date is YYMMDDHHMMSSZ > -.Pq the same as an ASN.1 UTCTime structure . > +The format of the date is [YY]YYMMDDHHMMSSZ, > +with all four year digits required for dates after 2050. > .It Fl status Ar serial > Show the status of the certificate with serial number > .Ar serial . > >
Re: openssl.1 diff
On Tue, Feb 27, 2018 at 08:54:48PM +0100, Holger Mikolon wrote: > When playing with "openssl ca" with various validity end dates I could > not manage end dates of 2050 or later - until I started reading code and > the RFC 5280. As far as I understand it now (and is confirmed by various > tests), the openssl parameter "-enddate" expects one of two date/time > formats - depending on whether the date is before 2050 or not. This is far > from obvious, hence I'd like to propose below change to the man page. > > Regards > Holger > > > --- ./usr.bin/openssl/openssl.1 > +++ ./usr.bin/openssl/openssl.1 > @@ -361,7 +361,11 @@ The number of days to certify the certif > .It Fl enddate Ar date > Set the expiry date. > The format of the date is YYMMDDHHMMSSZ > -.Pq the same as an ASN.1 UTCTime structure . > +.Pq the same as an ASN.1 UTCTime structure > +for dates before 2050. > +The format of the date is MMDDHHMMSSZ > +.Pq the same as an ASN.1 GeneralizedTime structure > +for 2050 and later (see RFC 5280). > .It Fl extensions Ar section > The section of the configuration file containing certificate extensions > to be added when a certificate is issued (defaults to > hi. 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. there is also "startdate" for openssl ca. we should probably do the same for that, assuming it applies. so sth like the diff below. jmc Index: openssl.1 === RCS file: /cvs/src/usr.bin/openssl/openssl.1,v retrieving revision 1.87 diff -u -r1.87 openssl.1 --- openssl.1 18 Feb 2018 07:43:55 - 1.87 +++ openssl.1 27 Feb 2018 21:38:06 - @@ -360,8 +360,8 @@ The number of days to certify the certificate for. .It Fl enddate Ar date Set the expiry date. -The format of the date is YYMMDDHHMMSSZ -.Pq the same as an ASN.1 UTCTime structure . +The format of the date is [YY]YYMMDDHHMMSSZ, +with all four year digits required for dates after 2050. .It Fl extensions Ar section The section of the configuration file containing certificate extensions to be added when a certificate is issued (defaults to @@ -492,8 +492,8 @@ A single self-signed certificate to be signed by the CA. .It Fl startdate Ar date Set the start date. -The format of the date is YYMMDDHHMMSSZ -.Pq the same as an ASN.1 UTCTime structure . +The format of the date is [YY]YYMMDDHHMMSSZ, +with all four year digits required for dates after 2050. .It Fl status Ar serial Show the status of the certificate with serial number .Ar serial .
openssl.1 diff
When playing with "openssl ca" with various validity end dates I could not manage end dates of 2050 or later - until I started reading code and the RFC 5280. As far as I understand it now (and is confirmed by various tests), the openssl parameter "-enddate" expects one of two date/time formats - depending on whether the date is before 2050 or not. This is far from obvious, hence I'd like to propose below change to the man page. Regards Holger --- ./usr.bin/openssl/openssl.1 +++ ./usr.bin/openssl/openssl.1 @@ -361,7 +361,11 @@ The number of days to certify the certif .It Fl enddate Ar date Set the expiry date. The format of the date is YYMMDDHHMMSSZ -.Pq the same as an ASN.1 UTCTime structure . +.Pq the same as an ASN.1 UTCTime structure +for dates before 2050. +The format of the date is MMDDHHMMSSZ +.Pq the same as an ASN.1 GeneralizedTime structure +for 2050 and later (see RFC 5280). .It Fl extensions Ar section The section of the configuration file containing certificate extensions to be added when a certificate is issued (defaults to
