In CMS, we anticipate the encapsulation of one content type with
another. In SMIME, there is in interposed MIME heading, so this capability
is not used. In other environments, CMS content types are directly
encapsulated (see draft-ietf-smime-x400wrap-03.txt).
Russ
At 07:36 PM 12/21/2001 +0100, luciano(_dot_)medina(_at_)safelayer(_dot_)com
wrote:
A major difference I find between CMS and PKCS#7 (from which CMS is
derived) is the fact that in PKCS#7 it is well defined how to encode
enhanced types to be used as content for another enhanced type.
" Content types in the enhanced class contain content of some type
(possibly encrypted), and other cryptographic enhancements. For example,
enveloped-data content can contain (encrypted) signed-data content, which
can contain data content. "
Specifically, in Section "7.General Sintax", Note 2:
" When a ContentInfo value is the inner content of signed-data,
signed-and-enveloped-data, or digested-data content, a message-digest
algorithm is applied to the contents octets of the DER encoding of the
content field. When a ContentInfo value is the inner content of
enveloped-data or signed-and-enveloped-data content, a content-encryption
algorithm is applied to the contents octets of a definite-length BER
encoding of the content field. "
On the other hand. CMS does not define any encoding rules at all. The new
draft of the CMS points out the question of compatibility with PKCS#7
(section 5.2.1) with the inclusion or not of the tag and lenght octets in
the encoding of a SEQUENCE in the encapContentInfo eContent field, but it
eludes again the matter of which encoding rules should be used in CMS.
Does not it implies that incompatibilities may arise between different
implementations of CMS when the content processed (digested or encrypted)
was other than Data? Suppose I receive a CMS EnvelopedData type, and the
encryptedContentInfo contentType is SignedData. After the decryption
process, how am I supposed to decode the resultant OCTET STRING? With
PKCS#7 I knew I had to use definite-length BER, but now?
I would like to receive some information or comments on this matter.
Luciano Medina
============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and
CONFIDENTIAL. Access by any other party is unauthorized without the express
prior written permission of the sender. If
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender.
Thank You.
============================================================================
================