While people are commenting on the use of CMS as a general protocol bucket,
there's something which has bothered me for awhile: The use of the term
MailListRecipientInfo to describe the use of shared symmetric keys. While I
appreciate that there are historical reasons for the ML naming, is it too late
to change it to something more appropriate like SymmetricKeyRecipientInfo?
Its use doesn't have much to do with mailing lists, and since CMS is supposed
to be an application-independent format it would be more accurate to describe
it by what it actually does rather than one particular possible application of
the technique when used with S/MIME.
An example of where this causes confusion is with authData (MAC'd data): If
you exclude MailListRecipientInfo, the key management is based entirely on
public-key technology, because the other two recipientInfos all use public-key
mechanisms (KeyTrans has "must contain a key transport public key", KeyAgree
has "must contain a key agreement public key"). However the most common use
for a MAC - using a shared key/password for integrity protection - requires
the use of the rather badly misnamed MailListRecipientInfo, which is the only
way to specify a shared key. It isn't at all obvious from flicking through
the RecipientInfo's that you're supposed to manage a shared key by pretending
you're on a mailing list.
If the name change to the more accurate description isn't possible, would it
at least be possible to add comments where necessary in the text to point out
that the ML stuff should be used for shared keys? This would require for
example changing the authData text in section 9 to:
3. For each recipient, the ... defined in Section 6.2. The most common use
for a MAC is with a key shared by both the sender and recipient, which
would entail the use of the MailListRecipientInfo type.
Peter.