Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-00.txt

From: Graeme Lunt <[email-masked]>
Date: Fri, 10 Nov 2000 08:31:03 -0000

Hi,

Here are some comments on the following draft:
> 	Title		: Securing X.400 Content with S/MIME

They relate to section 3.2.

The use of the terms "signedData Element", "signedData object" and 
"signedData structure" seems a little confusing. As I read it:

"signedData element" is the encapContentInfo(EncapsulatedContentInfo) 
field within "SignedData"

"signedData structure" is the complete SignedData SEQUENCE

and

"signedData object" is the the ContentInfo SEQUENCE, with a
contentType of id-signedData, containing the SignedData SEQUENCE

If this is indeed correct, then the last sentence of para 2. should 
be made the first sentence of para 1. This would more closely follow
the line of processing, and indicate the use of only one optional 
MIME encoding, the transport.

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?

(In para 2, 3rd sentence you should add a "the", so as to read:
"The object identifier for the content type ...")

A similar set of comments apply to section 3.3

Graeme

---

From: "Bonatti, Chris" <[email-masked]>
Date: Mon, 13 Nov 2000 11:22:46 -0500

> 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