LAMPS WG Minutes at IETF 106 in Singapore 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash We need a few minutes for draft-turner-5480-ku-clarifications. It was added to Section 4. 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-pkix-shake (Panos, Quynh) b) draft-ietf-lamps-cms-shakes (Quynh, Panos) c) draft-ietf-lamps-cms-hash-sig (Russ) d) draft-ietf-lamps-cms-mix-with-psk (Russ) None of these documents needed discussion. 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Bernie) The problem statement: Headers cannot be protected in S/MIME since version 3.1. Integrated feedback: simplified requirements for header fields not to include in clear text and added a new 'ecryption only' on receiving side. Open Issues: - We are not addressing 'encryption only' --> No comments - this should be the conclusion on this point. - Should a single format cover all protection levels. Opinions? >> DKG - if we only do signing or only do encryption we are missing something. We should not encourage people to use encrypted but not signing messages. >> Alexey - this requirement was about _not_ having multiple ways. --> So the issue is resolved; we keep the single format requirement. - To which extent are we addressing Backward Compatibility? >> Alexey - This solves two types of issues - once we make the choice on the protected header other things shall follow. >> DKG - what happens to legacy clients when they receive these messages? I think it is important we address this. --> Issue still open - Not many people have read the draft (two people) >> Alexey: What do you think we shall do with the requirement documents? >> Russ: I think the requirements are not helping us reach decisions, let's focus on providing solutions. Find the balance so that everyone is equally unhappy. - How do we deal with rendering at receiving side of "Weird artifacts"? How do we solve problems that might look like an empty messages with an attachment or attachments cannot be opened? - We can fix broken implementations instead of deploying a "work-around" (memory hole). More research needed. If we go with the work-around, we might introduce other weird artifacts (e.g., because of MIME libraries). Open Discussion: >> DKG - Three people read that draft - all headers are in the crypto message. However the legacy display part is there for legacy support (backward compatibility - not for being treated "specially" by the receiving client that does not know about the protected headers. We are looking for more feedback on this. We welcome additional contributors for the draft. >> Alexey - It seems we need to analyze the impact of the legacy displays. How difficult are both approaches for the receiving side? >> Russ - We might use a survey-monkey to get feedback... >> DKG - Maybe people can contribute with screenshot to the ML. >> Alexey - I can generate messages, and people can provide feedback to see if their client(s) crash, etc. >> DKG - The second question from Alexey is about the libraries. We want test vectors and screen shots. My question is "what is the question we are asking"? Given the messages, we want to know what legacy clients receiving them will do. >> DKG - Also we need to look into the MIME libraries issues. >> Alexey - We have 5 or 6 implementation for S/MIME. >> Sean Turner - The implementatiom report back in the day, I think, mentions 9 implementations for CMS. >> Russ - We might need 6 different of messages. How much time will it take to generate them? >> DKG - I can probably deliver on my idea by the end of the week. >> Alexey - I can probably do it next week. >> Russ - A couple of weeks is okay, but let's start --> Please sort out the logistics on the mail list Next Steps: - Close open isssues, confirm the set of requirements; reach out to to implementers. 4) Documents related to the proposed re-charter a) draft-brockhaus-lamps-lightweight-cmp-profile (Hendrik) Status: - Exchanged EncryptedValue with EncryptedKey to enable the use of EnvelopedData. - Added the support for legacy PKIs using a PKCS#10 request. - Added possibility of central generation of a key pair to the certificate request. - Completed the delayed enrollment case (async messages). - Completed the specifications for the selected set of messages. Next Steps: - Integrate the WG feedback; deriving a different secret for the key-transport mechanism (PBMParameter). Maybe also some references for doing message transport that is file-based. - Add new Key Usages in the profile with OIDs assigned by IANA. - Add security considerations and editorial changes. 4) Documents related to the proposed re-charter b) draft-brockhaus-lamps-cmp-updates (Hendrik) Status: - Add new extended key usages. - Complete the Encrypted values with regards to making use of encrypted keys and EnvelopedData. - Minor generalizations such as the removal of the reqirement that all PKI messages contained in a nested message must be of the same type. - There is no request id in "p10cr" transaction, but it is needed to open it to polling mechanism. - We need to complete the ASN.1 modules and polish the document. >> Russ - Why do you need an OID for a CA? We already have other ways to identify a CA in the certificate. >> Hendrik - You might want to sign CMP messages with a different key than the CA key. >> Sean - There is an OID for the RA in CMC, you might want to use it. 4) Documents related to the proposed re-charter c) draft-richardson-lamps-rfc7030est-clarify (Micheal) Status: - I put out the new document. - I am seeking help once the WG is re-charted to allow adoption of it. - Please read the document, especially if you have expertise on errata. 4) Documents related to the proposed re-charter d) draft-turner-5480-ku-clarifications (Sean) Status: - Section 3 of RFC 5480 is missing the description of values. - This proposed update is only one page long. - I am seeking adoption once the WG is re-charted to allow it. 4) Documents related to the proposed re-charter e) draft-housley-lamps-cms-update-alg-id-protect (Russ) Status: - We are nearly out of time, so I will skip the slides. - The proposed update adds some protection against algorithm substitution attacks. - I am seeking adoption once the WG is re-charted to allow it. 5) Other Business (if time allows) a) OCSPv2 (Max) Time is up, so this presentation was not given. However, the slides are in the proceedings.