Skip to main content

S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)
draft-ietf-jmap-smime-12

Revision differences

Document history

Date Rev. By Action
2022-04-04
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-03-03
12 (System) RFC Editor state changed to AUTH48
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):

From: The IESG
To: IETF-Announce
CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, superuser@gmail.com …
The following Last Call announcement was sent out (ends 2021-10-18):

From: The IESG
To: IETF-Announce
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:
Subject: Last Call:  (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'
  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):

From: The IESG
To: IETF-Announce
CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, superuser@gmail.com …
The following Last Call announcement was sent out (ends 2021-09-06):

From: The IESG
To: IETF-Announce
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:
Subject: Last Call:  (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'
  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
2019-07-08
00 Alexey Melnikov Uploaded new revision