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 > >
- RE: OOPS -- Correction. RE: pkix part 1, draft 4:… Hoffman, Mort
- Re: OOPS -- Correction. RE: pkix part 1, draft 4:… Housley, Russ