*Minutes taken by Chris Lemmons, Hannes Tschofenig, and Russ Housley
https://datatracker.ietf.org/meeting/115/materials/slides-115-cose-ietf-115-cose-chair-slides-00
Mike mentioned that several RFCs have been published recently and two more are in the queue.
https://datatracker.ietf.org/doc/html/draft-housley-cose-aes-ctr-and-cbc-00
Russ presents slides explaining background. Feedback was provided on the mailing list recently regarding attacks against CBC/CTR. 3 possible ways forward:
- proceed with current approach plus enhanced security considerations
- drop CBC
- stop working on the document
Brendan Moran: Relaying some points from the list: First there was commentary that perhaps we can be more severe than "deprecated." Second, maybe there are some AEADs that do work out of order?
Michael Prorock: I believe option one should be done. I think there's a lot of value of registering deprecated becaue that encourages folks that find neat things to think twice. There might be specific use cases, but registering this can provide a stopgap as long as we're clear we aren't suggesting use.
Richard Barnes: Seconding "stronger than deprecated". Can we mark these reserved, but then define them for use only with SUIT.
Russ: It might be hard to find out what that code point means.
Richard: Have the SUIT document reference the usage.
Russ: We could say only for use with SUIT Firmware Encryption.
Goeran Selander: I'm not sure I understood the SUITs proposal. There are multiple uses for AES-CTR, though. In SIGMA we only need AES-CTR to protect against chosen plaintext attacks. I support options one and two here.
Mike: I hear preference for option 1 and 2 but not 3. With no hat, I would encourage following regular registration processes.
Hannes presents slides.
Discussion on PR9 and PR10:
Goran: You're proposing a COSE key? And they're indexed by the algorithm that creates this new format. Is that right?
Hannes: Yes, that is right. We're talking about how to encode the fields. There aren't that many fields. The question is just where should they go.
Larence Lundblade: The top level algorithm is just HPKE. This seems like a divergence because usually the top-level algorithm is the cipher suite. This is helpful so you only have to look at the top level to determine if you support it. There's good reasons not to.
Hannes: That approach didn't get a lot of support. The expectation was that the HPKE folks would register new versions and we'd reuse the existing registry. It's not clear that's a huge benefit, but that's the idea.
Michael Prorock: I support how it is written now. I have concern pointing to a secondary registry. I'm concerned because HPKE is such a special case.
Richard Barnes: A point of clarification. I'm ambivalent on the code point question; FWIW, MLS does aggregated, TLS ECH does disaggregated. Leaving the document as it is is not an option -- we need to at least change the representation of the "enc" value from COSE_Key to opaque bytes.
Hannes: Keep discussing it and we'll find a solution at the end of the day.
Joel Hoglund presends slides on CBOR Encoded X.509 Certs.
No questions.
Tobias Looker presents slides on BLS Key representations.
Mike: Do you have any questions or action items for the working group?
Tobias: Nothing beyond, "Please review the draft."
Mike: Questions from the floor?
No questions.
Mike presents slides on Claims in COSE header draft.
Mike: Is it time for WGLC?
Goran: I didn't understand the example you mentioned here. Why not use unprotected header? An example would be great.
Mike: I know there's something on the mailing list on unprotected headers. It's not clear these are the same because one is claims and one is headers.
Laurence: The answer is that if you're decoding MIME or Content-Type header and you can switch on that before you bring up the CBOR encoder so it's good.
Orie: This applies to protected and unprotected or just unprotected
Mike: There's no unprotected in COSE_Sign0. It's a fair question if we want this to appear unprotected ever. That could be a WGLC comment.
Ivaylo: We will confirm on the mailing list for WGLC, but we will take the sense of the room with a vote.
Vote: "Ready for WGLC"
Raise hand: 12
Do not raise hand: 2
Ivaylo: If folks could explain why they think we should not?
Hannes: We just raised two open issues. We need to add an example and resolve the unprotected header question. It would be good to update first. Also, CDDL. This seems premature.
Ivaylo: We will take those action items on those issues and then we can go to WGLC.
Mike: Thank you, we're at time.
Michael Prorock presents slides on COSE and JOSE registrations for PQ signatures.
Michael: Split into 3 drafts?
Quynh Dang: They might come out at different times. So it's good to have separate documents because they might be finalized by NIST at different times.
Richard: It seems obvious to get them out as soon as they algorithms are done. When NIST gets them out, we should get them out. If we can go faster by decoupling, good. Otherwise, one is fine.
Orie: I agree with splitting them up.
John Gray: We had a hackathon on the x.509 doing this. We should have a conversation because our work heavily overlaps.
Michael: Thank you, yes.
Mike: Who is doing this?
John: Mostly LAMPS. But this goes beyond that. It goes everywhere. We're discussing a PQ WG charter, but we don't know where that will go.
John: We'll continue to work at our hackathon, which is happening monthly. Send emails if you want to be invited to those.
Orie: Mike and I and others have had conversations on the key representations. If the WG wants new docs in addition to splitting these out, we can do that.
Michael: Thanks for the time and support!
Maik Riechert presents slides on the SCITT receipts.
Does this make sense? Do we need new registries?
Henk: On the receipt, that's a core element of the SCITT work. We really need this in COSE. We can do it here transparently. We'll create a stable proposal and if people are satisfied, we can ask for adoption. Not yet, but soon.
Maik presents slides on timestamp tokens.
Henk: This is a migration path solution. You don't want to use these forever. But they're the most established thing today. If we want to move to something new, that's cool. But for now, this is required for use with existing infrastructure.
No other business. We adjourn.