Time Encoding

[Rodney Thayer <rodney@xxxxxxxxxxxxx>]

I thought it sounded strange when he presented it, because the message I
got was "UTCTime is bad and you should not be doing it but you must use it
until 2005".  If it's bad, kill it.  If it's not bad and we want a graceful
transition, then let's say that (Note I think Russ' approach does this).


>Date: Tue, 10 Dec 96 21:57:42 
>From: "Housley, Russ" <housley@spyrus.com>
>Encoding: 1218 Text
>To: ietf-pkix@tandem.com
>Subject: Time Encoding
>
>
>PKIX Participants:
>
>Tim Polk presented the changes to PKIX Part 1 at the IETF meeting in 
>San Jose.  This presentation included the change from UTCTime to 
>CHOICE { UTCTime, GeneralizedTime }.  The current draft of Part 1
>includes a "sliding window" approach to determining which of the two
>encoding alternatives will be used.  This approach is documented in 
>draft-ietf-pkix-part1-03.txt that was mailed to the list by Tim.
>
>I disagree with the approach presented in the document.  In my opinion,
>any particular date value should only have one encoding.  To this end, 
>I suggest that we replace the "sliding window" approach with the 
>following rules:
>
>          IF the value of the year to be encoded is less than 2050,
>          THEN use the UTCTime encoding.
>          
>          IF the value of the year to be encoded is greater than or 
>             equal to 2050,
>          THEN use the GeneralizedTime encoding.
>
>By adopting these rules, there is only one encoding possible for any
>date.  Of course, a certificate user could be forgiving about the format
>received in a certificate.  But, I think that we should mandate the above 
>rules for CAs conforming to PKIX.
>
>Comments?
>
>Russ
>
>

               Rodney Thayer <rodney@sabletech.com>       +1 617 332 7292
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: +1 617 332 7970           http://www.shore.net/~sable
                           "Developers of communications software"