S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)
RFC 9219
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-04-05
|
12 | (System) | Received changes through RFC Editor sync (created alias RFC 9219, changed title to 'S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)', … Received changes through RFC Editor sync (created alias RFC 9219, changed title to 'S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)', changed abstract to 'This document specifies an extension to "The JSON Meta Application Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status.', changed pages to 10, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-04-05, changed IESG state to RFC Published) |
|
2022-04-05
|
12 | (System) | RFC published |
|
2022-04-04
|
12 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9219">AUTH48-DONE</a> from AUTH48 |
|
2022-03-03
|
12 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9219">AUTH48</a> |
|
2022-01-28
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2022-01-28
|
12 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
|
2022-01-28
|
12 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Shaun Cooley was marked no-response |
|
2022-01-27
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2022-01-27
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2022-01-27
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2022-01-27
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2022-01-27
|
12 | (System) | IANA Action state changed to In Progress from On Hold |
|
2022-01-21
|
12 | (System) | IANA Action state changed to On Hold from In Progress |
|
2022-01-20
|
12 | (System) | RFC Editor state changed to EDIT |
|
2022-01-20
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2022-01-20
|
12 | (System) | Announcement was received by RFC Editor |
|
2022-01-20
|
12 | (System) | IANA Action state changed to In Progress |
|
2022-01-20
|
12 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2022-01-20
|
12 | Cindy Morgan | IESG has approved the document |
|
2022-01-20
|
12 | Cindy Morgan | Closed "Approve" ballot |
|
2022-01-20
|
12 | Cindy Morgan | Ballot approval text was generated |
|
2022-01-20
|
12 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2022-01-06
|
12 | (System) | Removed all action holders (IESG state changed) |
|
2022-01-06
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2022-01-06
|
12 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-12.txt |
|
2022-01-06
|
12 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2022-01-06
|
12 | Alexey Melnikov | Uploaded new revision |
|
2021-12-06
|
11 | (System) | Changed action holders to Alexey Melnikov (IESG state changed) |
|
2021-12-06
|
11 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
|
2021-11-18
|
11 | (System) | Removed all action holders (IESG state changed) |
|
2021-11-18
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-11-18
|
11 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-11.txt |
|
2021-11-18
|
11 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-11-18
|
11 | Alexey Melnikov | Uploaded new revision |
|
2021-11-09
|
10 | (System) | Changed action holders to Alexey Melnikov (IESG state changed) |
|
2021-11-09
|
10 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
|
2021-10-22
|
10 | (System) | Removed all action holders (IESG state changed) |
|
2021-10-22
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-10-22
|
10 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-10.txt |
|
2021-10-22
|
10 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-10-22
|
10 | Alexey Melnikov | Uploaded new revision |
|
2021-10-21
|
09 | (System) | Changed action holders to Alexey Melnikov (IESG state changed) |
|
2021-10-21
|
09 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2021-10-21
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2021-10-20
|
09 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
|
2021-10-20
|
09 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Kirsty Paine for the ART ART review, and thank you Alexey for … [Ballot comment] Thank you for the work on this document. Many thanks to Kirsty Paine for the ART ART review, and thank you Alexey for addressing Kirsty's comments. I have one non-DISCUSS question to which I'd really like an answer nonetheless. Given the following text: [RFC8551] and [RFC8550]. Possible string values of the property are listed below. Servers MAY return other values not defined below, as defined in extensions to this document. Would it make sense to define an IANA registry for the allowed values, to guarantee interoperability of implementations? Francesca |
|
2021-10-20
|
09 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
|
2021-10-20
|
09 | Robert Wilton | [Ballot comment] Hi, I have to confess that I don't know IMAP, and hence my question may have an obvious answer, but it is unclear … [Ballot comment] Hi, I have to confess that I don't know IMAP, and hence my question may have an obvious answer, but it is unclear to me whether a server supporting the smimeverify capability implies that it SHOULD also support checking the S/MIME signature at delivery time? If this is the case, should this be clarified, perhaps in section 3? I.e., section 3 states: Servers supporting _this_ specification MUST add a property called "urn:ietf:params:jmap:smimeverify" to the capabilities object. E.g., section 4.1 states: signed: S/MIME signed message, but the signature was not yet verified. Some servers might not attempt to verify a signature until a particular message is requested by the client. JMAP servers compliant with this document SHOULD return "signed/ verified" or "signed/failed" instead of this signature status. These two statements seem to imply that a server returning the smimeverify capability SHOULD also support checking the S/MIME signature at delivery because they SHOULD either return signed/verified or signed/failed for a request for smimeStatusAtDelivery, which at least implies that they have previously checked the signature when it was delivered. Is that was is intended? Thanks, Rob |
|
2021-10-20
|
09 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2021-10-20
|
09 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2021-10-19
|
09 | Warren Kumari | [Ballot comment] Thanks to Menachem Dodge for the OpsDir review; I see that the author has incorporated / addressed many of the comments/nits, but I … [Ballot comment] Thanks to Menachem Dodge for the OpsDir review; I see that the author has incorporated / addressed many of the comments/nits, but I don't think I saw any sort of discussion around the "Please consider whether the document header should indicate "Updates: 8621"." (which Benjamin also referenced). It is entirely possible that I completely missed any discussions, but I'd be interested in an answer if possible. |
|
2021-10-19
|
09 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
|
2021-10-19
|
09 | Benjamin Kaduk | [Ballot comment] Are we asserting that the "smime" prefix for property names (and "hasSmime", etc.) relates only to S/MIME signing? How might S/MIME encryption be … [Ballot comment] Are we asserting that the "smime" prefix for property names (and "hasSmime", etc.) relates only to S/MIME signing? How might S/MIME encryption be handled if support is added in the future? I see that the opsdir reviewer asked about whether this document should have an "Updates:" relationship with RFC 8621. I'm not sure I see a need for it, myself, but would be interested in hearing the stance of the authors/WG. Section 4.1 signed: S/MIME signed message, but the signature was not yet verified. Some servers might not attempt to verify a signature until a particular message is requested by the client. JMAP servers compliant with this document SHOULD return "signed/ verified" or "signed/failed" instead of this signature status. I'd suggest adding something like "SHOULD attempt verification and return", just to reiterate that servers don't get to arbitrarily claim verification/failure without doing the verification. smimeErrors: "String[]|null". null signifies that the message doesn't contain any signature or that there were no errors when verifying the S/MIME signature. (I.e., this property is non null only when the corresponding "smimeStatus" response property value is "signed/ failed".) [...] Would some hypothetical future smimeStatus type be compatible with a non-null smimeErrors? This phrasing seems to preclude such a possibility. This might result in the following response: [["Email/get", { "accountId": "abc", "state": "41234123231", I note that this "state" value is used in RFC 8621 when retriving a similar example message. As far as I recall this state value represents only the state of Email objects on the server overall (with some caveat about visibility to the user), and so it is not inherently inconsistent to use the same value across examples ... but it might be worth picking a new value anyway. The reuse of the message "id" for a message with a different "receivedAt" date, subject, etc., though, seems less defensible than reusing "state". Example 2: Retrieval of minimal information about a message, [...] ["Email/get", { "ids": [ "af123u123" ], "properties": [ "mailboxIds", "from", "subject", "date", "smimeStatus", "smimeErrors", "smimeVerifiedAt" ] }, "#1"] Is reusing the method call id allowed? Section 4.2 * *hasVerifiedSmime*: "Boolean". If "hasVerifiedSmime" has the value true, only messages with "smimeStatus" equal to "signed/ verified" match the condition. If "hasVerifiedSmime" has the value false, only messages with "smimeStatus" not equal to "signed/verified" (including the value null) match the condition. Might some future status value (say, "signed+encrypted/verified") also need to match as "verified S/MIME"? This phrasing seems to preclude such a possibility. Section 6 The immutability of smimeStatusAtDelivery might have unfortunate interactions with trust anchor changes (additions, mostly) on the server, since the state could be locked into invalid even if the current TA set would have verified it at the time of delivery. Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. [...] I think the client also trusts the channel between client and server, as well as the server itself. This is perhaps implicit in trusting the server, especially when combined with the JMAP requirement for secure transport, but might still be worth reiterating, as a divergence from the purely local S/MIME verification mode that is the alternative to this document's mechanism. Furthermore, I think it is worth clearly stating that trusting the server in this way also expands the attack surface -- when this mechanism is used, the server can be attacked (undetectably by the client) and return bogus S/MIME verification state, whereas local verification would have returned correct results. So the client is not just trusting the code and configuration of the server, but also its operational practices. Roman's text looks like a reasonable way of covering the last two points. NITS Section 1 This extension is suitable for cases where reduction in network bandwidth and client side code complexity outweigh security concerns about trusting JMAP server to perform S/MIME signature verifications. [...] "the JMAP server". Section 6 Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. [...] "the server-side [...] extension". |
|
2021-10-19
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2021-10-19
|
09 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
|
2021-10-18
|
09 | Roman Danyliw | [Ballot comment] ** Section 4.1. Recommend sticking to verification practices by citation when defining the semantics of “smimeStatus” OLD signed/verified: S/MIME signed message and the … [Ballot comment] ** Section 4.1. Recommend sticking to verification practices by citation when defining the semantics of “smimeStatus” OLD signed/verified: S/MIME signed message and the sender's signature was successfully verified, the sender matches the From header field, and the sender's certificate (and the certificate chain) is trusted for signing. signed/failed: S/MIME signed message, but the signature failed to verify. NEW signed/verified: S/MIME signed message and the sender's signature was successfully verified per the verification process in [RFC8551] and [RFC8550]. signed/failed: S/MIME signed message, but the signature failed to verify per the processes in [RFC8551] and [RFC8550]. ** Section 6. Recommend being more explicit with the trust model. OLD Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. NEW Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. A malicious or compromised server could return false verification status to a client. A successful verification could be conveyed to a client for a forged or altered message. A properly signed message could be signaled as having a failed signature verification or no signature at all. In the case of the latter attack, no new attack surface is presented with this extension above what malicious or compromised server could already do by stripping or tampering with the S/MIME information in the message. In the case of the former attack, client software capable of performing S/MIME signature verification could detect this attack. Local configuration of the client should determine if this client-side verification should occur. For clients without local verification capabilities, such an attack would be difficult to detect. |
|
2021-10-18
|
09 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
|
2021-10-17
|
09 | Erik Kline | [Ballot comment] Just some random questions that came to mind... [S4.2, question] * Is there any benefit to/reason to consider some boolean like "hasVerifiedAtDeliverySmime"? … [Ballot comment] Just some random questions that came to mind... [S4.2, question] * Is there any benefit to/reason to consider some boolean like "hasVerifiedAtDeliverySmime"? [S5, question] * In section 4.1, the values of smimeStatus are defined as ... Possible string values of the property are listed below. Servers MAY return other values not defined below, as defined in extensions to this document. If the intention is that documents that update this document are the the way to create new possible values, should this imply the establishment of a registry of these values? But perhaps this level of process is not desired. |
|
2021-10-17
|
09 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2021-10-17
|
09 | Peter Yee | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. |
|
2021-10-15
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2021-10-15
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-jmap-smime-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-jmap-smime-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the JMAP Capabilities registry on the JSON Meta Application Protocol (JMAP) registry page located at: https://www.iana.org/assignments/jmap/ a new registration will be made as follows: Capability Name: urn:ietf:params:jmap:smimeverify Intended Use: common Change Controller: IETF Security and Privacy Considerations: [ RFC-to-be; Section 6 ] Reference: [ RFC-to-be ] The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
|
2021-10-13
|
09 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
|
2021-10-11
|
09 | Lars Eggert | [Ballot comment] Section 6. , paragraph 3, comment: > Constant recalculation of S/MIME signature status can result in a > Denial-of-Service condition. For … [Ballot comment] Section 6. , paragraph 3, comment: > Constant recalculation of S/MIME signature status can result in a > Denial-of-Service condition. For that reason, it is RECOMMENDED to > cache results of signature verification for 10 minutes. Agree with the motivation to cache, but 10 minutes seems pretty arbitrary. Could a sentence be added giving a bit of context? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 4.1. , paragraph 13, nit: > ignature. (I.e., this property is non null only when the corresponding "smime > ^^^^^^^^ This expression is usually spelled with a hyphen. Section 4.1. , paragraph 13, nit: > Each string in the array is a human readable description (in the language sp > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 4.1. , paragraph 14, nit: > (See Section 3.8 of [RFC8620] in regards to how this is affected by the lan > ^^^^^^^^^^^^^ Use "in regard to", "with regard to", or more simply "regarding". Section 4.1. , paragraph 15, nit: > s response property to be set to a non null value, if an S/MIME signature exi > ^^^^^^^^ This expression is usually spelled with a hyphen. |
|
2021-10-11
|
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2021-10-11
|
09 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Bron Gondwana for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric -- Section 4.1 -- I cannot parse the sentence below, probably because of missing quotes or punctuation: smimeStatus: "String|null". null signifies that the message doesn't Suggest to replace with smimeStatus: "String|null". A smimeStatus value of "null" signifies that the message doesn't -- Section 6 -- Just wondering about the cache for 10 minutes only... The amount of information to be stored seems very little so the signature status should be kept until the trust anchors are modified. |
|
2021-10-11
|
09 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2021-10-07
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
|
2021-10-07
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
|
2021-10-07
|
09 | Cindy Morgan | Placed on agenda for telechat - 2021-10-21 |
|
2021-10-07
|
09 | Murray Kucherawy | [Ballot comment] Thank you to Kirsty Paine for her ARTART review. I suggest changing "spec" to "specification" or "document" in the Abstract. |
|
2021-10-07
|
09 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
|
2021-10-07
|
09 | Murray Kucherawy | Ballot has been issued |
|
2021-10-07
|
09 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
|
2021-10-07
|
09 | Murray Kucherawy | Created "Approve" ballot |
|
2021-10-07
|
09 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2021-10-07
|
09 | Murray Kucherawy | Ballot writeup was changed |
|
2021-10-07
|
09 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
|
2021-10-04
|
09 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-10-18):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, … The following Last Call announcement was sent out (ends 2021-10-18):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-jmap-smime-09.txt> (S/MIME signature verification extension to JMAP) to Proposed Standard The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'S/MIME signature verification extension to JMAP' <draft-ietf-jmap-smime-09.txt> 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 last-call@ietf.org mailing lists by 2021-10-18. 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 This document specifies an extension to JMAP for Mail (RFC 8621) for returning S/MIME signature verification status. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ No IPR declarations have been submitted directly on this I-D. |
|
2021-10-04
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2021-10-04
|
09 | Amy Vezza | Last call announcement was generated |
|
2021-10-04
|
09 | Murray Kucherawy | Last call was requested |
|
2021-10-04
|
09 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-10-04
|
09 | Murray Kucherawy | IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup |
|
2021-09-30
|
09 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-09.txt |
|
2021-09-30
|
09 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-09-30
|
09 | Alexey Melnikov | Uploaded new revision |
|
2021-09-22
|
08 | Murray Kucherawy | Changed action holders to Alexey Melnikov |
|
2021-09-22
|
08 | Murray Kucherawy | Awaiting response to ARTART review. |
|
2021-09-22
|
08 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for Writeup |
|
2021-09-22
|
08 | Kirsty Paine | Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Kirsty Paine. Sent review to list. |
|
2021-09-10
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2021-09-10
|
08 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-08.txt |
|
2021-09-10
|
08 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-09-10
|
08 | Alexey Melnikov | Uploaded new revision |
|
2021-09-07
|
07 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
|
2021-09-07
|
07 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
|
2021-09-07
|
07 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. |
|
2021-09-06
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2021-09-02
|
07 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
|
2021-09-02
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2021-09-02
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-jmap-smime-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-jmap-smime-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the JMAP Capabilities registry on the JSON Meta Application Protocol (JMAP) registry page located at: https://www.iana.org/assignments/jmap/ a new registration will be made as follows: Capability Name: urn:ietf:params:jmap:smimeverify Intended Use: common Change Controller: IETF Security and Privacy Considerations: [ RFC-to-be; Section 6 ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
|
2021-09-01
|
07 | Menachem Dodge | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Menachem Dodge. Sent review to list. |
|
2021-08-30
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
|
2021-08-30
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
|
2021-08-29
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
|
2021-08-29
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
|
2021-08-29
|
07 | Francis Dupont | Assignment of request for Last Call review by GENART to Francis Dupont was rejected |
|
2021-08-26
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
|
2021-08-26
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
|
2021-08-26
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shaun Cooley |
|
2021-08-26
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shaun Cooley |
|
2021-08-24
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Kirsty Paine |
|
2021-08-24
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Kirsty Paine |
|
2021-08-23
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2021-08-23
|
07 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-09-06):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, … The following Last Call announcement was sent out (ends 2021-09-06):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-jmap-smime-07.txt> (S/MIME signature verification extension to JMAP) to Proposed Standard The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'S/MIME signature verification extension to JMAP' <draft-ietf-jmap-smime-07.txt> 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 last-call@ietf.org mailing lists by 2021-09-04. 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 This document specifies an extension to JMAP for returning S/MIME signature verification status. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ No IPR declarations have been submitted directly on this I-D. |
|
2021-08-23
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2021-08-21
|
07 | Murray Kucherawy | Last call was requested |
|
2021-08-21
|
07 | Murray Kucherawy | Ballot approval text was generated |
|
2021-08-21
|
07 | Murray Kucherawy | Ballot writeup was generated |
|
2021-08-21
|
07 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation |
|
2021-08-21
|
07 | Murray Kucherawy | Last call announcement was generated |
|
2021-08-21
|
07 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-08-21
|
07 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
|
2021-08-19
|
07 | Bron Gondwana | Document Shepherd Write-Up for draft-ietf-jmap-smime 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC8621). … Document Shepherd Write-Up for draft-ietf-jmap-smime 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC8621). The request type is indicated in the title page header as "Standards Track". 2. Technical Summary This spec extends the JMAP Mail Protocol (RFC8621) with a way to obtain information about S/MIME signature verification status. Working Group Summary This document originally included both the verification and the creation of S/MIME signatures, but was split into two documents and this one is just the verification part. The main discussion was around cached validation status and being able to know if the server successfully validated the message in the past once a key has expired. There was also discussion about whether there was any point in describing what specifically caused validation to fail, or just a simple yes/no on validity. This document was discussed in multiple IETF sessions, as well as on the mailing list, and everybody was happy with the end result. Document Quality This spec is easy to implement for a server which already validates S/MIME. It can either store information or always calculate in real-time. It uses the standard JMAP extension mechanism to add new data items to the existing Email object, so will be familiar to anybody who has implemented JMAP. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Murray Kucherawy 3. The Document Shepherd has read the document through in detail. 4. There are no concerns about reviews, this document has been well reviewed. 5. There is no review required for the document by other areas. 6. There are no concerns with this document that IESG should be aware of. 7. Yes, the author has been contacted and confirmed and confirmed that they have no disclosures. 8. There have been no IPR disclosures filed. 9. The WG consensus is solid. 10. There has been no discontent. 11. The ID nits tool complains of one line which is overly long, which can be easily fixed in editing. It's inside an JSON example. 12. This document doesn't define anything which needs formal review outside the working group. 13. All references have been identified as normative. 14. All normative references are published standards. 15. There are no downreferences. 16. This RFC does not change the status of any other RFC. 17. The IANA considerations ask for a single entry in the JMAP capability registry, and the registration completely specifies the fields for that registry. 18. There are no new registries created. 19. There are no ABNF sections. The JSON examples were validated with the `jq` tool. |
|
2021-08-19
|
07 | Bron Gondwana | Responsible AD changed to Murray Kucherawy |
|
2021-08-19
|
07 | Bron Gondwana | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
|
2021-08-19
|
07 | Bron Gondwana | IESG state changed to Publication Requested from I-D Exists |
|
2021-08-19
|
07 | Bron Gondwana | IESG process started in state Publication Requested |
|
2021-08-19
|
07 | Bron Gondwana | Document Shepherd Write-Up for draft-ietf-jmap-smime 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC8621). … Document Shepherd Write-Up for draft-ietf-jmap-smime 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC8621). The request type is indicated in the title page header as "Standards Track". 2. Technical Summary This spec extends the JMAP Mail Protocol (RFC8621) with a way to obtain information about S/MIME signature verification status. Working Group Summary This document originally included both the verification and the creation of S/MIME signatures, but was split into two documents and this one is just the verification part. The main discussion was around cached validation status and being able to know if the server successfully validated the message in the past once a key has expired. There was also discussion about whether there was any point in describing what specifically caused validation to fail, or just a simple yes/no on validity. This document was discussed in multiple IETF sessions, as well as on the mailing list, and everybody was happy with the end result. Document Quality This spec is easy to implement for a server which already validates S/MIME. It can either store information or always calculate in real-time. It uses the standard JMAP extension mechanism to add new data items to the existing Email object, so will be familiar to anybody who has implemented JMAP. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Murray Kucherawy 3. The Document Shepherd has read the document through in detail. 4. There are no concerns about reviews, this document has been well reviewed. 5. There is no review required for the document by other areas. 6. There are no concerns with this document that IESG should be aware of. 7. Yes, the author has been contacted and confirmed and confirmed that they have no disclosures. 8. There have been no IPR disclosures filed. 9. The WG consensus is solid. 10. There has been no discontent. 11. The ID nits tool complains of one line which is overly long, which can be easily fixed in editing. It's inside an JSON example. 12. This document doesn't define anything which needs formal review outside the working group. 13. All references have been identified as normative. 14. All normative references are published standards. 15. There are no downreferences. 16. This RFC does not change the status of any other RFC. 17. The IANA considerations ask for a single entry in the JMAP capability registry, and the registration completely specifies the fields for that registry. 18. There are no new registries created. 19. There are no ABNF sections. The JSON examples were validated with the `jq` tool. |
|
2021-07-26
|
07 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-07.txt |
|
2021-07-26
|
07 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-07-26
|
07 | Alexey Melnikov | Uploaded new revision |
|
2021-07-26
|
06 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-06.txt |
|
2021-07-26
|
06 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-07-26
|
06 | Alexey Melnikov | Uploaded new revision |
|
2021-07-12
|
05 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-05.txt |
|
2021-07-12
|
05 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-07-12
|
05 | Alexey Melnikov | Uploaded new revision |
|
2021-07-12
|
04 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-04.txt |
|
2021-07-12
|
04 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-07-12
|
04 | Alexey Melnikov | Uploaded new revision |
|
2021-03-17
|
03 | Bron Gondwana | IETF WG state changed to In WG Last Call from WG Document |
|
2021-03-17
|
03 | Bron Gondwana | Notification list changed to brong@fastmailteam.com because the document shepherd was set |
|
2021-03-17
|
03 | Bron Gondwana | Document shepherd changed to Bron Gondwana |
|
2021-03-12
|
03 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-03.txt |
|
2021-03-12
|
03 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-03-12
|
03 | Alexey Melnikov | Uploaded new revision |
|
2021-01-03
|
02 | (System) | Document has expired |
|
2020-07-02
|
02 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-02.txt |
|
2020-07-02
|
02 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2020-07-02
|
02 | Alexey Melnikov | Uploaded new revision |
|
2020-02-10
|
01 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-01.txt |
|
2020-02-10
|
01 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2020-02-10
|
01 | Alexey Melnikov | Uploaded new revision |
|
2020-01-09
|
00 | (System) | Document has expired |
|
2019-11-21
|
00 | Bron Gondwana | Changed consensus to Yes from Unknown |
|
2019-11-21
|
00 | Bron Gondwana | Intended Status changed to Proposed Standard from None |
|
2019-07-08
|
00 | Alexey Melnikov | New version available: draft-ietf-jmap-smime-00.txt |
|
2019-07-08
|
00 | (System) | New version approved |
|
2019-07-08
|
00 | Alexey Melnikov | Request for posting confirmation emailed to submitter and authors: Alexey Melnikov <Alexey.Melnikov@isode.com>, Alexey Melnikov <alexey.melnikov@isode.com> |
|
2019-07-08
|
00 | Alexey Melnikov | Uploaded new revision |