I would like to generalize this debate. Since we are in the process of
updating RFC 2630 to change the mandatory-to-implement algorithms, perhaps
we should add some guidance. When does the version number need to be
incremented? Guidance on versioned structures that contain versioned
structures is also a good idea.
Russ
At 10:07 AM 4/20/2001 +0000, Peter Gutmann wrote:
"Pawling, John" <John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com> writes:
>I doubt if many implementations check the EnvelopedData version value before
>attempting to decode the hex data. A new version number would have assisted
>with debugging and error reporting, but it is probably not worth the
effort to
>change the specs and implementations to populate the new version value.
My code does (OK, it's not just pedantic, it's truly anal-retentive :-),
whether this was a good idea or not would have depended on how EnvelopedData
versions are interpreted. If the EnvelopedData version was incremented
whenever a new RecipientInfo was added then it's bad, because adding a single
vers.n+1 RI to a bunch of vers.n RIs will change the EnvelopedData version
even
though there are vers.n RIs there which could be processed (that is, the code
could still process the EnvelopedData except that the presence of the vers.n+1
value for the EnvelopedData would stop it). OTOH if the EnvelopedData version
is only incremented when the overall structure of the EnvelopedData is changed
then it's fine, because it won't try and decode something in a completely
different format. There are actually quite a variety of possibilities:
- Change it to n+1 if any n+1 RIs are present (yuck)
- Change it to n+1 only if there are no vers.n RIs present (arguable, but
I don't really like it)
- Leave it as is and use the RI version numbers to figure out whether you can
use a particular RI (ie only change it if the EnvelopedData itself changes
but not the RI within it)
The third one seems to be the most sensible.
Peter.