Subject: [AAA-WG]: CMS-Encrypted-Data AVP

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 16 Aug 2001 15:44:17 +0200

Hi all,

I've got a pair of questions regarding CMS-Encrypted-Data AVP in point
6.2 in CMS Security Application.

The first one refers to the next paragraph:

   Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the
   eContentType of the EncapsulatedContentInfo MUST be id-data [11].

EncapsulatedContentInfo is the type of the value encapContentInfo
inside the CMS SignedData type, not EncapsulatedData. No value of such
type belongs to EncapsulatedData definition, so that I suspect this
paragraph refers really to CMS-Signed-Data and should be moved to &.1
point.

The sense of the next paragraph isn't quite clear for me:

   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.

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 refers to nested enveloping.

However, the following sentence which is a consequence of the previous
("implementations MUST be able to add a new CMS-Encrypted-Data AVP
value") isn't straightforward. I mean, it might suggest that a
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 interpretations. If there're nested encryption,
just the "last" enveloped might be opened, so that a nested envelope
couldn't be opened by the receiver unless he didn't open 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 intended recipient.

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

Of course I'm little bit confused. Has anyone any clue?

Regards

  // M.A.