RE: baseline CPIM security

Well, I understand your position, but I still believe the group has been
working toward building a 'common core' for IM&P, not merely a gateway
specification (some textual support for this is provided below). If you have
objected to this direction, it is a little strange to be airing it at this
stage.

While I acknowledge the idea that a gateway might support some 'canonical
form' to which and from which it converts various interworked protocols, in
my experience this format is a totally implementation-specific concept that
would require no standardization in a forum like the IETF. I don't think the
text of either the MSGFMT or PIDF drafts supports the contention that they
are intended to be such a 'canonical form' internal to a gateway. MSGFMT
identifies itself as an end-to-end mechanism extensively throughout its
draft. The Motivation section reads:

   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.

This is clearly not talking about internal gateway formats, this is talking
about a message format that must be used by CPIM-compliant protocols. Also,
consider the Introduction to the PIDF draft:

   The significance of the common presence format primarily
   resides in the fact that it alleviates the load of gatewaying of
   messages with presence data payloads.  Without such a common presence
   data format, a gateway must process and transform the presence data
   payload from one format to another every time it gateways the
   protocol messages.  Such payload processing also disables the
   validity of digitally signed presence data.  Utilizing the common
   presence data format allows secure transfer of the presence payloads
   across the boundary of different protocol domains.

Also, applying end-to-end security properties to these objects isn't some
sort of new idea that we're suddenly introducing now. MSGFMT already
references a requirement for an end-to-end security mechanism; consider the
first bullet in the Goals section of the draft:

   o  a securable end-to-end format for a message (a canonical message
      format for signature calculation)

... and this stance is further corroborated throughout the draft and in the
security considerations:

   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.

Finally, the core CPIM spec already suggests that S/MIME could be used to
protect these objects, although the draft applies no normative strengths to
that statement. In my experience, the IESG does not look favorably on work
that has no normatively mandatory-to-implement security mechanism. 

So in summary, I don't think that what I am suggesting is something radical
and new. I merely proposed that we take the security requirements already in
PIDF and MSGFMT and unify them, with some normative strengths, in the core
CPIM spec. I have no doubt that we both want the work of this group to
conclude swiftly - but I fear that without some prospect for
interoperability, including security interoperability, it is unlikely that
this work will efficacious and successful.

Other input on this issue from the group would definitely be appreciated -
we need to arrive at consensus on this matter ASAP.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Thursday, October 03, 2002 6:57 PM
> To: Peterson, Jon
> Cc: 'Beckmann Mark ICM MP P PS 4 SAL 2'; '[email protected]'
> Subject: RE: baseline CPIM security
> 
> 
> At 08:57 PM 10/3/2002 -0400, Peterson, Jon wrote:
> >There are various degrees of interoperability that we might encourage
> >through CPIM - but clearly there would be no need for MSGFMT or the
DateTime
> >RFC or PIDF if our intention wasn't that CPIM-compliant protocols would
use
> >these common objects.
> 
> a gateway specification needs a canonical form.  indeed, gateways that are

> designed for extensibility usually implement a canonical internal form and

> then map to and from it.
> 
> that was the intent behind the original effort on CPIM, as I understood it

> at the time.  the larger and longer-term likelihood of propagating change 
> out to the participating systems was thought to be just 
> that.  likelihood.  not requirement.
> 
> anything that is imposed as a change to a participating system -- such as
a 
> requirement that can only be satisfied by the direct cooperation of the 
> originator or the recipient system -- ensures that CPIM can have 
> essentially no utility as a gateway mechanism and must, instead, be 
> strictly competitive with existing IM services.
> 
> Competition was explicitly not the goal.  Interconnect was the goal.  I 
> guess that has changed.
> 
> 
> >Gateways have no use for something like PIDF
> 
> see the above observation about the role of canonical form in 
> a gateway.
> 
> 
> >  - PIDF is
> >designed to be tunneled through gateways. Now we're merely discussing the
> >addition of security properties to these tunneled objects that we've
already
> 
> "merely discussing the addition" is what is called a slippery slope, and 
> this working group has slipped down it quite a distance.
> 
> take a look at the timeline of this working group.  there is no "merely" 
> for anything that is added.
> 
> d/
> 
> ----------
> Dave Crocker <mailto:[email protected]>
> TribalWise, Inc. <http://www.tribalwise.com>
> tel +1.408.246.8253; fax +1.408.850.1850
> 



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