Alicia da Conceicao <alicia(_at_)engine(_dot_)ca> 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.