Lamps Status PagesLimited Additional Mechanisms for PKIX and SMIME (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2016-Jul-01 —Chairs:
IETF-108 lamps minutes
Session 2020-07-28 1100-1240: Room 7 - Audio stream - lamps chatroom
LAMPS WG at Virtual IETF 108
0) Minute Taker, Jabber Scribe, Bluesheets
Rich Salz agreed to take notes.
1) Agenda Bash
2) Documents with the RFC Editor and IESG
a) draft-ietf-lamps-5480-ku-clarifications (Sean)
In RFC editor queue.
b) draft-ietf-lamps-ocsp-nonce (Mohit)
Will address AD comments and post new version soon. That version should be ready for IETF Last Call.
c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei)
In IESG Evaluation; on IESG telechat for 13 August 2020.
d) draft-ietf-lamps-cms-update-alg-id-protect (Russ)
AD review done, which only uncovered a few editorial changes. IETF Last Call started yesterday.
3) Active Working Group Documents
a) draft-ietf-lamps-cmp-updates (Hendrik)
Changes presented. Editorial updates still needed.
Private key is currently id-data (OCTET STRING); the Lightweight CMP Profile will use an Asymmetric Key Package (RFC 5958).
The ASN.1 module needs to be added, and then the document will be ready for WG Last Call.
b) draft-ietf-lamps-lightweight-cmp-profile (Hendrik, Steffen, David)
Changes presented. Still need more work on the security considerations, discussion of centralized key generation, and editorial clean up.
In addition, changes are needed to be clear what parts of RFC 6712 are being updated.
Showed details of converting SignedData content from id-data (OCTET STRING) to id-ct-KP-aKeyPackage (RFC 5958).
There was discussion of where to identify algorithms, and it was agreed that they will be put in a companion document so that it is easy to update MUST and SHOULD statements about particular algorithms without opening the protocol document.
Since this document depends upon draft-ietf-lamps-cmp-updates, so it will go to WG Last Call after that document.
c) draft-ietf-lamps-header-protection (Alexey, Bernie)
There was discussion of the extent that the selected mechanism need to accomodate MIME-compliant user agents and non-MIME-compliant user agents. This has an impact on what the recipient is likely to see rendered by their user agent. There was general agreement that the document ought to present the processing steps for a sender and separately present the processing steps for a recipient.
There was discussion of message protection profiles to be included in the document. Nested messages, gateway handling, and many other things impact the headers that are actually rendered by the recipient user agent. There was general agreement that the document ought to address two right now: (1) signed only, and (2) signed and encrypted. Once these two, which are the most common ones, are sorted out, then the WG can decide whether to include others, including triple-wrap (sign-encrypt-sign).
There was general agreement that the document ought to state what the user agent needs to be presented to the human user, but not say anything about how it is presented.
There was a request from the WG chair to keep the momentum going. Work on this document had stalled for a while. He asked the document authors to update the Internet-Draft based on today's discussion, and then start a thread on the mail list for any open issues.