There is no need to specify the encoding rules for this. The content is
contained within an OCTET wrapping, and all of the bytes are encoded
(unlike PKCS#7 where the first type and length bytes are not). Once you
have removed the octet wrapping, you can decode using what ever rules
you have. Generally people will either DER or BER encode the embedded
content so that attempting to decode as BER will work (DER is a subset
of BER).
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
luciano(_dot_)medina(_at_)safelayer(_dot_)com
Sent: Friday, December 21, 2001 10:36 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Encoding of enhanced content types in CMS
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