Blake,
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.
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.
IMHO, this issue is different than with the v3 X.509 certs. In that case,
they were constrained by the basic Certificate syntax. In this case, we
have much more flexibility because we are dealing with a set of attributes
(i.e. OID and ANY).
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).
- John Pawling
At 03:03 PM 11/12/97 -0800, Blake Ramsdell wrote:
On Wednesday, November 12, 1997 2:35 PM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
It seems to me that it would be much simpler to have two separate
attributes: one for UTCTime and the other for GeneralizedTime. This
strategy allows the receiving application to quickly identify the flavor of
the signing time based on the OID identifying the attribute. IMHO, the
ChoiceOfTime just adds complexity because the receiving agent has to figure
out which choice was chosen.
The concern for me (as usual) is backwards compatibility. There is no
implementation complexity to using ChoiceOfTime with a sliding window,
since this gives implementors a grace period before implementing
GeneralizedTime -- use UTCTime through the year 2049 and use
GeneralizedTime for 2050 or after. This seems like it is the best
balance between compatibility and complexity.
If we have a separate OID identifying the GeneralizedTime attribute,
then the current implementations won't see it and won't be able to use
it. If we use the sliding window, nothing changes in applications until
around 2040.
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