Skip to main content

SIP-Based Messaging with S/MIME
draft-campbell-sip-messaging-smime-05

Revision differences

Document history

Date Rev. By Action
2019-04-26
05 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-04-22
05 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-04-15
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-03-11
05 (System) IANA Action state changed to No IANA Actions from In Progress
2019-03-11
05 (System) RFC Editor state changed to EDIT
2019-03-11
05 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-03-11
05 (System) Announcement was received by RFC Editor
2019-03-11
05 (System) IANA Action state changed to In Progress
2019-03-11
05 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-03-11
05 Amy Vezza IESG has approved the document
2019-03-11
05 Amy Vezza Closed "Approve" ballot
2019-03-11
05 Amy Vezza Ballot approval text was generated
2019-03-11
05 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-03-09
05 Eric Rescorla [Ballot comment]
Thank you for addressing my DISCUSS.
2019-03-09
05 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss
2019-01-26
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-01-26
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-01-26
05 Ben Campbell New version available: draft-campbell-sip-messaging-smime-05.txt
2019-01-26
05 (System) New version approved
2019-01-26
05 (System) Request for posting confirmation emailed to previous authors: Ben Campbell , Russell Housley
2019-01-26
05 Ben Campbell Uploaded new revision
2018-10-25
04 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-10-25
04 Benjamin Kaduk
[Ballot comment]
I support Ekr's Discuss.

Section 4.1

nit: please use the same formatting for the id-Ed25519 OID as the other
OIDs in the document. …
[Ballot comment]
I support Ekr's Discuss.

Section 4.1

nit: please use the same formatting for the id-Ed25519 OID as the other
OIDs in the document.

Section 4.2

  Symmetric key-encryption keys can be distributed before messages are
  sent.  If sending and receiving UAs support previously distributed
  key-encryption keys, then they MUST assign a KEK identifier [RFC5652]
  to the previously distributed symmetric key.

nit: 5622 seems to spell it "KEKIdentifier" (with no space).

nit: id-X25519 OID formatting, too.

Section 4.3

Many readers may be used to seeing encrypt-then-mac used to avoid the
well-publicised security risks of mac-then-encrypt; some discussion of why
sign-then-encrypt is safe in that regard might be in order.

Section 6

  SIP signaling can fork to multiple destinations for a given Address
  of Record (AoR).  A user might have multiple UAs with different
  capabilities; the capabilities remembered from an interaction with
  one such UA might not apply to another.

No discussion of the potential consequences of this for message reception
and display to the user?

Section 8.1

  The sender MUST apply any S/MIME operations to the whole message
  prior to breaking it into chunks.  Likewise, the receiver needs to
  reassemble the message from its chunks prior to decrypting,
  validating a signature, etc.

Are there any new DoS concerns due to retaining such state until the final
chunk is available?

Sectino 9.1

                                                  UAs that support
  S/MIME and CPIM SHOULD be able validate signatures and decrypt
  enveloped data both when those operations are applied to the entire
  CPIM body, and when they are applied to just the CPIM payload.

How do such UAs know which validation procedure to use?

Section 12

                                In general, the UAS should compare the
  certificate to the identity that it relies upon, for example for
  display to the end-user or comparison to white lists and blacklists.

[just noting we had a long ietf@ thread about potentially offensive
terminology; no action expected]

                  While hop-by-hop protection can mitigate some of those
  risks, it still leaves messages vulnerable to malicious or
  compromised intermediaries.

Hop-by-hop doesn't address impersonation unless the client requires
hop-by-hop protection, in which case it is still limited protection.
2018-10-25
04 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-10-25
04 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-10-25
04 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-10-24
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-24
04 Michelle Cotton IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-10-24
04 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-10-24
04 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-10-24
04 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-10-23
04 Spencer Dawkins
[Ballot comment]
Thanks for doing this work.

Just for my own background, does the "updates RFC 3261" also improve the ability to implement and …
[Ballot comment]
Thanks for doing this work.

