[Top] [All Lists]

RE: Comments on draft-ietf-smime-x400wrap-03

2001-08-08 02:29:32

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Bonatti, 
Sent: Tuesday, August 07, 2001 12:33 AM
To: jimsch(_at_)exmsft(_dot_)com
Cc: Ietf-Smime; phoffman(_at_)imc(_dot_)org; 
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

On Monday, August 06, 2001 08:13 Jim Schaad 

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.

[JLS]  With the most recent change of omitting algorithms from CMS, this
section is now required both here and in the message draft.

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
MAY mime wrap.   Additionally if a MIME wrapper is added to the
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?

[JLS] OK your description here makes much more sense.  I was looking at
this and reading it as a question of whether or not there was mime
wrapping at each layer of wrapping not at the top level.  I don't
however believe that the outer wrapping is at all interesting as the
adding and stripping of this on the gateway is trivial.

3.  Section 3.2.1:  The following
      Content-Type: application/pkcs7-mime; smime-type=signed-data
      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 

[JLS] Just remove the "as a single block".  "Encrypt the result of step
3." is sufficent.


If there was a comment 5, I didn't receive it.

no comment.

Best regards,