Re: Fixing documents and proposed agenda for Minneapolis

At 16:15 12/10/03 -0400, Mark Day wrote:
>The IESG has responded to our various drafts and so it makes sense to
>discuss how we should proceed.  It is really hard to figure out in the ID
>tracker where the comments are (I had to ask our AD for help), so here's the
>link:
>https://www1.ietf.org/IESG/EVALUATIONS/draft-ietf-impp-im.bal

In my previous message, I didn't respond to the comments concerning 
reference to S/MIME.

On reviewing these as they apply to <draft-ietf-impp-cpim-msgfmt>, I think 
there is some confusion about the intended scope of the message format 
specification.

Steve Bellovin comments:
[[
draft-ietf-impp-cpim-msgfmt
                 Why isn't it using S/MIME or CMS used? The problem statement
                 sounds about the same.

                 (I'd really like Russ to see these documents; he's the S/MIME
                 expert.)
]]

and:

[[
The problem I have is that draft-ietf-impp-cpim-msgfmt lays out a
detailed set of requirements and explains how to use MIME. If S/MIME
is the right answer, much of the rationale can be omitted, except
perhaps a short statement that the environmental model is very much
like the one that email has. This is the message format RFC; it should
really point to the authoritative source for the desired encoding and
encapsulation. The rationale, if needed at all, should have been in
draft-ietf-impp-im, which is setting out the framework.

Beyond that, it isn't clear to me that they've said enough about how to
use CMS and S/MIME. There are lots of possible options and variations;
I don't know that all are useful or correct here. That's where I want
to defer to Russ.
]]

I'm finding this comment hard to fathom, so maybe I'm, missing the point, 
but here in my initial response:

This draft was never intended to tell people how to apply security to the 
message format.  As far as security is concerned, the requirement was to 
provide a consistent message content format to which security could be 
applied, and the only references to security that I recall are:
[[
    To adequately meet the security requirements of RFC 2779, a common
    message format is needed so that end-to-end signatures and encryption
    may be applied.  This document describes a common canonical message
    format that must be used by any CPIM-compliant message transfer
    protocol, and over which signatures are calculated for end-to-end
    security.
]] -- sect 1.1
[[
       For example RFC2822/MIME comments may be encoded in multiple ways.
       For security purposes, a single encoding method must be defined as
       a basis for computing message digest values.  Protocols that
       transmit data in a different format would otherwise lose
       information needed to verify a signature.
]] -- sect 1.2
[[
    o  Mutability -- addition, modification or removal of header
       information.  Because it is not explicitly forbidden, many
       applications that process MIME content (e.g. MIME gateways)
       rebuild or restructure messages in transit.  This obliterates most
       attempt at achieving security (e.g. signatures), leaving receiving
       applications unable to verify the received data.

]] -- sect 1.2
[[
    The Message/CPIM format encapsulates an arbitrary MIME message
    content, together with message- and content-related metadata.  This
    can optionally be signed or encrypted using MIME security multiparts
    in conjunction with an appropriate security scheme.
]] -- sect 2
[[
    In order to secure a Message/CPIM, an application or implementation
    should use RFC 1847 and some appropriate cryptographic scheme.

    Using S/MIME and pkcs7, the above message would look like this:
    ...
]] -- sect 5.2, noting this is just an example
[[
    The Message/CPIM format is designed with security in mind.  In
    particular it is designed to be used with MIME security multiparts
    for signatures and encryption.  To this end, Message/CPIM messages
    must be considered immutable once created.

    Because Message/CPIM messages are binary messages (due to UTF-8
    encoding), if they are transmitted across non-8-bit-clean transports
    then the transfer agent must tunnel the entire message.  Changing the
    message data encoding is not an allowable option.  This implies that
    the Message/CPIM must be encapsulated by the message tranfer system
    and unencapsulated at the receiving end of the tunnel.

    The resulting message must have no data loss due to the encoding and
    unencoding of the message.  For example, an application may choose to
    apply the MIME base64 content-transfer-encoding to the Message/CPIM
    object to meet this requirement.
]] -- sect 9 (security considerations)

It seems to me that much of the text here is about saying why pure MIME is 
insufficient for the purposes set out by the WG, viz to be able to 
reconstruct a verifiable message even when it has been transmitted using a 
different format for the message headers.  The message format itself is 
clearly specified to be NOT MIME (even if it uses a few syntactic 
conventions of RFC2822/MIME).  And (apart from one illustrative example) 
this document does not attempt to specify how security should be applied -- 
that is for the application to specify.

...

In response to Steve's comments, I propose to add some text to section 1.1 
to try and clarify the scope of this specification, along the lines of:
[[
The common message format is intended to allow the use of security 
techniques, without saying what techniques should be used, or how those 
techniques should be applied.  It is a matter for the instant messaging and 
presence application specifications to describe any specific security 
mechanisms that are needed.  Because the message format can be encapsulated 
as a MIME object, it is possible (but not required) to use MIME security 
techniques, such as RFC1847, S/MIME and PGP-MIME.
]]

Arguably, in light of the this, the suggestion to use RFC1847 should be 
toned down, or removed, to avoid any appearance of specifying how to apply 
security.  So, the (lower case) "should" in section 5.2 would become a "may".

Also, section 6 (application design considerations) should include a bullet:
[[
[Applications using this specification must also specify:]

o Any specific security techniques and algorithms that are used to to 
protect the integrity and/or confidentiality of the message content.
]]

Returning to Steve's comment:  "If S/MIME is the right answer ...".  From 
the scope of the message format specification, it is not at all clear that 
S/MIME is the right answer.  The message format is truly agnostic about 
what specific security technology is appropriate, and just tries to ensure 
that they can be applied.

A possible point of misunderstanding here is that the message format itself 
is *not* MIME, but a new format that employs some syntactic conventions 
from MIME.  This might be clarified by adding something like this in 
section 1.1:

[[
The CPIM message format is associated with a new MIME type, but the message 
format itself is NOT MIME.  Message headers and message payload are all 
part of a specified format that may be conveyed within a MIME object 
wrapper using the indicated MIME content-type.  In this way, many of the 
problems associated with securing headers in RFC2822/MIME message formats 
are avoided.
]]

...

Note that these comments are made with respect to the message format 
specification (only):  it may be that the issues raised do need to be 
addressed in (say) the CPIM service specification.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact




  [reminder: [email protected] for non-technical discussions, please]