I disagree with adding "..." to the RecipientInfo CHOICE because I believe
that leads to non-interoperable S/MIME implementations.
Personally I think a new version number is advisable every time the choice is
extended, as that would make the handing of any extended choice easier to
handle on reception. But I am happy to follow the general consensus on that
issue.
<grumble>
Why are people trying to manufacture all this unnecessary complexity for
something so simple? X.500 has had this capability (the Name CHOICE) for over
10 years and it's never lead to any problems because the only way to extend it
is via changes to X.500 (that is, you need to extend the standard to extend
the CHOICE). Similarly, someone can't just drop in a new CHOICE option for
CMS, it'd have to be done via the usual CMS standards process, so that
resulting implementations would be just as interoperable as, say, ESS
implementations.
Similarly, I don't see why it's necessary to change the version number every
time the CHOICE is extended - if you don't recognise a CHOICE alternative, you
skip it and continue. Since CMS already requires changes from S/MIME v2/PKCS
#7 (by adding the CHOICE) adding an extra line or two of code to
implementations to skip unrecognised choices can't be that hard.
</grumble>
This is why I asked for '...' (or text to that effect for those still stuck
with ASN.1:1988) be added to CMS, it means it'll be possible to extend the
CHOICE in the future with further RFC's without requiring an update to CMS
itself (I believe this was the same rationale behind X.500's Name CHOICE).
There won't be an uncontrolled explosion of choices since the only way to
extend it would be as a full RFC, which would have to go through the usual
carefully-controlled standards process.
Peter.