I would agree with this change in terminology (as would most
of X9, who like this because it provides X9.17-like (ugh) functionality).
From: Peter Gutmann <pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz>
Subject: Re: CMS: Algorithm Dependancy Issues
Date: Saturday, November 07, 1998 4:38 AM
While people are commenting on the use of CMS as a general protocol
there's something which has bothered me for awhile: The use of the term
MailListRecipientInfo to describe the use of shared symmetric keys.
appreciate that there are historical reasons for the ML naming, is it too
to change it to something more appropriate like
Its use doesn't have much to do with mailing lists, and since CMS is
to be an application-independent format it would be more accurate to
it by what it actually does rather than one particular possible
the technique when used with S/MIME.
An example of where this causes confusion is with authData (MAC'd data):
you exclude MailListRecipientInfo, the key management is based entirely
public-key technology, because the other two recipientInfos all use
mechanisms (KeyTrans has "must contain a key transport public key",
has "must contain a key agreement public key"). However the most common
for a MAC - using a shared key/password for integrity protection -
the use of the rather badly misnamed MailListRecipientInfo, which is the
way to specify a shared key. It isn't at all obvious from flicking
the RecipientInfo's that you're supposed to manage a shared key by
you're on a mailing list.
If the name change to the more accurate description isn't possible, would
at least be possible to add comments where necessary in the text to point
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
for a MAC is with a key shared by both the sender and recipient,
would entail the use of the MailListRecipientInfo type.