Subject: [AAA-WG]: [issue] Several CMS-Encrypted-Data AVPs in a message

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 22 Aug 2001 19:03:42 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-08-22
Reference: 
Document: CMS-02
Comment type: E
Priority: 1
Section: 
Rationale/Explanation of issue: 

In 6.2 it's stated that:

   CMS-Encrypted-Data MAY contain more than one CMS object, that is,
   implementations MUST be able to add a new CMS-Encrypted-Data AVP
   value and also MUST be able to decrypt all CMS-Encrypted-Data AVP
   values which are encrypted for them.

This text isn't clear for me:

- The first sentence ("CMS-Encrypted-Data MAY contain more than one
CMS object") might suggest that it is possible to encrypt several AVPs
into a CMS-Encrypted-Data AVP (even if those AVPs are also
CMS-Encrypted-Data AVPs). That is, it might refer to nested
enveloping.

- However, the next sentence, which is a consequence of the previous
("implementations MUST be able to add a new CMS-Encrypted-Data AVP
value") isn't straightforward since it doesn't specify to what it can
be added (to the message or maybe to an AVP?). I mean, it might
suggest that an implementation MUST be able to add a new
CMS-Encrypted-Data AVP to a message.

- The last sentence ("also MUST be able to decrypt all
CMS-Encrypted-Data AVP values which are encrypted for them")
contradict my previous interpretation. If there're nested encryption,
just the "last" envelope could be opened, so that a nested envelope
couldn't be opened by the receiver unless he opened the external
envelopes. On the other hand, with different CMS-Encrypted-Data AVPs
inside the same message and with different recipients, any AVP would
be opened by the its intended recipient.

Another possibility is that the paragraph is trying to say that new
RecipientInfo values may be inserted. But that fact can't be true
since it would be necessary for an entity trying to do that to be a
recipient to be able to decrypt the CEK and reencrypt it with a new
key.

Requested change: 

Replace the quoted paragraph (and maybe the next one) with a more
clear text.

Regards

  // M.A.

-- 
  Miguel Angel Monjas Llorente
  Systems Engineer, GSM/UMTS Systems Management
  Ericsson España, S.A. (EEM) UMTS/GSM Databases
  Tel: +34 91 3393605                 Mob: +34 629 570196
  <mailto:[email-masked]>  Fax: +34 91 3392538
  Retama 1, 4th. 28045 Madrid - SPAIN -