Subject: [AAA-WG]: [issue] Digital encryption + signature in CMS-Sec

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 06 Sep 2001 10:43:54 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-09-06
Reference: 
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.1, 6.2
Rationale/Explanation of issue:

When a set of AVPs is required also as encrypted and digitally signed,
the draft states (according to S/MIME RFC) that the encryption must be
done first. That's is coherent but can, in some occasions, be confused
for an implementation.

I'll try to explain it. Let's imagine that the Expected-Encrypted-AVP
states that AVPs A and B must be encrypted. So does the
Expected-Signed-AVP (including maybe another AVP, C). The
implementation will first create a CMS-Encrypted-AVP containing A and
B, that are subsequently dropped. When the signing process begin,
there's no A and B AVPs, so that it might sign only C. In order to
avoid this misbehaviour, I suggest stating explicitly that when
encryption and digital signature are required, it has to be treated as
an atomic operation, so that the implementation must "remember" that A
and B AVPs are also inside an encrypted AVP.

Requested change: 

Add some paragraphs after (6.1):

   When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
   AVP MUST be created first. The resulting CMS object MUST then be
MIME
   encoded producing an application/pkcs7-mime MIME type which is then
   used as the content of the EnvelopedData. This means that signing
is
   "outside" encryption.

It might be something like the following:

   Implementations MUST treat this process as an atomic process, so
that
   one encrypted the set of AVPs required as so, the implementation
MUST
   use the CMS-Encrypted-Data AVP (as well as any additional AVP
required
   as only signed) as the input to the signing process (even if the 
   CMS-Encrypted-Data AVP was not required as digitally signed).

   Where an implementation wants to receive a set of AVPs both
encrypted
   and signed it MIGHT use a work around consisting of requiring the
set
   of AVPs as encrypted and CMS-Encrypted-Data AVP as digitally
signed.

   Where there are more AVPs required as encrypted than digitally
signed,
   a CMS-Encrypted-Data AVP MUST be created including only the AVPs
that
   has also to be digitally signed. This AVP will be the input to the 
   signing process. The rest of AVPs required as encrypted MUST be
done
   as many as desired additional CMS-Encrypted-Data AVPs.

Replace the next paragraph in 6.2:

   When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
   AVP MUST be created first.

with

   When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
   AVP MUST be created first, according to the guidelines stated in
6.1.

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 -

---

From: Alain Zahm <[email-masked]>
Date: Thu, 06 Sep 2001 11:10:36 +0200

Well what SMIME is stating on signed/encrypted content is given below (FromR
 FC2311)

-----------------------------
3.5 Signing and Encrypting
To achieve signing and enveloping, any of the signed-only and 
encrypted-only formats may be nested. This is allowed because the above 
formats are all MIME entities, and because they all secure MIME entities.A
 n S/MIME implementation MUST be able to receive and process arbitrarily 
nested S/MIME within reasonable resource limits of the recipient computer.I
 t is possible to either sign a message first, or to envelope the messagef
 irst. It is up to the implementor and the user to choose. When signing 
first, the signatories are then securely obscured by the enveloping. Whene
 nveloping first the signatories are exposed, but it is possible to verifys
 ignatures without removing the enveloping. This may be useful in an 
environment were automatic signature verification is desired, as no privatek
 ey material is required to verify a signature.
-------------------------------

This being said it is better practice to sign then encrypt. What needs tob
 e authenticated is the given values not the encryption result. If you wantt
 o support non-repudiation, then you MUST sign first.

Regards

Alain Zahm

>    AVP MUST be created first, according to the guidelines stated in

**********************************************************************
This footnote confirms that this email message has been swept for the
presence of computer viruses.

SchlumbergerSema - Sophia Antipolis
[email-masked]
**********************************************************************

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 06 Sep 2001 12:42:35 +0200

Alain Zahm wrote:
> 
> Well what SMIME is stating on signed/encrypted content is given below (From
> RFC2311)
> 
> formats are all MIME entities, and because they all secure MIME entities.
> An S/MIME implementation MUST be able to receive and process arbitrarily
> nested S/MIME within reasonable resource limits of the recipient computer.
> It is possible to either sign a message first, or to envelope the message
> first. It is up to the implementor and the user to choose. When signing
> first, the signatories are then securely obscured by the enveloping. When
> enveloping first the signatories are exposed, but it is possible to verify
> signatures without removing the enveloping. This may be useful in an
> environment were automatic signature verification is desired, as no private
> key material is required to verify a signature.
> This being said it is better practice to sign then encrypt.

No, I don't think so. It's only said that one process may be useful in
one environment.

> What needs to
> be authenticated is the given values not the encryption result.
> If you want
> to support non-repudiation, then you MUST sign first.

Well, I see that a previous enveloping doesn't guarantee "direct"
non-repudiation of the sender (it's necessary an extra step to decrypt
the EnvelopedData object, but it doesn't matter so that the recipient
of the message in on the list of receivers in the RecipientInfo of the
CMS EnvelopedData, so it's able to decrypt the content). What I guess
is that this mechanism is lighter, since the receiver must verify
first that it's on the recipients list (by inspecting the
CMS-Encrypted-Data AVP), next check the digital signature and finally
decrypt the encrypted data. Otherwise, a previous decryption would be
always necessary before verifying that the digital signature can be
checked (certificates available, naming compliance and so on).

Of course that this is just my interpretation. Maybe Stephen Farrell
could enlighten us :-)

Regards

  Ombú 3, 10th. 28045 Madrid - SPAIN -

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 06 Sep 2001 12:48:02 +0200

Just a clarification

Miguel Ángel Monjas Llorente wrote:
>    CMS-Encrypted-Data AVP MUST be created first. The resulting CMS
>    object MUST then be MIME encoded producing an 
>    application/pkcs7-mime MIME type which is then used as the
>    content of the EnvelopedData. This means that signing is
>    "outside" encryption.
> 
>    that one encrypted the set of AVPs required as so, the
>    implementation MUST use the CMS-Encrypted-Data AVP (as well as
>    any additional AVP required as only signed) as the input to the
>    signing process (even if the CMS-Encrypted-Data AVP was not
>    required as digitally signed).

 Since the Diameter message will contain, at least, one 
 CMS-Encrypted-Data AVP and a CMS-Signed-Data AVP with a digital
 signature on it, the convention about the 'P' bit MUST be followed.

>    encrypted and signed it MIGHT use a work around consisting of
>    requiring the set of AVPs as encrypted and CMS-Encrypted-Data
>    AVP as digitally signed.
> 
>    signed, a CMS-Encrypted-Data AVP MUST be created including only
>    the AVPs that has also to be digitally signed. This AVP will be
>    the input to the signing process. The rest of AVPs required as
>    encrypted MUST be done as many as desired additional
>    CMS-Encrypted-Data AVPs.
>

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 17:23:06 +0200

Hi all,

according to the discusion on issue 150, this issue may be removed. A
little bit of digital signature doesn't harm any AVP :-)))

Regards

  // M.A.

PS: maybe a fragment of the proposed text:

>    requiring such a set of AVPs as encrypted (using as many as
>    needed Expected-Encrypted-AVP AVPs) and CMS-Encrypted-Data
>    AVP as digitally signed (using an only Expected-Signed-AVP
>    AVP).

could be added at the end of 6.10