On Sep 18, 2005, at 2:43 AM, Alicia da Conceicao wrote:
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).
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)?
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com