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

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Aug 2001 13:12:38 +0100

1.  Is it intentional that there is no section on content encryption
algorithms for MUSTs?

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.

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

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".

5.

---

From: "Bonatti, Chris" <[email-masked]>
Date: Mon, 6 Aug 2001 19:32:39 -0400

> 1.  Is it intentional that there is no section on content encryption

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.

> to be in conflict with the third paragraph where it states that MIME

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?

> 	Content-Type: application/pkcs7-mime; smime-type=signed-x400

Agree.  Anders noted this earlier.

> 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?

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

Best regards,
Chris

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Aug 2001 10:29:23 +0100

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 07, 2001 12:33 AM
To: [email-masked]
Cc: Ietf-Smime; [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03

> 1.  Is it intentional that there is no section on content encryption 

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
binary

> transports such as X.400 are used then the optional MIME encoding 
> SHOULD NOT be used."
>

> to be in conflict with the third paragraph where it states that MIME 

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.

> 	Content-Type: application/pkcs7-mime; smime-type=signed-data
Should 
> be

> 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?

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

no comment.

Best regards,
Chris

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 14 Aug 2001 15:47:32 -0400

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

---

From: "Bonatti, Chris" <[email-masked]>
Date: Tue, 14 Aug 2001 21:20:27 -0400

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

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 15 Aug 2001 01:02:48 -0700

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-----

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

---

From: "Bonatti, Chris" <[email-masked]>
Date: Wed, 15 Aug 2001 11:53:59 -0400

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

jim

-----Original Message-----

Russ,

Chris

-----Original Message-----

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 15 Aug 2001 12:05:02 -0700

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

jim

-----Original Message-----

Russ,

Chris

-----Original Message-----

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 15 Aug 2001 10:58:15 -0400

Chris:

Fine.  I think that Blake will need to expand his discussion to pick up all 
of the details that are no longer in RFC2630bis and CMSALG.

Russ

At 09:20 PM 8/14/2001 -0400, Bonatti, Chris wrote:
>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.
>

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 15 Aug 2001 11:20:47 -0400

Jim:

You are correct that this approach might delay the x400wrap document.  The 
alternative is to replicate the same information in both documents.

Russ