Just for my own background, does the "updates RFC 3261" also improve the ability to implement and deploy S/MIME for other SIP applications?

  While both SIP and MSRP provide mechanisms for hop-by-hop security,
  neither provides native end-to-end protection.  Instead, they depend
  on S/MIME [RFC5750][RFC5751].  However at the time of this writing,
  S/MIME is not in common use for SIP and MSRP based messaging
  services.  This document updates and clarifies RFC 3261, RFC 3428,
  and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier
  to implement and deploy in an interoperable fashion.
2018-10-23
04 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2018-10-23
04 Ben Campbell [Ballot comment]
I am an author.
2018-10-23
04 Ben Campbell [Ballot Position Update] New position, Recuse, has been recorded for Ben Campbell
2018-10-23
04 Adam Roach
[Ballot comment]

Thanks for the work everyone did on this document.

---------------------------------------------------------------------------

Title:

The RFC editor considers "SIP" to be well-known enough to no longer …
[Ballot comment]

Thanks for the work everyone did on this document.

---------------------------------------------------------------------------

Title:

The RFC editor considers "SIP" to be well-known enough to no longer require
expansion. You may want to shorten it to simply "SIP-Based Messaging with
S/MIME".

See https://www.rfc-editor.org/materials/abbrev.expansion.txt

---------------------------------------------------------------------------

§1:

>  The Open Mobile
>  Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses
>  the SIP Message Method for short "pager mode" messages and MSRP for
>  large messages and for sessions of messages.

I am a bit confused about why the RCS reference appears in this sentence.

---------------------------------------------------------------------------

§1:

>  the SIP Message Method for short "pager mode" messages and MSRP for

Nit: MESSAGE

>  these notifications are security sensitive.  For example, such

Nit: "security-sensitive"

>  S/MIME is not in common use for SIP and MSRP based messaging

Nit: "SIP- and MSRP-based"

>  and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier

Nit: remove "the" from in front of "S/MIME"


---------------------------------------------------------------------------

§4.3:

Should this section provide guidance to implementers about what to do if they
receive a message that is first encrypted and then signed as in the original
specification?

---------------------------------------------------------------------------

§7.2:

>  SIP user agents (UA) can indicate support for S/MIME by including the
>  appropriate media type or types in the SIP Accept header field in a
>  response to an OPTIONS request

This should probably mention something about the limitations of using OPTIONS in
this way due to the HERFP problem.

---------------------------------------------------------------------------

§7.3:

>  Content-Disposition header "handling" parameter of "required" return

Nit: "header field"

>  certificate.  However, it MAY return a 2XX class response if

Nit: "2XX response" or "200-class response"

---------------------------------------------------------------------------

§9.1:

>  time of this writing, CPIM compliant gateways have not been deployed.

Nit: "CPIM-compliant"

>  metadata in CPIM header fields.  For example, CPM and RCS based
>  service include application servers that may need to insert time

Nit: "services"

>  If such clients need to provide encrypt or sign CPIM metadata end-to-

Nit: s/provide//

---------------------------------------------------------------------------

§10:

>  Some SIP header fields are folded to avoid
>  overrunning the margins.  Folded lines contain leading white space at
>  the beginning of the line.  These folds would not exist in the actual
>  message.

This disclaimer seems unnecessary, given RFC 3261 §25.1:

>  SIP header field values can be folded onto multiple lines if the
>  continuation line begins with a space or horizontal tab.  All linear
>  white space, including folding, has the same semantics as SP.  A
>  recipient MAY replace any linear white space with a single SP before
>  interpreting the field value or forwarding the message downstream.

---------------------------------------------------------------------------

§12:

There are a set of recently discovered vulnerabilities in S/MIME in general
that allow exfiltation of encrypted information from S/MIME clients. One of
these is exclusively a problem with the way that clients have implemented
S/MIME, and can be addressed by taking proper steps in the clients to parse
MIME bodies prior to parsing HTML. The other one seems somewhat more tricky to
address, and is a foundational flaw in S/MIME. Both a tax require access to
the message that is going to be intercepted, so the use of hop-by-hop
encryption helps significantly. I would think that both of these deserve at
least some treatment in the security section of this document. See
https://efail.de/ for additional details.
2018-10-23
04 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-10-23
04 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4892



