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.
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).
Hi Blake:
Correct, that is why I suggested using a DigestInfo attribute instead
of the message-digest attribute, since the DigestInfo includes the
algorithmIdentifier. In addition, a different OID should be used,
since the hash is generated by digesting the encrypted data, instead
of digesting the unencrypted data.
Note that if one does not include the encryptedContent, then without
my proposed hash, there is NOTHING IN THE CMS EnvelopedData structure
that can be used to MATCH it with its EXTERNAL ENCRYPTED DATA. Hashes
are also used to match up CMS SignedData with its external data.
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.
I don't understand -- why not just produce a normal Enveloped data
and then detach the entire encryptedContent (which is basically an
encrypted SignedData)?
Because then the SignedData has to embed the data. I am looking for a CMS
replacement for PKCS7 SignedAndEnvelopedData that would work with fully
detached and encrypted data. What I suggested would do that.
This way I can send a single CMS structure in a small messager header
which contains both the digital signature and encryption keys. Then stream
the actual external encrypted data in a large message body, which can be
directly decrypted on the fly since it is just a RAW data OCTET STRING.
This is especially true for large (> 2GB) data, since it much easier to
decrypt streaming data and keep a running hash total on the fly.
Especially if one uses DER encoding.
Alicia.