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