DETAIL
S 4.2.
>      When generating an encrypted message, sending UAs MUST follow the …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4892



DETAIL
S 4.2.
>      When generating an encrypted message, sending UAs MUST follow the
>      conventions specified in [RFC5751] for the application/pkcs7-mime
>      media type with smime-type=enveloped-data.  When decrypting a
>      received message, receiving UAs MUST follow the conventions specified
>      in [RFC5751] for the application/pkcs7-mime media type with smime-
>      type=enveloped-data.

I don't think we should be recommending encryption without integrity
at this point.
2018-10-23
04 Eric Rescorla
[Ballot comment]
S 1.
>      to implement and deploy in an interoperable fashion.

>      This document updates RFC 3261, …
[Ballot comment]
S 1.
>      to implement and deploy in an interoperable fashion.

>      This document updates RFC 3261, RFC 3428, and RFC 4975 to update the
>      cryptographic algorithm recommendations and the handling of S/MIME
>      data objects.  It updates RFC 3261 to allow S/MIME signed messages to
>      be sent without imbedded certificates in some situations.  Finally,

Nit: "embedded"


S 4.1.
>      part, and it is also is used to encrypt an encapsulated body part.

>  4.1.  Signed Messages

>      While both SIP and MSRP require support for the multipart/signed
>      format, this document recommends the use of application/pkcs7-mime

RECOMMENDS?


S 4.1.
>      format, this document recommends the use of application/pkcs7-mime
>      for most signed messages.  Experience with the use of S/MIME in
>      electronic mail has shown that multipart/signed bodies are at greater
>      risk of "helpful" tampering by intermediaries, a common cause of
>      signature validation failure.  This risk is also present for
>      messaging applications; for example, intermediaries might insert

Nit: this should be a colon, I believe.


S 4.1.

>      Sending and receiving UAs MAY support other message digest
>      algorithms.

>      Sending and receiving UAs MUST support the Elliptic Curve Digital
>      Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and

Nit: P-256.


S 4.2.
>      media type with smime-type=enveloped-data.  When decrypting a
>      received message, receiving UAs MUST follow the conventions specified
>      in [RFC5751] for the application/pkcs7-mime media type with smime-
>      type=enveloped-data.

>      Sending and receiving UAs MUST support the AES-128-CBC for content

Nit: either "the AES-128-CBC algorithm" or no "the"


S 4.3.

>  4.3.  Signed and Encrypted Messages

>      RFC 3261 section 23.2 says that when a User Agent Client (UAC) sends
>      signed and encrypted data, it should send an EnvelopedData object
>      encapsulated within a SignedData message.  That essentially says that

Technically this is a "SHOULD"


S 6.
>      MUST be able to validate a signed message.

>      End-user certificates have long been a barrier to large-scale S/MIME
>      deployment.  But since UAs can validate signatures even without local
>      certificates, the use case of organizations sending secure
>      notifications to their users becomes a sort of "low hanging fruit".

I'm not sure I agree with this, because you still need trust anchors;
this can be a real obstacle.


S 9.1.

>  9.  S/MIME Interaction with other SIP Messaging Features

>  9.1.  Common Profile for Instant Messaging

>      The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an

