Skip to main content

Minutes IETF118: cose: Tue 12:00
minutes-118-cose-202311071200-00

Meeting Minutes CBOR Object Signing and Encryption (cose) WG
Date and time 2023-11-07 12:00
Title Minutes IETF118: cose: Tue 12:00
State Active
Other versions markdown
Last updated 2023-11-08

minutes-118-cose-202311071200-00

COSE IETF 118

Connection details

Action Items

  • WGLC typ-header-parameter at end of IETF unless something comes up
  • for RoMa: Put recommendations in writing.

Minutes

  • Jabber scribe:
  • Minutes taken by: Christian Amsüss, Marco Tiloca

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

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]

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]

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]

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]

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]

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]

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]

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]

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.