Subject: Re: CMS: Algorithm Dependancy Issues

From: "Rich Ankney" <[email-masked]>
Date: Fri, 6 Nov 1998 20:21:57 -0500

I would agree with this change in terminology (as would most
of X9, who like this because it provides X9.17-like (ugh) functionality).

/ Rich

----------
> From: Peter Gutmann <[email-masked]>
> To: [email-masked]
> 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
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.