Subject: SV: Comments on draft-ietf-smime-x400wrap-03

From: "Eggen, Anders" <[email-masked]>
Date: Tue, 7 Aug 2001 15:47:41 +0200

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

---

From: "Eggen, Anders" <[email-masked]>
Date: Wed, 15 Aug 2001 22:42:18 +0200

Jim and Chris

I'm OK with "aligning with" instead of "referencing".  

Anders

-----Original Message-----
From: Jim Schaad
To: 'Bonatti, Chris'; 'Housley, Russ'; [email-masked]
Sent: 15.08.01 21:05
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

Alignment rather than reference makes more sense to me.  Then the two
communities can upgrade at different rates on algorithms etc according
to desires of the different groups.  (X.400 might be more security aware
than the general community.)

jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bonatti, Chris
Sent: Wednesday, August 15, 2001 8:54 AM
To: [email-masked]; 'Housley, Russ'; [email-masked]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

Jim,

This is a good point that I hadn't considered.  I can go with "aligning
with" instead of "referencing".  Okay?

Chris

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 04:03
To: 'Bonatti, Chris'; 'Housley, Russ'; [email-masked]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

I am not sure that I agree with this.  I would like to see these drafts
progress and that cannot happen if you are going to reference son-of-MSG
until it finishes.

jim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 14, 2001 6:20 PM
To: Housley, Russ; [email-masked]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

Russ,

I think that referencing son-of-MSG would be best, since the protection
is really targeted at the same kind of functional use... e-mail.  It's
just a different e-mail.

I'll take a look at Blake's draft and see whether I can propose some
text.

Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Housley, Russ
Sent: Tuesday, August 14, 2001 15:48
To: [email-masked]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

Correct.  At the face-to-face meeting in London last week, there was
strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case,
x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents
to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad 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.
>
>[JLS]  With the most recent change of omitting algorithms from CMS,
this
>section is now required both here and in the message draft.