On Wednesday, November 12, 1997 3:23 PM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
Constructing the ChoiceOfTime is the easy part. My point is that it adds
complexity to the SignedData decoding software that must determine which
choice was chosen. For example, in 2051, our code will need to be able to
decode stored SignedData objects some of which include SigningTime with
UTCTime choice and others that include SigningTime with GeneralizedTime
choice. Sure, there are ways of determining which choice was chosen, but
the OID check for the signingTime or NewSigningTime attributes would be
quicker and easier.
I understand. Point taken.
In the signingTime or NewSigningTime attributes environment, you could use
an equivalent strategy to ensure backwards compatibility by including the
signingTime (UTCTime) attribute in SignedData objects generated thru the
year 2049 and including newSigningTime (GeneralizedTime) in SignedData
objects generated on 2050 or after. Using this strategy, in 2051, the
software can easily determine which flavor of signing time was included in a
SignedData object simply by examining the attribute OID.
Yup -- I agree with this. This does sound better.
I'm apologize if I'm being a pain, but I'm just trying to ward off more
complexity in an already complex protocol (and getting more complex each
day).
I don't think you're being a pain (hey, I should be apologizing, not
you). It's better to be picky and get it right than it is to have
unwritten "steeped in oral tradition" rules.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060