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

[[e-mail] (John Pawling)]

Peter,

I still oppose the addition of "..." to the CMS RecipientInfo syntax.  IMHO,
"..." does not add any value to the document.  Implementors realize that the
S/MIME v3 documents are subject to enhancements.  If people need to add a
CHOICE to the CMS RecipientInfo syntax, then they need to propose a specific
syntax and accompanying text for inclusion in CMS.  


You stated: "- if you don't recognise a CHOICE alternative, you skip it and
continue." 

If you were talking about v3 cert extensions or signedAttributes, I would
agree with your "skip it and continue" strategy for unrecognized syntaxes.
In the case of a CHOICE syntax, I disagree that it is straightforward to
"skip" an unrecognized CHOICE alternative.  Most S/MIME implementations use
an ASN.1 decoding strategy by which the entire object (i.e. envelopedData,
signedData, etc) is decoded via a single call to an ASN.1 library that
implements general purpose ASN.1 decoding rules.  In this case, there is no
easy way to "skip" an unrecognized CHOICE syntax.  That is an error
condition.  For example, if a RecipientInfo includes a CHOICE alternative
not defined in the CMS standard, then the decoding software returns an error
when attempting to decode the object.  I believe that you will find that the
vast majority of S/MIME implementations work in this fashion.  For example,
the S/MIME Freeware Library calls the freeware SNACC ASN.1 library to decode
objects.  The SNACC ASN.1 library is capable of using general purpose ASN.1
rules to decode the ASN.1 syntaxes included in the ASN.1 modules provided at
compile time (ex: CMS ASN.1 module).  If the SNACC library encounters an
unrecognized CHOICE alternative, it returns an error.  There is no easy way
to add code to handle a special case like "skip an unrecognized CHOICE
alternative in recipientInfo".  


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

I don't like the idea of splitting a CHOICE syntax definition between
multiple documents.  IMHO, that is OK for defining attributes and
extensions, but not CHOICEs.    

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================