[Top] [All Lists]

Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData

2005-09-18 03:26:39


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 (, 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
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,