Now that the specific issue of RIs containing V2 ACs is settled by
John's proposal withdrawal, there is an opportunity to make a more
general statement in support of Peter's third option below.
The version number contained within an Attribute Certificate is
sufficient in principle for a decoder of an outer object (EnvelopedData)
to determine whether the inner (AC) version is supported, and if
not, ignore the AC, throw an appropriate diagnostic gracefully,
and continue parsing at the end of the unknown inner object. I don't
buy the argument that some tools don't do the right thing and that a
data standard should therefore do the wrong thing (increment
EnvelopedData). And I don't understand the argument that versioning
is related to one-pass-ness; a one-pass structure decoder should be
able to skip unknown inner objects just as easily as a tree builder
or something using Russ' try-this-then-try-that scheme.
Incrementing EnvelopedData is wrong because of the collateral damage
-- it forces correct implementations to reject messages that they could
otherwise have processed by ignoring an unknown AC. And it is wrong
because it sends the message "those ASN.1 people are sooooo stupid
-- let's just rewrite CMS in XML and avoid problems with tools not
being able to handle version numbers".
Can we adopt a general principle that when evolving the standard,
the first priority should be to minimize damage to capable
implementations? If a conflict arises with specific toolkit
limitations, the answer should be "improve the toolkit".
Dave
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.