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 |