Is this section really necessary? I mean, can't we just say "nobody
cares about CPIM" and be done?
2018-10-23
04 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2018-10-18
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-10-18
04 Ben Campbell New version available: draft-campbell-sip-messaging-smime-04.txt
2018-10-18
04 (System) New version approved
2018-10-18
04 (System) Request for posting confirmation emailed to previous authors: Ben Campbell , Russell Housley
2018-10-18
04 Ben Campbell Uploaded new revision
2018-10-12
03 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-10-10
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-10-08
03 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2018-10-08
03 Liang Xia Request for Last Call review by SECDIR Completed: Ready. Reviewer: Liang Xia. Sent review to list.
2018-10-05
03 Amy Vezza Placed on agenda for telechat - 2018-10-25
2018-10-05
03 Alexey Melnikov Ballot has been issued
2018-10-05
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-10-05
03 Alexey Melnikov Created "Approve" ballot
2018-10-05
03 Alexey Melnikov Ballot writeup was changed
2018-09-21
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2018-09-21
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2018-09-20
03 Alexey Melnikov Changed consensus to Yes from Unknown
2018-09-13
03 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-09-13
03 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-09-13
03 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-09-13
03 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-campbell-sip-messaging-smime-03, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-campbell-sip-messaging-smime-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-09-12
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2018-09-12
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2018-09-12
03 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-09-12
03 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-10-10):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, sean+ietf@sn3rd.com, draft-campbell-sip-messaging-smime@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: …
The following Last Call announcement was sent out (ends 2018-10-10):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, sean+ietf@sn3rd.com, draft-campbell-sip-messaging-smime@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Securing Session Initiation Protocol (SIP) based Messaging with S/MIME) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'Securing Session Initiation Protocol (SIP) based
Messaging with S/MIME'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Mobile messaging applications used with the Session Initiation
  Protocol (SIP) commonly use some combination of the SIP MESSAGE
  method and the Message Session Relay Protocol (MSRP).  While these
  provide mechanisms for hop-by-hop security, neither natively provides
  end-to-end protection.  This document offers guidance on how to
  provide end-to-end authentication, integrity protection, and
  confidentiality using the Secure/Multipurpose Internet Mail
  Extensions (S/MIME).  It updates and provides clarifications for RFC
  3261
, RFC 3428, and RFC 4975.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-campbell-sip-messaging-smime/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-campbell-sip-messaging-smime/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-09-12
03 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-09-12
03 Alexey Melnikov Last call was requested
2018-09-12
03 Alexey Melnikov Last call announcement was generated
2018-09-12
03 Alexey Melnikov Ballot approval text was generated
2018-09-12
03 Alexey Melnikov Ballot writeup was generated
2018-09-12
03 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation::External Party
2018-09-11
03 Sean Turner
# 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 …
# 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.
2018-09-10
03 Sean Turner
# 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 …
# 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 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.
2018-07-30
03 Alexey Melnikov Waiting for shepherding write-up before initiating IETF LC.
2018-07-30
03 Alexey Melnikov IESG state changed to AD Evaluation::External Party from Waiting for Writeup
2018-07-30
03 Alexey Melnikov IESG state changed to Waiting for Writeup from Publication Requested
2018-07-30
03 Alexey Melnikov Assigned to Applications and Real-Time Area
2018-07-30
03 Alexey Melnikov Responsible AD changed to Alexey Melnikov
2018-07-30
03 Alexey Melnikov Intended Status changed to Proposed Standard
2018-07-30
03 Alexey Melnikov IESG process started in state Publication Requested
2018-07-30
03 Alexey Melnikov Notification list changed to Sean Turner <sean+ietf@sn3rd.com>
2018-07-30
03 Alexey Melnikov Document shepherd changed to Sean Turner
2018-07-30
03 Alexey Melnikov Stream changed to IETF from None
2018-06-25
03 Ben Campbell New version available: draft-campbell-sip-messaging-smime-03.txt
2018-06-25
03 (System) New version approved
2018-06-25
03 (System) Request for posting confirmation emailed to previous authors: Ben Campbell , Russ Housley
2018-06-25
03 Ben Campbell Uploaded new revision
2017-12-26
02 Ben Campbell New version available: draft-campbell-sip-messaging-smime-02.txt
2017-12-26
02 (System) New version approved
2017-12-26
02 (System) Request for posting confirmation emailed to previous authors: Ben Campbell , Russ Housley
2017-12-26
02 Ben Campbell Uploaded new revision
2017-11-29
01 Ben Campbell New version available: draft-campbell-sip-messaging-smime-01.txt
2017-11-29
01 (System) New version approved
2017-11-29
01 (System) Request for posting confirmation emailed to previous authors: Ben Campbell , Russ Housley
2017-11-29
01 Ben Campbell Uploaded new revision
2017-10-30
00 Ben Campbell New version available: draft-campbell-sip-messaging-smime-00.txt
2017-10-30
00 (System) New version approved
2017-10-30
00 Ben Campbell Request for posting confirmation emailed  to submitter and authors: Ben Campbell , Russ Housley
2017-10-30
00 Ben Campbell Uploaded new revision