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

I believe this is a correct interpretation of the relationship between CPIM
and 2779.

The alternative would be that only the individual CPIM-compliant protocols
have to have the 2779-specified security properties, and that CPIM-based
gatewaying between different protocols might break those properties. That
would seem to be contrary to our larger goal of encouraging interoperation.

That said, I am also sympathetic with Dave's sense that CPIM is about
gatewaying, and that gateways can't get "uppity" and start acting as though
they can force changes on the various sides being gatewayed.  But the
situation of IMPP with respect to its descendant WGs is a little different
from a typical gateway.  In particular, each of the child groups has in its
charter that it has to be IMPP-compliant, and the explicit role assigned to
IMPP by the ADs at the reorganization was to pull together the minimal core
required for interop among the otherwise divergent protocols.  I think it's
reasonable that the core might include some kind of mandatory security
baseline for compliance with the security-related parts of 2779.

Concretely, and as a non-expert on security, I'll observe that the S/MIME
part of Jon's proposal seems reasonable. However, specifying a ciphersuite
that is still in the discussion phase seems like a complete non-starter. For
better or worse, any security baseline would have to be something that can
be completely specified and implemented right now.

--Mark




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