Have you come up with a way to support SignedAndEnvelopedData that does not
include the vulnerability that was described last week?
The SignedAndEnvelopedData was dropped because of a security concern. An
attacker can remove the signature, essentially making an EnvelopedData,
and the recipient has no way to tell that the originator intended to sign
and encrypt the protected content.
Dear Russ:
In answer to your question, NO. Mind you, I do not consider this
to be a serious security concern when compared to the following:
An attacker can also remove the signature from a CMS SignedData
structure and be left with a blocked of unsigned data. How is this
any less of a security concern?
And an attacker can also re-encrypt using a recipient public key,
and replace any encrypted data in a CMS EnvelopedData structure.
On a side note, how about this:
What if we placed a CMS SignedData structure without any encapsulated
data, and placed it in the EncryptedContent of a CMS EnvelopedData
structure? The original detached data that was signed can then be
encrypted using the EncryptedKey in the CMS EnvelopedData structure.
An unprotected attribute for the CMS EnvelopedData structure can be
added that specifies that the original data is encrypted and provide
a digest hash of the encrypted data so that it can be matched against
it.
This appears to be CMS compliant, and it would only need to have
acceptance of an unprotected attribute as a common standard. This
approach for signing and encrypting works great with detached
encrypted data, and protects the identity of the signer since the
detached signature is encrypted.
Comments?
Alicia.