Subject: RE: [Simple] MSRP Security Review: RFC3862 Application Considerations

From: [email-masked]
Date: Fri, 10 Sep 2004 11:08:15 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Ben Campbell
> Sent: 10.September.2004 05:22
> To: Simple WG
> Subject: [Simple] MSRP Security Review: RFC3862 Application
> Considerations
> 
> 
> Hi,
> 
> Sam's security review pointed out that we had not handled the 
> application considerations required by RFC3862 on all applications 
> using the message/cpim MIME type. Here is a first cut at those 
> considerations for discussion (quoted text from RFC3862)
> 
> >   Applications using this specification must also specify:
> >
> >    o  all headers that must be recognized by implementations of the
> >       application
> 
> All MSRP endpoints MUST recognize the From, To, DateTime, and Require 
> headers as defined in RFC3862. Such applications SHOULD recognize the 
> CC header, and MAY recognize the Subject header. Any MSRP application 
> that recognizes any message/cpim header MUST understand the NS (name 
> space) header.
> 
> >
> >    o  any headers that must be present in all messages 
> created by that
> >       application.
> 
> All message/cpim body parts send by an MSRP endpoint MUST include the 
>  From and To headers. If the message/cpim body part is 
> protected using 
> S/MIME, then it SHOULD also include the DateTime header.
> 
> >
> >    o  any headers that may appear more than once in a 
> message, and how
> >       they are to be interpreted (e.g., how to interpret multiple
> >       'Subject:' headers with different language parameter values).
> >
> 
> Message/cpim headers defined in RFC 3862, with the exception 
> of the NS 
> header, MUST NOT occur more than once in a given message/cpim 
> body part 
> in an MSRP message. The Require header MAY include multiple 
> values. The 
> NS header MAY occur zero or more times, depending on how many name 
> spaces are being referenced.
> 
> Extension headers MAY occur more than once, depending on the 
> definition 
> of such headers.

The To-header field should not be limited to 1, nor should the CC field. This could be used in the future for, what is commonly referred to as, whispering or private messages within a conference.

Also, the subject header might appear multiple times. I would say we limit the from-header to one and no limit on the rest.

Regards,
Hisham

> 
> >    o  Security mechanisms and crytography schemes to be 
> used with the
> >       application, including any mandatory-to-implement security
> >       provisions.
> 
> [Ben: I _think_ we are covering this in general--do we need to 
> explicitly relate such mechanisms to message/cpim?]
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Sep 2004 08:18:11 -0500

On Sep 10, 2004, at 3:08 AM, <[email-masked]> wrote:

[...]

> The To-header field should not be limited to 1, nor should the CC 
> field. This could be used in the future for, what is commonly referred 
> to as, whispering or private messages within a conference.
>
> Also, the subject header might appear multiple times. I would say we 
> limit the from-header to one and no limit on the rest.
>

Good point on multiple To and CC values. I'm not sure how CC helps for 
whisper, I think you are looking for something like BCC, which is more 
of a function than a header. Nevertheless, I can see needing multiple 
CC values.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Sep 2004 09:25:34 -0400

Hisham,

I agree with most of your comments, but I question the logic of multiple 
Subject headers. What does this mean? Is the actual subject the 
catenation of the contents of all the Subject headers? Should they have 
<CR><LF> between then when displayed? Or are they to be treated as 
alternatives, such as the same subject represented in different languages?

I believe 3261 only allows one Subject header. I don't know about email, 
but by common usage I don't think it would work well if there was more 
than one.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Sep 2004 09:53:07 -0500

Oops, in my hurry to reply about To and CC, I missed Subject. I also 
don't know what it means to have multiple subjects. The application 
considerations require us to document what it means to have more than 
one of any particular header that we allow multiples for. Hisham, did 
you have an application in mind?

On Sep 10, 2004, at 8:25 AM, Paul Kyzivat wrote:

> Hisham,
>
> I agree with most of your comments, but I question the logic of 
> multiple Subject headers. What does this mean? Is the actual subject 
> the catenation of the contents of all the Subject headers? Should they 
> have <CR><LF> between then when displayed? Or are they to be treated 
> as alternatives, such as the same subject represented in different 
> languages?
>
> I believe 3261 only allows one Subject header. I don't know about 
> email, but by common usage I don't think it would work well if there 
> was more than one.
>
> 	Paul
>
>>> From: [email-masked] [mailto:[email-masked]]On 
>>> Behalf
>>> Of ext Ben Campbell
>>> All MSRP endpoints MUST recognize the From, To, DateTime, and 
>>> Require headers as defined in RFC3862. Such applications SHOULD 
>>> recognize the CC header, and MAY recognize the Subject header. Any 
>>> MSRP application that recognizes any message/cpim header MUST 
>>> understand the NS (name space) header.
>>>
>>>
>>> All message/cpim body parts send by an MSRP endpoint MUST include 
>>> the From and To headers. If the message/cpim body part is protected 
>>> using S/MIME, then it SHOULD also include the DateTime header.
>>>
>>>
>>> Message/cpim headers defined in RFC 3862, with the exception of the 
>>> NS header, MUST NOT occur more than once in a given message/cpim 
>>> body part in an MSRP message. The Require header MAY include 
>>> multiple values. The NS header MAY occur zero or more times, 
>>> depending on how many name spaces are being referenced.
>>>
>>> definition of such headers.
>> field. This could be used in the future for, what is commonly 
>> referred to as, whispering or private messages within a conference.