Graeme Lunt wrote:
Which raises another other point. In para 2, it states that:
"X.400 content SHOULD be ASN.1 encoded" (and consequently MUST NOT be
MIME wrapped). Surely this should be "MUST be ASN.1 encoded",
especially given that the "content type of the protected X.400 content
MUST be placed in the eContentType field". (The use of "SHOULD" is
also somewhat at variance with step 1 in 3.4.1 which mandates ASN.1
encoding for triple-wrapped messages).
For example, if I find an eContentType of "2.6.1.10.1" (P22), I would
expect the content to be ASN.1 encoded.
Is there a reason why you would want to allow a different encoding of
the X.400 content prior to protection, or is this just a typo?
Graeme,
I'm going to have to check up on your other comments, but this one has
an immediate answer. The reason that the ASN.1 encoding is a SHOULD and
not a MUST is that X.400 allows non-ASN.1 content. Obviously P22 is not
in this category, but we did not want to unnecessarily exclude the
applicability of the specification. Neither the 'eContent' nor
'encryptedContent' fields in CMS should have any trouble with this. They
are both defined as OCTET STRING, and should be able to handle any data
regardless of encoding.
The chief reasons that we mandated an encoding here in RFC 2633 were
(a) backward compatibility, and (b) MIME processors rely on this wrapper
to tell it what the content is. Neither of these reasons seemed to apply
with X.400 content.
Chris