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