https://datatracker.ietf.org/meeting/117/materials/slides-117-cose-cose-chair-slides
AES-CTR and AES-CBC are in RFC Editor Queue.
cwt-claims-in-headers is ready for shepherd write-up.
Mike Prorock volunteers to produce a shepherd write-up.
Russ: This is not living in a vaccuum. There are three documents in the LAMPS group, there are three documents on how to put the keys into the certificate, there are documents in the JOSE group. We want to have that the crypto libraries behind these implementations are the same. There has to be cross-collaboration.
Mike: agree the need for cross-WG collaboration
John: Is it reasonable to go for WGLC now? It makes no sense to me to do a WGLC. We have to wait till NIST finishes standardization.
Laurence: is the idea to go forward with all three algs? Why not pick one?
Mike: NIST is going with 3 algs for good reason, eg falcon is meaninful in certain constrained environments. sphics+ is a good fallback etc.
Mike: Closing remark: we need to be testing interop.
Two different procedures explained - are they different. Do they need to different header parameters? Can a parameter only go into one bucket - protected vs. unprotected.
Chair: typically a protected header is called for
Mike Prorock: one parameter is probably fine but call it out in the security considerations section
Henk: usecases are different ...
Russ: there are cases when the header has to go into the unprotected header, just explain it but use the same header type in both cases
Orie: agree with russ over being afraid of confusion
Henk: we should go for a call for adoption.
Chair calls for consensus. No-one expressed concern/opposition in the room. Confirm on list.
https://datatracker.ietf.org/meeting/117/materials/slides-117-cose-cbor-encoded-x509-second-version
Mike Ounsworth: Question: CBOR-encoded-certs is still fundamentally RFC5280 certs, just encoded in CBOR rather than DER, right? IE this is distinct from "Let's define a new cert format with a reduced set of claims and get rid of X.500 DNs, etc", right?
John: yes essentially. It is a subset of RFC 5280.
10 people in favor - none against.
Chair: adoption call on the list
Chair: encourage people to answer the call for adoption, solicit more reviews
Hannes: Deadline for responding to the call for adoption is already over.
Chairs will review the feedback.
Brendan: I have a use case for symmetric keys COSE_Key thumbprints. Please add symmetric key support.
Kohei: we should work on this
John Mattsson: I think it could make sense to send thumbprints of a CCS (CWT Claims Set) and CWT (CBOR Web Token) with cnf instead. CCS is a superset of COSE key and CWT is a superset of CCS. Agree with Brendan that supporting symmetric would be good. I think SUIT can profile away symmetric.
MikeJ. suggests to discuss this on the list.
https://datatracker.ietf.org/meeting/117/materials/slides-117-cose-cose-typ-type-header-parameter
Brendan: would counter-signatures affect the typ parameter?
Orie: good question ... move to list
... discussion ...
Russ suggests to discuss this on the list.
Carsten: The type parameter is a way for the signer to indicate what the signature means.
This adds another dimension of overloading of media type but still why don't we use media types?
Ivo suggests to discuss this on the list.
Mike: With proposal 1 is it possible to have non-sensical combinations?
Orie: it depends.
MikeO: As the author of the hybrid-composite draft in LAMPS, I got the feedback that too much flexibility for developers. In that case ciphersuite is better.
Daisuke: I have said everything on the mailing list. We should provide a comparison table of the pros & cons of the two proposals to make a real decisions. Then, a decision should be made
Carsten proposed a document yesterday on the comparison.
Jonathan Hammell: I implemented the draft and I ran into a few issues. Based on my experience I prefer proposal 2.
Tobias Looker: proposal 2 (registries) is more in keeping with how other headers in COSE have been treated. Probably will have the effect of keeping the number of HPKE combinations to a reasonable level.
Paul Wouters: What are the registry policies for adding the values?
Orie: this would be a registry reviewed by COSE experts (designated experts IANA policy)
Christopher Allen: I would dramastically reduce the number of ciphers. Proposal 2 with limits on it
Carsten: I am very much in favor of proposal 2. I believe HPKE is a product of HPKE and they designed their registry in a specific way. We need to support to what is in this registry and they need to make a decision. That's why I made a proposal to support their registry.
(support from chat on proposal 2)
Hannes: limiting the cipher suites sounds nice but in practice it is hard to do. This is a larger issue for the IETF. (still a vote for option 2)
Mike: If enc is opaque, how do you support interoperability?
Orie: The KEM has to specify it.
Carsten: I have a preference for proposal #4.
MikeO: Are we uncertain what the output is called?
Orie: We want to decide whether we should serialize the output of the HPKE to a COSE format or not.
Laurence: When I read HPKE it is written like a python API. It is not clear what is supposed to go over the wire. It is a confusing specification. I see the enc as a byte string. I am in favor of proposal #3.
Tobias: How does it remain opaque in the definition?
Jonathan Hammel: I ran into this issue too. Opaqueness depends on your crypto library.
Daisuke: I support proposal 3
Hannes: confusion is caused by how the HPKE spec is written. It doesn't specify what goes over the wire. The intention was not to specify a wire-protocol (confirmed with authors). This is a bit unfortunate and that has led to a lack of interop. Proposal 4 fixes those things.
MikeO: We only have a single example today. Opaque (proposal 3) is more future-proof.
Carsten: HPKE is a specific way to package the output and I think we should do it the way COSE expresses it. Vote for proposal #4.
Laurence: The HPKE specification is descriptive. The question is: how far into the implementation do you read to understand how the payload looks like. We have to make a call on what the top-level specification is and stick with it. Vote for proposal #3.
Chair: need to wrap this up
Laurence: (go back to slide on APIs) COSE HPKE should clarify how the HPKE APIs should be interpreted - ie a descriptive clarification of the HPKE spec.
Chair: call time on this topic. Some disagreements in the room.
Youtube video https://drive.google.com/file/d/1JGFgqlbW_fscud33gHW-x-5ptD8YtVvg/view?usp=sharing