Re: OOPS -- Correction. RE: pkix part 1, draft 4: UTCTim

"Housley, Russ" <housley@spyrus.com> Mon, 07 April 1997 03:51 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id UAA15330; Sun, 6 Apr 1997 20:51:49 -0700
Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id UAA15323; Sun, 6 Apr 1997 20:51:47 -0700
Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id UAA04316; Sun, 6 Apr 1997 20:45:44 -0700
Received: from cc:Mail by spysouth.spyrus.com id AA860380972 Sun, 06 Apr 97 19:42:52
Date: Sun, 06 Apr 1997 19:42:52 -0000
From: "Housley, Russ" <housley@spyrus.com>
Encoding: 1401 Text
Message-Id: <9703068603.AA860380972@spysouth.spyrus.com>
To: ietf-pkix@tandem.com, Mort.Hoffman@gsc.gte.com, wpolk@nist.gov
Subject: Re: OOPS -- Correction. RE: pkix part 1, draft 4: UTCTim

Mort:

I think the text says that dates before 2050 should be encoded at UTCTime, and 
that dates after 2049 should be encodes as GeneralizedTime.  Thus, a UTCTime 
of 500101000000Z should be interpreted as midnight on January 1, 1950.

Agree?

Russ

>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 >GeneralizedTime 
(not 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 
>
>