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.