RE: pkix part 1, draft 4: UTCTime vs GeneralizedTime dates anomaly

"Hoffman, Mort" <Mort.Hoffman@gsc.gte.com> Wed, 02 April 1997 21:54 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA23262; Wed, 2 Apr 1997 13:54:04 -0800
Received: from Sonnet.GSC.GTE.Com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id NAA23257; Wed, 2 Apr 1997 13:54:02 -0800
Received: from ndhm06.ndhm.gtegsc.com ("port 2448"@ndhm06.ndhm.gtegsc.com) by Sonnet.GSC.GTE.Com (PMDF V5.0-6 #17886) id <01IH8JPBSVGA000Y0L@Sonnet.GSC.GTE.Com> for ietf-pkix@tandem.com; Wed, 02 Apr 1997 16:53:52 -0400 (EDT)
Received: by ndhm06.ndhm.gtegsc.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC3F86.AF27CD00@ndhm06.ndhm.gtegsc.com>; Wed, 02 Apr 1997 16:55:35 -0500
Date: Wed, 02 Apr 1997 16:55:34 -0500
From: "Hoffman, Mort" <Mort.Hoffman@gsc.gte.com>
Subject: RE: pkix part 1, draft 4: UTCTime vs GeneralizedTime dates anomaly
To: "'ietf-pkix@tandem.com'" <ietf-pkix@tandem.com>, 'Tim Polk' <polk@csmes.ncsl.nist.gov>
Message-id: <c=US%a=_%p=GTE%l=NDHM06-970402215534Z-37380@ndhm06.ndhm.gtegsc.com>
MIME-version: 1.0
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit

Tim,

Reading throught the spec I ran into the following anomaly:  section
4.1.2.5 specifies that dates in the year 2050 should be generated as
UTCTime, and section 4.1.2.5.1 specifies that UTCTime dates encoded with
the year set to 50 shall be interpreted as 2050.  Now, since there were
no CAs existing in the year 1950, then there should not exist any such
dates in certificates at all (OK, this could be argued with on strictly
technical grounds, but I think it is basically true).  Therefore the
anomaly in the spec should not really affect anything, but if someone
writing code to generate certificates read section 4.1.2.5.1 instead of
4.1.2.5, then he would be lead astray.

I imagine all this traces back to the discussion in the X.509 arena on
the dates, but I deleted that mail and I don't know if the anomaly
existed there.  If it didn't then the fix would be to fully align to
what was agreed in X.509.  Otherwise, I guess I'd recommend that a
UTCTime encoded with 50 should be rejected, since it could not have been
legally generated.

Mort