# COSE IETF 118 {#cose-ietf-118} # Connection details {#connection-details} * Date: Nov 7, 2023 * Meeting materials: https://datatracker.ietf.org/meeting/118/session/cose * Recording: https://youtu.be/MJVl-4lry3I?si=r3nvm2Q0lMh3UBLJ&t=26 # Action Items {#action-items} * WGLC typ-header-parameter at end of IETF unless something comes up * for RoMa: Put recommendations in writing. # Minutes {#minutes} * Jabber scribe: * Minutes taken by: Christian Amsüss, Marco Tiloca ## Opening remarks - the chairs \[13:00-13:10\] {#opening-remarks---the-chairs-1300-1310} https://datatracker.ietf.org/doc/slides-118-cose-chair-slides/ IP doing introductions. IP (p7, p8): Status, see slides. IP (p9): Agenda. ## draft-ietf-cose-typ-header-parameter-00 \[13:10-13:15\] {#draft-ietf-cose-typ-header-parameter-00-1310-1315} MJ presenting not-as-chair. MJ (p2): Lost in history why the JOSE parameter was not added originally. MJ (p3): Motivation. Secured statement of what a thing is, so it can be rejected (i.e. security reasons) MJ (p4): Got feedback, got adoption, No further feedback until a few days ago. (Slide error: s/Entity Type/Content Type/). CB: I still have some wording changes to propose on the PR out there, but that's fine during WGLC. MJ: "CWT claims in headers" uses this, so that also may need this. MJ (p5): WGLC time? IP: Start at end of IETF when no further comments come in. ## draft-ietf-cose-key-thumbprint-04 \[13:15-13:20\] {#draft-ietf-cose-key-thumbprint-04-1315-1320} KI presenting. KI (p3): Symmetric Keys has been requested in IETF117. Have relevant security considerations. KI (p4): New confirmation method 'ckt' for 'cnf' claim also registered. KI (p5): URI proposed by Orie (?). Using NI registry and not COSE. KI (p7): Ready? CB: Intrigued by parameters (???). Confusion b/c talks about oauth. Might be mistaken for "designed for OAuth", may influence implementers' choice. Get more COSE wording? (Cursed of text based representations … people read them) KI: Try to fix it. CA: Using the NI or COSE registry came up in CBOR registry. The former seems to be not well maintained. Can you elaborate on your choice? CB (on chat): +1 to CA KI: Is not binary. Numbers not good for human user. If binary, would go with COSE identifier. CA: It makes implementations harder and needing to handle two different registries. KI: What if we choose from the COSE registry then? Would it be a good improvement? CA: Not sure, let's take it offline. MJ (not as Chair): Thumbprint made choices from JWK thumbprint. There is OAuth registry, fine to reuse it. Also got much feedback there to use IANA hash algorithms registry, so that's what we did there. Don't think changes are needed. CB: (Mike's argument is good, but think mine is better). Here it'd be -16. It's already very long, -16 is shorter. KI: Discussed on mailing list. ## draft-ietf-cose-cbor-encoded-cert-07 \[13:20-13:30\] {#draft-ietf-cose-cbor-encoded-cert-07-1320-1330} GS presenting. GS (p1): Will have questions for WG in here. GS (p2): Should look familiar to X509 except Type (is the original X509 / reconstructed signed or the literal C509?) GS (p3): Example of c509 from drip-dki GS (p4): Recent work influenced by DRIP, LAKE (non-signature PoP provides compact MAC instead of large signature; slightly confusing but OK to have non-signature thing in signature registry) GS (p5): More processed input. GS (p5): WG, what do we need with separate draft on revocation that was split out? CB: When splitting a document in WG, can just do that and can decide whether it's WG doc or individual, depending on maturity as decided by chairs. RM: The one thing this needs is code to actually convert DER-C509 to show it. Team or others helping the team need to get code. Python kind of thing. JG: Have you done any comparison on what you gain? GS: What is being compressed is neither signature nor key. JG: So used for legacy stuff, not worried about post-quantum? RM: Saving 130 bytes on those won't matter much. GS: Multiply by chain. GS (p6): CSR could also be in different ways. Proposal: Only standardize those two that make sense. CB: GS (p7): Remaining to be fixed this year. Rust code only does X509->C509 so far, and not up to latest spec. RM: Have draft (...ecc-pki?) with code for 802.1AR examples. Can look at that, work together for good examples. GS: Example already has HTT consulting, pro'ly yours :-) GS: After that, WGLC? MJ: Please give me heads-up when thinking a draft is done. ## draft-ietf-cose-hpke-07 \[13:30-14:00\] {#draft-ietf-cose-hpke-07-1330-1400} LL presenting. LL (p1): team work presentation, but team has conflict. LL (p2): Once more, authors changed LL (p3): what was indicated indicated by 3 integers in the a-la-carte approach is now reflected in the name of the value of the alg field in the COSE header, according to the ciphersuite approach. LL (p4): Open items. Not planning to have a new key representation. DA (p5, continuing presentation): One of the major remaining issues are ciphersuites. Switched as per p3 away from alacarte. 16 in current draft, can be reduced. Most problematic: Specs for CP and X25519Kyber are not yet RFCs. The drafts could still be updated. RoMa: Community that's interested in ChaCha is generally not interested in NIST curve. So some lines can probably go out. Guess what you tried to say with the CP KEMs is to allow later registration once they're RFCs? DA: Not standardized, so hold off the cipher suites. RoMa: Please put recommendations in writing on list. Now in: https://mailarchive.ietf.org/arch/msg/cose/FonvRdlMFuY4\_yo-ZFjpVqtlvlY/ CB: I suggested a way to avoid list. Everything from registry toolkit applies. Anything missing is not a disaster. Not sure of policy, but DEs will be welcoming to missing gaps. CB: Also, we can do early allocations. Once CP starts to standardize, let's help them and give them code points. Decision of which repr to use for your cryptographic items should not be "where do I get the registration most quickly". Knowing conflict with other (even own) views: try to not register garbage. If something has security properties, not register. Make it easy to get something in, and make it not a desaster. MJ: On list, Stephen Farell agreed with you. DA: CP and X..Kyber are not RFCs yet. Premature to include here. DA (p6): ??. Prefer A or B, slightly B, like to move forwaard with that. Can expand after RFC publication. MJ: Procedurally, you can have normative refs to drafts, which delays publication to when those are published. CB (on chat): we can have early allocation for those codepoints LL (p8): What's different is that algorithm is contain scipher suites. it's like key use restrictions (?). LL (p9): outlook; the next version would fix remaining issues and add examples and test vectors; then WGLC. ## draft-tschofenig-jose-cose-guidance-00 \[14:00-14:10\] {#draft-tschofenig-jose-cose-guidance-00-1400-1410} LL presenting on behalf of HT. LL (p1): Early proposal. BCP for implementers. LL (p3): Possible abuse case. Large set of choices. LL (p5): Way forward? Gather feedback to process as it comes; engage with implementors. (some thumbs up from room) IP: Please comment on list. ## draft-ra-cose-hybrid-encrypt-02 \[14:10-14:20\] {#draft-ra-cose-hybrid-encrypt-02-1410-1420} AB presenting. AB (p1): Early draft. AB (p3): Concatenate+Hash approach from >=2 secrets. >=1 needs to be secure. AB (p4): General definitions, everyone aware anyway. AB (p5): Term "Hybrid" is ambitious (??) AB (p6): Context specific string AB (p7): ? AB (p8): Parts visualized. AB (p10): Beware of "hybrid" term, used differently in different contexts. AB (p11): Comments? RH: Concerned to end up where 1 library can't support what LAMPS, COSE and JOSE produce. Want to end up where 1 library can do that. On p10, hope authors are talking. In LAMPS, discussed composite KEMs, combining 2 KEMs. People: "really easy, but look at combinatorial explosion". Thus, focus on some -- let's focus on the same. JH: On p9. You have HKDF in there. Is intention to do hybrid HKDFs? AB: We had to pass the DH secret through a KDF as it was not uniform. JH: Why not use HKDF for construction as well, so it's aligned? AB: From Kyber perspective it's already done. RH: Also uses same KDF. JH: Will discuss on list. MO: Orange HKDF looks weird. Where does that come from? AB: Probably got it from original cose 9053 draft. TRK: Orange is existing and already there. New is the PQC part. ?: "" RB: FWIW, KMAC is a valid KDF. Documents are being updated to make that official. Sponge function already does what is needed. So use KMAC throughout. RH(?): Or use KDF throughout. ## draft-lemmons-composite-claims-01 \[14:20-14:30\] {#draft-lemmons-composite-claims-01-1420-1430} CL presenting. CL(p2): Problem statement. CL(p2): Think we need some new CWT claims. CL(p3): Logic claims -- AND, OR, NOR. CL(p4): Envelopes b/c claim might get logged somewhere. CL(p5): Tools to combine those. Some uses may not require knowledge of all claims. Almost everything else in the ecosystem has crit, but it's not defined as actual claim. CL(p6): Could do Expert Review, but Generic enough they could be useful. Shouldn't each use own building blocks. CB: As Designated Expert for many registries, each registry should come with a Dispatch Working Group (maybe not even a WG but a RG should be started sometimes). CB: This is good stuff. Can only stay that if it is kept small. At some level, you will get Turing equivalence. But you can delay that; find Pareto optimal 80%, which is best found in forum for discussion. Bring it to the WG. CL: No Loop claim ;-) RoMa: bearer? CL: Doesn't need to be bearer token RoMa: It's 2023. No more encouraging of bearer tokens. Also, no binding in here. Should include binding so can't copy paste claims. TM: Wondering about the encrypted chunks. Considered work around selective disclosure? Especially about not necessarily disclosing length of claims. Encrypting still exposes length. CL: Sorry, have to pad. TM: Also seems like duplicate work. CL: In selective disclosure, holder selects, and holder knows. In this paradigm here, issuer is the decider on what gets disclosed. Thus, can't use same component. Right, you're exposing length w/o padding. If all bearer tokens get issued have 9-digit account IDs, you're fine. If all have addresses, can tell country unless protocol level has padding to hide that info. MJ (not as Chair): Conversation in hackathon room. This is building blocks for general authorization languages. Wouldn't call it claims. Many ppl working in this space, see also new WG. Policy operators are ...? CL: Agree for envelope. But logical operators are acceptable (?) based on contents like all other claims. Super valuable statement. MJ: The WG was in OpenID foundation, with ppl with background in compact representation, some XML. AuthZen at openid.net. CB: Please look at XML and don't do it again. JG: No expert in COSE ... mentioned nesting. Nesting in arbitrary depth is worrying for parsers. CL: Needs language on "protocols that use the claims need to tell you nesting requirements and limits". CL: So, next step is apply feedback and ask for adoption. ## AOB \[14:30-15:00\] {#aob-1430-1500} IP: AOB? RN: Not sure if out-of-scope; on weekend talked about post-quantum key establishment. Talked about hybrid Kyber(?) stuff. Orie proposed COSE representation of Kyber that was discarded. My question: Who will represent KEM of Kyber. Do you want to work on expressing PQ KEM in CBOR? MJ: Start by talking with Orie; sadly right now in conflicting session. RN: Will do. * * * *[AB]: Aritra Banerjee *[CL]: Chris Lemmons *[CA]: Christian Amsüss *[CB]: Carsten Bormann *[DA]: Daisuke Ajitomi *[GS]: Göran Selander *[HT]: Hannes Tschofenig *[IP]: Ivaylo Petrov *[JG]: John Gray *[JH]: Jonathan Hammell *[KI]: Kohei Isobe *[LL]: Laurence Lundblade *[MT]: Marco Tiloca *[MJ]: Michael Jones *[MO]: Mike Ounsworth *[RM]: Robert Moskowitz *[RN]: Renzo Navas *[RoMa]: Rohan Mahy *[RH]: Russ Housley *[TRK]: Tirumaleswar Reddy K *[TM]: Tristan Miller