# Minutes: LAMPS WG at IETF 116 The session was held on Wednesday, 29 March 2023 at 9:30 UTC. The minute takers were Rich Salz and John Gray. Thank you. ## 1) Agenda Bash Long agenda, luckily many documents can simply report "no new changes since last meeting". ## 2) Recently Published RFCs ### a) Announcement: draft-ietf-lamps-documentsigning-eku is now RFC 9336 ### b) Announcement: draft-ietf-lamps-5g-nftypes is now RFC 9310 No discussion. ## 3) With the IESG or the RFC Editor ### a) draft-ietf-lamps-cmp-algorithms (Hendrik, Hans, Mike, John) ### b) draft-ietf-lamps-cmp-updates (Hendrik, David, John) ### c) draft-ietf-lamps-lightweight-cmp-profile (Hendrik, Steffen, David) ### d) draft-ietf-lamps-rfc3709bis (Stefan, Russ, Trevor, Leonard) No discussion. ## 4) Active PKIX-related Documents ### a) draft-ietf-lamps-rfc4210bis (Hendrik, David, Mike, John) All changes from draft-ietf-lamps-cmp-updates have been incorporated. KEM support has been added as well. Current version supports HPKE (see RFC 9180), but the authors are moving towards draft-ietf-lamps-cms-kemri becauses it is more straight forward. No feedback offered at this time. Russ: requests that the KEM section get a lot of review since this part is very new. ### b) draft-ietf-lamps-rfc6712bis (Hendrik, David, Mike, John) Internet-Draft more or less complete. No changes since IETF 115. ### c) draft-ietf-lamps-pkcs12-pbmac1 (Hubert) No update. ### d) draft-ietf-lamps-rfc7030-csrattrs (Michael) No update. ### e) draft-ietf-lamps-key-attestation-ext (Carl, Sean) No update. ### f) draft-ietf-lamps-dilithium-certificates (Jake, Panos, Sean, Bas) No update. ### g) draft-ietf-lamps-kyber-certificates (Sean, Panos, Jake, Bas) Internet-Draft emphasizes that Kyber public keys will appear in encryption certificates, and not appropriate for use in TLS 1.3. Public keys were wrapped in ASN.1 OCTET STRING; however, other public keys do not have such a wrapper, want to remove it. Want to include private key format too. Deb: Not having a wrapper is fine, the simpler the better. Mike: Do you have an opinion on draft-uni-qsckeys-kyber? Sean: No opinion at this point... But there is no ASN.1 structure in our document, just an OCTET STRING. So, our document is simpler. Roman: Can we move quickly to avoid having other groups doing something incompatible? Sean: We're waiting for NIST to assign OIDs, but otherwise this is almost done. John: Join the hackathon team, which is using placeholder OIDs. Sean: Apparently Kyber might be renamed when it is published by NIST. ### h) draft-becker-guthrie-cert-binding-for-multi-auth (Alie, Rebecca, Mike) Document was recently adopted by the LAMPS WG, then some changes regarding the language. A few open questions were listed in the [slides](https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-draft-ietf-lamps-cert-binding-for-multi-auth-00). Authors want to know if they should generalize. That is, if one is getting a new certificate, do we want the general capability of the new one referring to the old one? Russ: Look at OCSP (see RFC 6960) for an ASN.1 structure to reference a certificate. Sean: Don't generalize it. Doing so will cause more work, just solve the problem you're trying to solve. ## 5) Active S/MIME-related Documents ### a) draft-ietf-lamps-header-protection (DKG, Alexey, Bernie) Going to ask for WG Last Call, so now is the time to read and review. [Slides](https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-header-protection-for-cryptographically-protected-e-mail-01) list the most recent changes. Future work: User agen implementers need to think about how protected headers are displayed to users. Alexander: it takes time to do usability right; it makes sense to keep it out of the RFC. DKG: I agree completely. John: If user agents need a new Header Confidentiality Policy (HCP), how will they document it? Will there be a registry? DKG: Expecting the people that need a new HCP to create Internet-Drafts, but if needed a registry could be created. Alexander: Similar to last quesiton about registry. Russ: Suggestion: if this becomes popular, then a registry can be created, but wait until the first Internet-Draft is written for a new HCP. ### b) draft-ietf-lamps-e2e-mail-guidance (DKG) Note that header-protection Internet-Draft refers to this one; however, don't want that to become a MISSREF and block. Seeking feedback from mail user agent implementers. Document lists a number of proposals for consideration. [Slides](https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-end-to-end-e-mail-guidance-00) include outstanding questions. Russ: Pointed out that S/MIME RFC 8551 has advice in the area of multiple recipients, especially in the area of BCC. Rich: Please repeat concepts that cause blockage? DKG: Cryptographic envelopes and payload. MIME is super flexible; take existing message and envelope it. If you get anything outside the envelope, something is fishy. Header protection includes a copy of headers in the payload. Rich: Can you just point to the S/MIME documents? DKG: S/MIME documents are often not taken seriously. Rich: This is more about the practises of doing this in a useful fashion. DKG: Yes Rich: Your suggested way forward makes sense. Sean: Great way forward (slides 4 and 5), mark guidance section as non-normative. Haiguang: What happens if user changes secret key? DKG: Good question, there are ways to handle this, but the current document doesn't address this. Haiguant: Maybe draft could offer suggestions. Users don't handle secret keys; the user agent does. DKG: Document has some text, but I welcome your suggestions. Remember that this is for implementors, not users, please give feedback. Deb: We have record management requirements; how do you handle that? DKG: How do you handle it now? Deb: We decrypt, and then store the message separately. DKG: Please contribute text. ### c) draft-ietf-lamps-caa-issuemail (Corey) [Slides](https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-ietf-116-draft-ietf-lamps-caa-issuemail-01) provide background and rational. This Internet-Draft was recently adopted by the LAMPS WG. The document is ready for WG Last Call. Russ: Any concerns about this going to WG Last Call? No response. Russ: We will do WG Last Call in a few weeks. ### d) draft-ietf-lamps-cms-kyber (Julien) This Internet-Draft now makes use of draft-ietf-lamps-cms-kemri. Mike: The IETF should be consistent on which KDFs we use with Kyber. Russ: Concerned about the last KDF (HKDF-SHA512 or NULL) at the bottom of slide 2. See [slides](https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-draft-ietf-lamps-cms-kyber-00-00). Julien: Should we remove it? Russ: Please raise it on the mailing list so that we hear from everyone before NULL is removed. ### e) draft-ietf-lamps-cms-sphincs-plus (Russ, Scott, Panos, Bas) No update. ### f) draft-ietf-lamps-cms-kemri (John Grey) The authors believe that the KEMRecipientInfo structure works for all KEMs; draft-housley-lamps-rfc5990bis shows it works for RSA-KEM. Four Internet-Drafts are already using KEMRecipientInfo, and we have interoperable running code examples. Please review. Hendrik: Did you think of adding an ephemeral key for forward-secrecy? Mike: Does CMS do forward secrecy? Isn't being able to decrypt later a property of CMS? Russ: Yes and no. Example of Static-Static Diffie-Hellman where a UKM is used to avoid the same key-encryption key for different messages. Jonathan: Please add base64 content to the samples in the Internet-Draft. Russ: I think the examples belong in documents that specify the conventions for a particular KEM, like draft-housley-lamps-rfc5990bis. I'll be glad to add the Base64 there. Tim: This document is pretty much done, but has a lot of cryptography, so we will give it time to get more eyes on it. ## 6) Under consideration for adoption ### a) draft-ounsworth-pq-composite-keys (Mike, Max) Many changes; see [slides](https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-ounsworth-composite-00). Worked with OpenPGP WG on some areas. ### b) draft-ounsworth-pq-composite-sigs (Mike, Max) ### c) draft-ounsworth-pq-composite-kem (Mike, Max) Max Pala presented a K-of-N (draft-pala-klaussner-composite-kofn) and a way to revoke one algorithm used in a composite. Sean: Is the CRL extension for revocation critical or non-critical? Paul Hoffman: CRL extension for revocation of an algorithm should be in a separate Internet-Draft, please don't rush this piece. Max: Agree, we can put it in a separate Internet-Draft. Dean: Question on list of explicits, hash functions. Mike: It is all SHA-3. DKG: Can you have generic OID with the generic OID? Mike: No recursion, explictly not allowed. DKG: Question about generic combiner: cost is vetted implementation? Mike: If working group wants generic removed, we can remove it. DKG: What is timeframe of algorithm deprecation? Max: This is for long-lived certificates? DKG: Algorithm deprecation should go hand in hand with software updates. We need to think more about deprecation. Yoav: I don't see the utility of the algorithm revocation. Max: It may depend on use cases. Russ: I would like to see email discussion on the "generic" composite algorithms. Paul: Sequencing of other Internet-Drafts is important; Russ agrees. Haiguang: Don't object to adoption, but voiced concerned about both specific and generic being specified. ### d) draft-housley-rfc5990bis (Sean) Goal is to align with the new KEMRecipientInfo as specified in draft-ietf-lamps-cms-kemri. Mike: Made a comment about kema-rsa-kem on the mailing list, but might now be able to retract it. Russ: Call for adoption is underway; need Mike to reply on the mailing list soon. ### e) draft-reddy-lamps-jose-eku (Tirumal) Want EKU identifiers for COSE. 3GPP is motivation; goal is to avoid potential for misuse within 5G network functions. Russ: Could use two EKU values (one for JSON and one for CBOR) in combination with the keyUsage bits. The alternative it to define four EKU values. Email uses first approach. My personal preference is to use the first approach here too. Tiru: We will update the document to do that. Russ: We'll do an call for adoption once the update is posted. ***Out of time. Unable to cover the rest of the agenda.*** ### f) draft-ounsworth-pkix-key-attestation (Mike) ### g) short IBM presentation on PQC (Michael Obsorne) ### h) draft-bonnell-rfc5019bis (Corey) ## 7) Wrap up