Skip to main content

Minutes IETF117: cose

Meeting Minutes CBOR Object Signing and Encryption (cose) WG
Date and time 2023-07-24 20:00
Title Minutes IETF117: cose
State Active
Other versions markdown
Last updated 2023-08-18



Connection details

Action Items


  • Jabber scribe:
  • Minutes taken by: Hannes, Leif

Opening remarks - the chairs [13:00-13:05]

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.

Post-Quantum Signatures draft-ietf-cose-{dilithium,sphincs,falcon} - Mike Prorock and Orie Steele [13:05-13:20]

  • Mike presents goals and status of the sig mechs coming out of the NIST work
  • Mike summarizes of some of the differences between classical and PQC mechanisms
  • Mike summarizes key updates to the drafts
  • Mike notes that some common implementations have known errors - caveat emptor
  • Chair notes that post-WGLC the specs will be held until the NIST process completes

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.

draft-birkholz-cose-tsa-tst-header-parameter - Henk Birkholz [13:20-13:30]

  • Henk talks about the use of time-stamps and the tsa-tst parameter

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.

draft-ietf-cose-cbor-encoded-cert (10 minutes) - Göran Selander or John Mattsson [13:30-13:40]

  • John Mattsson presents status
  • CRL and OCSP will be broken out into separate I-D
  • Summary of ongoing discssuions and issues (cf slides)

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.

draft-steele-cose-merkle-tree-proofs - Orie Steele [13:40-13:50]

  • Orie presents status on CoMETRE I-D
  • This is a part of the SCITT WG
  • Encodes the RFC 9162 inclusion and consistency proofs in CBOR/COSE.
  • There is a demo available at
  • There is another merkle tree algorithm already being proposed (in addition to the proofs provided by RFC 9162), namely based on the Confidential Computing Framework (CCF).
  • call for adoption?

10 people in favor - none against.

Chair: adoption call on the list

draft-birkholz-cose-cometre-ccf-profile - Henk Birkholz [13:50-14:00]

draft-isobe-cose-key-thumbprint - Kohei Isobe [14:00-14:10]

  • Kohei presents status of COSE_Key thumbprint I-D
  • propose WG adoption
  • close to WGLC - no open issues

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.

draft-jones-cose-typ-header-parameter (10 minutes) - Orie Steele and Mike Jones [14:10-14:20]

  • Orie presents "typ" (type) header parameter I-D status
  • (Mike steps away as chair for this part since he is a co-author)
  • Orie calls for more reviewers and possible WG adoption

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.

COSE-HPKE - Orie Steele/Hannes Tschofenig [14:20-14:50]

  • Orie present summary of HPKE I-D
  • there are fundamental design issues on the table - should HPKE rely on a COSE registry for parameters or should those parameters be directly included in the alg header

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)

  • Orie presents on the encoding of "enc"
  • Proposal 3: "enc" is opaque bound to alg+kem
  • Proposal 4: "enc" is a COSE key (or JWK)

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.

  • Orie: need consensus-call on list

Chair: need to wrap this up

  • Hannes presenting on issues related to HPKE "modes". Should COSE-HPKE implement all other modes?
  • Next issue: what should be included in the KDF?
  • Please see issue tracker on github for several open issues

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.

draft-demarco-cose-header-federation-trust-chain (5 minutes) - Giuseppe de Marco [14:50-14:55]

Youtube video

AOB (5 minutes) [14:55-15:00]