Re: More on KEKIdentifiers, and a suggested addition to CMS

[[e-mail] (Peter Gutmann)]

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