[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Time Encoding



I would personally prefer stronger language about the rule, for the same reason that X.509 has DER-like rules.  I think it's nice to be able to encode a certificate from some internal format without having to keep track of what the original format was.

(Just bringing up a point people frequently seem to forget; DER is there for a reason.)

- Mark Bartel

----------
From: 	Michael Myers-P23970[SMTP:Michael_Myers-P23970@email.mot.com]
Sent: 	Wednesday, December 11, 1996 11:34 AM
To: 	housley@spyrus.com; ietf-pkix@tandem.com
Subject: 	RE: Time Encoding

Russ--

I agree.  This would better align PKIX with other activities.

Text regarding applicability of the rule to cert generation vs. cert 
processing would be useful guidance.  I would expect the rule to strictly 
apply to PKIX-conformant CAs, while apps must minimally comply in the sense 
that they may choose a more tolerant implementation.

 --Mike

 ----------
>From: housley@spyrus.com2
>To: ietf-pkix@tandem.com
>Subject: Time Encoding
>Date: Tuesday, December 10, 1996 11:50PM
>
>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
>