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

["Hoffman, Mort" <[e-mail]>]

Russ,

Not quite.  I agree with you on what the encoding rules say.  However,
in 4.1.2.5.1, for purposes of decoding UTCTime it says

"Where YY is greater than 50, the year shall be itnerpreted as 19YY; and
Where YY is less than or equal to 50, the year shall be interpreted as
20YY."

Thus a UTCTime of 500101000000Z would be interpreted as midnight January
1, 2050, even though January 1, 2050 would be encoded in
GeneralizedTime!

Mort

>----------
>From: 	Housley, Russ[SMTP:[e-mail]]
>Sent: 	Sunday, April 06, 1997 3:42 PM
>To: 	[e-mail]; [e-mail]; [e-mail]
>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 
>>
>>
>