Skip to main content

Shepherd writeup
draft-campbell-sip-messaging-smime

# Summary

This document offers guidance on how to provide end-to-end authentication,
integrity protection, and confidentiality for SIP (Session Initiation Protocol)
based messaging using S/MIME (Secure/Multipurpose Internet Mail Extensions). 
It updates and clarifies RFC 3261, RFC 3428, and RFC 4975 in an attempt to make
it easier to implement and deploy in an interoperable fashion.  It also updates
cryptographic algorithm recommendations previously specified in RFC 3261, RFC
3428, and RFC 4975.  This document is targeted as Standards Track because of
these updates.

Sean Turner is the document shepherd.

Alexey Melnikov is the responsible Area Director.

# Review and Consensus

The document was presented at IETF100 to the DISPATCH WG, see
https://datatracker.ietf.org/meeting/100/materials/slides-100-dispatch-secure-messaging-00.
 The draft was also discussed on the dispatch list; the result was to suggest
AD sponsorship:
https://mailarchive.ietf.org/arch/msg/dispatch/Vm6bWtZs28fCQbwmlWu9OZK6Efc.

In general, the discussion did not indicate major technical flaws. There were
some minor comments that have been addressed in version 3. There was some
questions about whether the material is still relevant, but there were other
comments indicating support. This included a comment to the effect that there
is US wireless industry support for the work. (See “Other Points” section for
related details.)

# Intellectual Property

I have confirmed with each author that to their direct, personal knowledge any
IPR related to this document has already been disclosed, in conformance with
BCPs 78 and 79.

# Other points

This document updates RFCs 3261, 3428, and 4975; the header, abstract, and
introduction clearly denote this fact.  Note that ID-nits complains about the
“RFC” being in the “Updates” line.

References:
* There is one DOWNREF, RFC 5753, but RFC 5753 has been in the DOWNREF registry
for a long time.  RFC 5753, actually all RFCs which specified EC (Elliptic
Curve) algorithms, was Informational because of IPR concerns.  Now you’ll note
that many protocols are standardizing on EC curves. * There is one obsolete
informational reference but that is by design.

There are no IANA considerations for this document, and that makes sense
because it’s not defining any new OIDs (Object Identifiers) for algorithms used
in CMS/S/MIME, SIP headers, etc.

Carriers are talking about deployment of the RCS specifications from GSMA,
which depends upon SIP MESSAGE and MSRP.  This specification provides
end-to-end protection for both of those messaging protocols.  Without this
specification (or one something like it), then will not be an opportunity for
end-to-end protections.  At least one industry association is looking into the
infrastructure needed to support the deployment of these end-to-end security
capabilities.
Back