Skip to main content

Minutes IETF111: cose

Meeting Minutes CBOR Object Signing and Encryption (cose) WG
Date and time 2021-07-28 21:30
Title Minutes IETF111: cose
State Active
Other versions markdown
Last updated 2021-09-14


COSE @ IETF 111 (Virtual)

Meeting details

Date: Monday, 18 July 2021
Time: 07:30 - 08:30 UTC
- Ivaylo Petrov
- Matthew Miller
- Mike Jones

Area Director:
- Benjamin Kaduk

Minute Taker(s):
- Christian Amsüss
- Carsten Bormann
Jabber Scribe:
- Carsten Bormann

Action items:
- [Chairs]: Check countersign
- [Ivaylo]: handle x509 questions that are still open or find people to help with that.
- [Mike Jones]: countersign next steps?


  1. Administrivia – The Chairs

MJ going through agenda etc.

  1. Document Status – The Chairs

MJ listing status, see chair slides.

Russ Housley: With countersign, we finished WGLC, just waiting for chairs to push publish button.
MJ taking that up after meeting.
RH: If not, please point to unresolved comments.
CB: Who is shepherding?

  1. draft-ietf-cose-x509 – Ivaylo Petrov

IP presenting, see slides.

BK[?] will check open PRs.
IP (p2, "Some short additional text on what cose-x509 is protecting people from"): Anyone around with appropriate knowledge to write the additional text?

[ no volunteers ]

  1. draft-ietf-cose-cbor-encoded-cert – The Editors

John Preuß Mattsson presenting, see slides. (Quick; recap from previous interims)

CB: John provided me with the chains of p9. Applied cbor-packed out of curiosity; uncovered bug in cbor-packed which is not yet fixed, so maybe showing this on Friday in CBOR meeting.

  1. Introduction of draft-denhartog-pairing-curves-jose-cose – Kyle Den Hartog

KDH not in the room; MJ powerpoint-karaoke'ing.

Who heard of "pairing friendly curves"? (5 on chat) Used for zero-knowledge proofs, some used in decentralized identity world. Currently no COSE/JOSE registration for these curves.

(p4) Key encoding? Representations are around for compressed curves; not advocating but probably what author is about.

BK on prohibited status: Bn256G[12] correspond to subgroups. In general, good to have identifiers. Codepoints are not particularly scarce. Comments or other notes can say that they are not expected for signatures or that like, but in other protocol elements. So registering and prohibiting seems to make sense.

Jonathan Hammell: They were believed to have 128bit security, but by attack reduced to 100bit. Have been well-deployed, but now efforts to define new, more secure Bn curves.


CB: What we need to discuss is the point encoding. There are references to SEC1 -- do we want it to be used like that, or more like OKP? Haven't read IRTF draft this is based on, that's stuck on shepherd, so have to ask Stanislav.

BK: The question on OKP encoding ties it to next item. General sense I got was that OKP will be preferred if there's no reason to prefer SEC1. So question to Kyle: Are there existing deployments with strong SEC1 encoding, so we don't do things inconsistently just for the sake of doing it that way?

  1. Discussion of criteria for registering additional algorithms – Working Group

MJ: How should we think about when it makes sense to adopt draft about new curves and algorithms? (Open mike, not here to drive but to listen.)

(showing slides)

Brendan Moran: Big argument to register some PKC algorithms. Certainly once NIST competition finishes. Also stateful hash-based algorithms. So should take a role in registering these.
MJ: Nature of the competition, outcomes?
BM: Am no expert on that; there's competition for key agreement and signing. Fits in where we use ephemeral static ECDH, would probably want something in similar space. Likewise, algorithms for signing. Obviously, one already put through on topic of stateful hash based signing, that's already registered. In the same vein, once that finishes, should be prepared to register algorithms for winners of NIST competitions.

Göran Selander: Chiming in as designated expert for some COSE code points. Were happy with Jim Schaad being around as eager to provide input about registration request. Now looking at patterns in RFC8152(?) etc; it's not always clear how registrations should be made. Jim knew JOSE and PKIX assignments (eg. truncations). There are rules -- what's bundled with what, key type indicates curve. Also exceptions. If we want to change a lot, we have to do that carefully, or create a mess. Probably needs larger effort than WG meeting. In particular, need to be careful with short identifiers.

Carsten Bormann: Just because NIST competition is complete doesn't mean we can act on it immediately. Needs time to write up standards compatible description of what they have. On GS's point: We need to address this, should write document that explains the guidelines we're using, will at some point become BCP but it's important to write it up so it's not just lore. (strong support from BK via Jabber). How would a registrant know when we prefer OKP? Need document for this BCP information.
MJ: In JOSE, we wanted to register things we'd assume would be used. Designated experts want to see that there's been public cryptographic analysis of safety and effectiveness. I'm novice in pairing friendly curve space and need to defer to CFRG. But we don't want to make experimentation hard either by not having common algorithm.

Brendan: You mentioned indication of analysis / review. What do we do about independent submissions that register an identifier? Those may appear to outsider to have these properties, but they were not in regular stream so they haven't had that.
MJ: Our registries have a field for documents in which the analysis has been done. Without evidence, the registration is not accepted.

JPM: Current "recommended" column can be yes or no. Maybe that's too little / good to have more flexibility and information. (Similar discussion in TLS group, early conclusion there is that it's not enough).
MJ: Indeed, JOSE has more granularity now.

BK: GS' and CB's points were good; write it down for people who ask for registrations. Hoping for CB to help writing this in draft. Looking forward to seeing that, it's within charter. Should have that as milestone.

  1. AOB

Request to discuss rats-uccs draft.

Henk Birkholz: Is there a question?
Carsten: Say what it is? A CWT is by definition always protected by an armor. Sometimes you want to exchange unarmored, unprotected data structures containing CWT data. Technically trivial, but needs to be written up, and also needs security considerations. And they're not CWTs and can't be used like them. You can use them on secure channels, and to talk about things usually transported in CWTs.
Henk: Jim did not like this.... It's null cipher.
Carsten: It's not. It's not looking like a CWT, can't be confused.
Henk: Jim: "It's like a CWT with a null cipher". JWTs with a null cipher are much worse. But there's a definition in CWT that defines claim sets. We want to keep the guarantees associated with CWTs, and that is, here, provided in conveyance method and provides the same guarantees as CWTs. Unfortunately, that's application specific. So the channel needs to be set up in some way, and comes with burdens. So you can't just define UCCS as a claim set encased in CWT and done, you have to always provide a security consideration specific to usage scenario. But at the core, it's an unprotected claim set.
CB: Core is it's unprotected. Rest is speculative on security properties a channel would need to have to get the same properties as in a CWT. It's unfortunate that both are in same document, but that's where we are.
MJ from floor: OpenID connect uses ? set in a flow. They're sent as bare claims, using the JWT claims, but only protected by TLS.
Henk: Please add as examples.
Henk: ...
MJ: Certainly a relevant topic.