RE: baseline CPIM security

While no specific understanding of CPIM's requirements was ever formalized
in our charter, to date I have worked under the assumption that the
requirements of RFC2779 apply to CPIM - in the sense that two CPIM-compliant
protocols communicating with one another through a CPIM gateway must meet
the requirements of RFC2779. This would seem to entail that end-to-end
encrypted notifications and so forth should be able to pass a CPIM gateway
without violating the requirements of RFC2779 (like 5.2.1).

Personally, I believe this is a desirable requirement - it would be useful
to be able to send an encrypted instant message from a SIMPLE client to an
APEX client without revealing its contents to any third parties (including
CPIM gateways), and I think it is an achievable requirement (S/MIME being
one way to do it).  If it we do not accept this as a requirement, then, for
example, SIMPLE-to-SIMPLE communication will most likely be more secure than
SIMPLE-to-APEX communication, which to some degree undermines
interoperability.

We should probably have consensus on the requirements before delving further
into the mechanism.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Thursday, October 03, 2002 2:42 PM
> To: Peterson, Jon
> Cc: 'Beckmann Mark ICM MP P PS 4 SAL 2'; '[email protected]'
> Subject: RE: baseline CPIM security
> 
> 
> At 02:03 AM 10/3/2002 -0400, Peterson, Jon wrote:
> >The requirements of RFC2779 entail an end-to-end security 
> model - this
> >suggests that either transport or network layer security 
> would not meet the
> 
> 1.  The subject line of this thread refers to CPIM, but 2779 
> refers to a 
> protocol.  CPIM is not a protocol.  It is a gateway mechanism.  In a 
> gateway, there is no "end to end".  For that matter, a 
> gateway translates 
> between protocol environments, so the concept of end to end 
> is difficult 
> there, too.
> 
> 2.  In a variety of venues, there has occasionally been discussion of 
> separating object-oriented security mechanisms to permit 
> re-use of the data 
> encryption key (ie, the computational cheap "session" key) 
> from the public 
> key mechanism, so that multiple messages can use the same 
> encryption key.
> 
> 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]