Subject: Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData

From: Alicia da Conceicao <[email-masked]>
Date: Sun, 18 Sep 2005 05:43:55 -0400 (EDT)

Greetings:

For CMS EnvelopedData, it would be very useful to have an
UnprotectedAttribute containing a DigestInfo (as defined in PKCS#1) with
a hash of the encrypted data.

        DigestInfo ::= SEQUENCE {
            digestAlgorithm DigestAlgorithm,
            digest OCTET STRING }

This would be essential when the encrypted data is detached from the CMS
EnvelopedData structure, which occurs when the optional encryptedContent
is not present.  If one has either the detached encrypted data or the CMS
EnvelopedData, then this hash would greatly assist in finding a match for
the other.

What OID should I assign this DigestInfo attribute?  Although I could use
a custom OID from my corporate tree (2.16.124.113568), it would be best to
use any existing standard.  In fact, if no existing standard exists, then
it should be offically published by this IEFT-SMIME group.

In additional, since SignedAndEnvelopedData is not available in CMS, one
could simply place a CMS SignedData structure inside the encryptedContent
of a CMS EnvelopedData structure.  This would protect the identity of the
signer and prevent forgery.

For signed and encrypted data that is completely detached from a CMS
structure, which is useful for large or streamed data, one can do the
following...  Place a SignedData structure with **DETACHED DATA** inside
the encryptedContent of a CMS EnvelopedData structure, then **ENCRYPT THE
EXTERNAL DETACHED DATA WITH THE SAME CIPHER AND KEY USED IN THE
encryptedContent**.  Adding the UnprotectedAttribute DigestInfo would
also be essential, although this time the hash should be of the external
encrypted data and not the internal encryptedContent.

But since we have two sets of encrypted data, one for the signature in
the embedded encryptedContent, and one for the external data, should a
different OID be used for the DigestInfo attribute?  Or should a second
UnprotectedAttribute be added that specifies that the CMS EnvelopedData
structure is associated with TWO sets of encrypted data?

I would greatly appreciate hearing your feedback on this.
Thank you in advance,
Alicia.

---

From: Blake Ramsdell <[email-masked]>
Date: Sun, 18 Sep 2005 04:19:04 -0700

> it should be offically published by this IEFT-SMIME group.

I think we need to get some buy-in from the working group to  
determine if we want to undertake this. One way to start is to submit  
an individual submission with your proposal, and then see if you can  
get traction for it. The worst case is that it's an individual  
submission and you've contributed your work, but not in the working  
group (which isn't that bad). I think that this is a perfectly  
reasonable thing to discuss on the list, however, since it's an add- 
on for CMS.

I am only aware of the message-digest attribute in section 11.2 of  
RFC 3852, which does not include any information about the algorithm  
used (just the digest value).

> encrypted data and not the internal encryptedContent.

I don't understand -- why not just produce a normal Enveloped data  
and then detach the entire encryptedContent (which is basically an  
encrypted SignedData)?

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 19 Sep 2005 20:35:42 +1200

Alicia da Conceicao <[email-masked]> writes:

>UnprotectedAttribute containing a DigestInfo (as defined in PKCS#1) with a
>hash of the encrypted data.
>

I proposed something like this a while back to get around the patent mess
surrounding the encrypt+authenticate modes of operation, and the response was
pretty underwhelming.  Specifically though, you want a MAC, not a digest, to
protect the content.  PGP uses a straight hash, but protects it by encrypting
it alongside the content.  If you use a hash then besides the obvious weakness
of not protecting it from modification, you also leak information about the
content in the hash.

>EnvelopedData structure, which occurs when the optional encryptedContent is
>not present.  If one has either the detached encrypted data or the CMS
>EnvelopedData, then this hash would greatly assist in finding a match for the
>other.

OK, that's a quite different use for what I was proposing it for - I was after
integrity protection of the content.  This is something that no current CMS
mechanism provides, but which a great many users expect as being provided when
they use encryption (see Simpson Garfinkel's thesis).  Adding a MAC as PGP has
would ensure that the behaviour of a CMS envelope met user's expectations.

Peter.

---

From: Alicia da Conceicao <[email-masked]>
Date: Mon, 19 Sep 2005 06:02:24 -0400 (EDT)

> of not protecting it from modification, you also leak information about the

Hi Peter:

Actually since the hash is generated by digesting the encrypted data,
no information would be leaked, since that data is encrypted with
random session keys, the resulting hash would be random as well.

There is no signifigant advantage in using an HMAC, and the encrypted
data integrity, and hence the unencrypted data integrity can be verified.

You are correct though, since the hash in an UnprotectedAttribute, it can
be replaced by an attacker.  This would not gain the attacker any info on
the data itself, but the attacker would be able to corrupt the encrypted
data, and the recipient would not be able to verify its integrity since
they could replace the hash.

But that is why I am interested in place a CMS SignData structure inside
the encryptedContent of a CMS Enveloped structure, since a digital
signature would verify data integrity, originality, and more.

> would ensure that the behaviour of a CMS envelope met user's expectations.

Correct, using a HMAC in an UnprotectedAttribute would be a method of
verifying data integrity, but it would not be useful in finding a match
between detached encrypted data and a CMS envelopedData structure.

Prehaps we need two UnprotectedAttribute for the CMS EnvelopedData
structure.  One attribute for matching of detached encrypted data, and
the other attribute for data integrity that is protected.  I would be
open to any creative suggestions on a way for us to solve both problems
with a single attribute.

Thanks in advance.
Alicia.

---

From: Alicia da Conceicao <[email-masked]>
Date: Mon, 19 Sep 2005 06:02:24 -0400 (EDT)

<<< No Message Collected >>>

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 19 Sep 2005 23:15:23 +1200

Alicia da Conceicao <[email-masked]> writes:

>But that is why I am interested in place a CMS SignData structure inside the
>encryptedContent of a CMS Enveloped structure, since a digital signature
>would verify data integrity, originality, and more.

But in that case why not just nest encrypted inside signed or signed inside
encrypted?  This seems like a rather awkward way of recreating the old
SignedAndEncrypted...

>Prehaps we need two UnprotectedAttribute for the CMS EnvelopedData structure.
>One attribute for matching of detached encrypted data, and the other
>attribute for data integrity that is protected.  I would be open to any
>creative suggestions on a way for us to solve both problems with a single
>attribute.

I think one of the possible objections to the HMAC use was that you need two
distinct keys, one for encryption and one for the HMAC, and there's no obvious
way to handle the second key in a system that usually only has a single
encryption key.  My suggestion would have been to use the key as is for
encryption and pass it through PBKDF2 to get the HMAC key.  This would be
backwards-compatible, since existing code would decrypt as normal and
integrity-enhanced code would know about the extra PBKDF2 + MAC step.

A bigger problem is that RecipientInfo doesn't provide any way of indicating
that integrity protection is to be applied without breaking backwards-
compatibility.  That is, you could use (say) a 3DES-with-HMAC-SHA1 OID, but
any existing app looking for 3DES only won't be able to process it based
solely on the OID.  The only place where you could put this is in the
originatorInfo by adding another choice for general attributes.  To some
extent this makes sense, since it's not per-recipient information but just an
advisory that the originator has provided optional integrity protection.

Peter.