LAMPS WG Agenda at IETF 114 -- 27 July 2022 at 10:00 EDT 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) With the IESG or the RFC Editor a) draft-ietf-lamps-documentsigning-eku (Tadahiko, Tomofumi, Sean) b) draft-mtis-lamps-8410-ku-clarifications (Sean, Simon, Daniel, Tadahiko) c) draft-ietf-lamps-cmp-algorithms (Hendrik, Hans, Mike, John) d) draft-ietf-lamps-cmp-updates (Hendrik, David) e) draft-ietf-lamps-lightweight-cmp-profile (Hendrik, Steffen, David) 3) Active PKIX-related Documents a) draft-ietf-lamps-rfc3709bis (Stefan, Russ, Trevor, Leonard) 4) Active S/MIME-related Documents a) draft-ietf-lamps-header-protection (DKG, Alexey, Bernie) b) draft-ietf-lamps-e2e-mail-guidance (DKG) 5) Under consideration for adoption a) draft-richardson-lamps-rfc7030-csrattrs (Michael) b) draft-housley-lamps-5g-nftypes (Russ, Sean, John, Daniel) c) draft-wallace-lamps-key-attestation-ext (Carl, Sean) d) draft-turner-lamps-nist-pqc-kem-certificates (Sean, Panos, Jake, Bas) e) draft-massimo-lamps-pq-sig-certificates (Jake, Panos, Sean, Bas) f) draft-perret-prat-lamps-cms-pq-kem (Ludovic, Julien, Mike) g) draft-ounsworth-pq-composite-keys (Mike, Max, Jan) h) draft-ounsworth-pq-composite-sigs (Mike, Max) i) draft-becker-guthrie-cert-binding-for-multi-auth (Alie, Rebecca, Mike) j) draft-uni-qsckeys (Christine, Silvio, Basil, Tamas, Michael, Dieter, Joppe) k) draft-kario-pkcs12-pbmac1 (Hubert) 6) Wrap up Document signing: CMP Algorithms: passed IESG review ready for publication CMP updates: addressed IESG and AD comments, ready for publication LW CMP profile: updated, waiting for AD review. IESG requested RFC4210bis and RFC6712bis: Opens the scope of change to the entire document. Russ: this is a document the protocol not redesign the protocol effort. The original authors have to give the rights to update the document (this is possibly already done?). 3709 bis: consensus has been called. Header protection: DKG reported that there is a subtlety that has to be addressed. DKG says he has the action to complete. End to End Mail guidance: DKG is waiting for review/suggestions. He's looking for contributers and lesson sharing. Russ and Alexi have agreed to review. Alexi reported that he had reviewed an earlier draft, and that terminology might need to be aligned. He will read again. CSR Attributes (draft-richardson-lamps-rfc7030-csrattrs): There were issues in the original draft and in the RFC, but that has all been corrected. Insert ASN.1 here.... the goal was to fix the ASN.1 without breaking what is in use today. Sean asked for adoption. Roy Williams @ Microsoft asked if UTF8 was going to be required. Russ/MCR answered that the field was a choice where UTF8 was chosen. The authors asked for Roy Williams @ Microsoft to provide an example that was not UTF8. X509 Cert Extension for 5G Network Function Types (NFTypes) (draft-housley-lamps-5g-nftypes): Sean Turner. Simple draft on how to put 3GPP NFTypes in certificates, to support 3GPP. NFTypes are all ASCII strings, listed in a 3GPP spec. Decision is to define a new extension NFTypes which is a sequence of NFType objects. Asking for WG Adoption. Russ Housley: NFTypes define in 3GPP specs are all 8 characters or less, have 4x that for safety. John Mattsson: this is already done in a bad way in 3GPP, don't think it's been discussed there. Sean: If 3GPP want to do it themselves then that's fine. John: Next step is to get 3GPP agreement and discussion. Rich Salz: Support adoption. TimH: Seems like most are in favour of adoption. They will take it to the list. Key attestation: Carl Wallace (CW). Draft defines key attestation extension. Uses WebAuthn Attestation Statement Format. Would like adoption. Thomas Fossati: Are you creating IANA registry in your draft? CW: That's the plan. TF: Will you coordinate with W3C? CW: Don't think that's necessary. Stefan Santesson: There is overlap with ETSI mechanism in qualified certificate statements extension, want to make you aware there's a widely deployed function. (Link - https://www.etsi.org/deliver/etsi\_en/319400\_319499/31941205/02.03.01\_60/en\_31941205v020301p.pdf) CW: WebAuthn format is also widely deployed. Monty Wiseman: Simple binary of hardware and software is going to be hard for people to use. Appraiser will need more information than a bit. CW: Can you post this to the mailing list? Sean Turner: Worried we'll refer to SCEP and downref it and it'll become standards track. Flagging to ADs. Leif Johansson: Relying parties don't have a lot of experience in processing WebAuthn format. Refers to NIST 800-63 and Vectors of Trust. Advise taking a look at what's been used in digital identity industry as alternative or addition to WebAuthn. Maybe define something that can encompass WebAuthn and other things. Don't pick winners. Michael Richardson: Have read draft. Does LAMPS want to fight RATS for it? CW: No RATS in this draft. Russ: This points to attestation formats that are already defined, if it was defining a new one it might be for RATS. Russ: Any objections to adoption? No objections, will take it to the list. PQ KEM Certs (draft-turner-lamps-kyber-certs): NIST only chose one KEM. Draft will specify Kyber public/private key format, get OID from NIST and not include parameters. Instead alg (OID) identifiers will specify parameters. Sec considerations will point to algorithm specs. John Mattsson: How will OIDs work for security levels? Sean: One OID per security level. JM: Does NIST want our input? ST: We're not trying to usurp NIST, will go with their decisions. Roman: Charter says we take what NIST do. Mike Ounsworth: Key Usage isn't straightforward. KeyTrans and KeyAgree are both wrong, but we don't want a new EKU. We just need to agree. Sean: Think we agreed on KeyTrans, will make sure it's consistent. Paul Wouters: Please don't name anything with a dash or space because that's awful for people who code in C. Sean: Asking for adoption. No one opposed to call for adoption, will go to list. Mike Ounsworth: For PQ stuff can we adopt, do the work, and then pause to wait for NIST? Sean: That's exactly what we're doing. PQ Signature Certs (draft-massimo-lamps-pq-sig-certificates): Jake Massimo. Signature version of the above. Aimed at "pure" PQ certs, not hybrid. Interest from industry who need long-term root of trust that's difficult to re-issue. NIST has announced they will standardize Dilithium, SPHINCS+, Falcon. This draft will define data structures for use of quantum-safe Dilithium, OIDs will come from NIST. Key discussion points: how many algs per draft? Suggest one. Which security levels to include? John Gray: Support this. John Mattsson: Support this. LAMPS should do everything NIST standardise. On OIDs, for LMS we have one OID for all security levels, are we saying that was wrong? Russ Housley: Algorithm spec for LMS is different, in LMS the key encodes the parameters. Doesn't seem that'll be the case for PQC signatures. Orie Steele: Support this. Russ: One draft for all algorithms or one per algorithm? Sean: Separate drafts for algorithms. John Gray: Separate. Orie Steele: Separate. Roman: Personal opinion - separate, AD hat - will support consensus. Poll: 41 in favour of splitting algorithms into separate drafts, 1 for having them together. Will have call for adoption for a Dilithium draft. Composite keys: Admits that there might be an argument that hybrid isn't required. The author thinks that there should be a standardized way to do hybrid independent from the algorithm specifications for the community that requires it. The author is asking for adoption for both the composite keys and composite sigs drafts. There is a new composite kem draft. DKG commented that these allow a wide range of choices and why the is the flexability necessary. The author talked about OIDs and the options for those. ST brought up the ECC integrations where there were too many choices. The author's plan is to going participate in the hackathon. Composite vs non-composite: the author argued they were complementary, and they both might be necessary. Jonathan Hammell: Would like to keep the combiner modes (OR, KofN mode) separate, this draft should just include the AND mode. DKG: I think this should be adopted. I agree we should just have the AND mode in this draft. Mike Ounsworth: There are use cases for OR now. Every time I take it out I get pushback. Viktor Dukhovni: How does this play into TLSA records? Mike Ounsworth: Is this different from RSA which can be used with a number of different signing algorithms? Viktor: In TLS you negotiate signing algorithm on the wire. Discussion goes to list. Deb Cooley: Who do you envisage as the users of these things? I don't see large PKIs using these tools. Mike Ounsworth: I don't have an answer I can say publicly. We do have customers. John Gray: We expect some changes based on what happens on the mailing list. Think customers would appreciate this. Roy Williams: Building this and hoping somebody comes to it is a non-goal. Need someone who says they want to use this. Russ Housley: Does anyone object to a call for adoption on composite keys. TimH: Uri Blumenthal objects in chat. Russ: Will discuss further on list. Russ: Call for adoption on composite sigs? Jonathan Hammell: If the plan is to significantly change from what it is now I object. Russ: At least one person against adoption in chat. Composite-KEM: Brand new. Contains two things that need crypto review 1. Transforms to treat everything as a KEM. 2. Cominers to combine multiple component shared secrets. Please review. Related certificates for use in multiple authentications: Rebecca Guthrie. -01 version uploaded in June. Changes from -00 draft: Title of document changed, added section with use case, narrowed scope of document to two certificate case. Have made changes to relatedCertRequest Attribute including changing signature to include the requestTime (concatenated with certID). RelatedCertificate Extension now includes hash of entire certificate rather than just certID. Is the time just a nonce? Rebecca: Included to prevent reuse. Russ: Any objections to adoption? No objections so there will be a call for adoption. QSC key ID and serialization: Mike Osborne briefed. This draft is about key storage issues wrt PQ keys. Asking for adoption. Russ: Concerned that the direction you're taking is different from the direction we've decided on. We can't get ahead of NIST so the way this is structured we can't publish this until NIST has standardised all algorithms. Mike: Happy to split this into four documents. Michael Richardson: This document contains private key formats for PKCS8. There might be a lot of commonality between documents. Do we need to repeat ourselves? Russ: They're different enough, we need to repeat. Sean Turner: I have private key format in my draft, so we need to decide where this ends up. In the past having choices didn't help with adoption.