On Monday, August 06, 2001 08:13 Jim Schaad
[mailto:jimsch(_at_)nwlink(_dot_)com]
wrote:
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 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?
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?
5.
If there was a comment 5, I didn't receive it.
Best regards,
Chris