"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.