Jim, Chris,
>>
>> 1. Is it intentional that there is no section on content
encryption
>> algorithms for MUSTs?
>Yes. From the beginning, the model for this draft was RFC 2633.
We dealt
>with this only in the "options" for CMS, and what it says has crept
in
>through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and
leave the
>topic to CMS (Son-of-CMS). However, I don't think the division is
easy to
>make cleanly.
>>
>> 2. I don't understand the reasoning behind the following
statement from
>> section 3.2. Why should this be an important statement? I don't
like
>> the fact that the encoding is suppose to be based on where one
thinks
>> the message MIGHT be sent. I don't see any problem with SHOULD
binary
>> MAY mime wrap. Additionally if a MIME wrapper is added to the
outside
>> of the SignedData object, then it does not matter if the inner is
>> encoded as binary as the mime wrapper can base64 the entire
object. [
>> This is also inconsistant with behavior for encrypted data where
it is
>> always the x.400 content that is embedded. ]
>>
>> "Note that if SMTP [SMTP] used to transport the resulting
signed-only
>> message then the optional MIME encoding SHOULD be used. If binary
>> transports such as X.400 are used then the optional MIME encoding
SHOULD
>> NOT be used."
>>
>> The preceeding text is also present in section 3.3, however it
appears
>> to be in conflict with the third paragraph where it states that
MIME
>> SHOULD NOT be used.
The third and fifth paragraph are not in conflict with each other.
Paragraph 3 states that the X.400 content SHOULD NOT be MIME encoded before
it is encapsulated in EnvelopedData, wheras the fifth paragraph states that
the outer ContentInfo SHOULD be MIME encoded if SMTP transport is used.
>The notion here is multifold: (a) we don't think that an outer MIME
wrapper
>should be used in the X.400 scenario; (b) we recognize that there
are places
>where X.400 systems will meeting SMTP/MIME systems where the outer
MIME
>wrapper might be necessary; (c) we assumed that since this was
outside the
>security wrappers whatever servers or gateway logic bridged the gap
between
>the two systems would be smart enough to apply or remove the outer
MIME
>wrapper as appropriate. The text you are seeing is an attempt to
cast these
>thoughts into the language of RFC 2633. Perhaps there is a better
way to
>present this issue.
>
>Perhaps a better way is to state that the MIME wrapper MAY be
applied, and
>simply state the conditions (as above). Thoughts?
In an X.400 environment where this RFC is most likely to be used,
you don't need the extra outer MIME wrapper. In fact it only adds additional
overhead (ca. 40 %) to the wrapped object. This was the rational for stating
that the optional MIME encoding should not be used in X.400 environments.
Apart from this I don't have any problems with Chris' new proposal.
>>
>> 3. Section 3.2.1: The following
>> Content-Type: application/pkcs7-mime; smime-type=signed-data
>> Should be
>> Content-Type: application/pkcs7-mime; smime-type=signed-x400
>Agree. Anders noted this earlier.
>>
>> 4. Section 3.4.1: Step 4 uses the phrase "in a single block".
This
>> bothers me as it implies that the entire body needs to be
supplied at
>> once. We octet wrap the content so this is not necessary.
Please
>> remove or clarify what is meant by "in a single block".
>I don't see how it implies anything inappropriate. The step 4
encryption
>has to process the entire step 3 output to proceed. I read "in a
single
>block" to mean that the result of step 3 including the content.
Since the
>detached signature form does not apply to triple-wrapped messages,
this
>seems to me to be the only way to do this. How do you think this
could be
>clarified?
I don't see the problem either.
>>
>> 5.
>If there was a comment 5, I didn't receive it.
>>
>Best regards,
>Chris
Best regards
Anders