Monday, 18 March 2024
1530 - 17:00 AEST (UTC +10)
Room P2
Notes: https://notes.ietf.org/notes-ietf-119-jose
Please check https://datatracker.ietf.org/meeting/119/agenda for updated
link to the meetecho session.
Note Taker: Orie Steele
Admin and Agenda Bash
JSON Web Proof Drafts
Fully Specified Algorithms for JOSE and COSE
https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/
Use of HPKE with JOSE
https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/
JOSE-COSE HPKE Cookbook
https://datatracker.ietf.org/doc/draft-steele-jose-cose-hpke-cookbook/
Guidance for COSE and JOSE Protocol Designers and Implementers
https://datatracker.ietf.org/doc/draft-tschofenig-jose-cose-guidance/
Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and
COSE
https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-kem/
JOSE algorithms for ECDH-MAC-based signatures
https://datatracker.ietf.org/doc/draft-bastian-jose-alg-ecdh-mac/
JSON Fine Grained Access
https://datatracker.ietf.org/doc/draft-zhang-jose-json-fine-grained-access/
AOB and Way Ahead
Mike Jones: we're covering json web proof today.
Much progress has been made since IETF 118.
Many examples now have normative statements, and text.
IANA registrations have been added for new parameters.
Proof registrations have been updated to support multiple parts.
We have addressed an ambiguity between undisclosed and zero length
values.
We aligned to BLS keys and BBS signatures, updating to the latest
versions.
We've also triaged and addressed issues and PRs.
There are several related specificatons, including BBS Signatures.
CFRG has made changes which has impacted the software we use to generate
examples in the drafts.
In COSE tomorrow, Tobias will discuss if we should add a compressed key
representations.
There is a key representation which is used in other places, which we
may wish to align to.
Please read the draft, and file issues or comment on the list.
We would like to add an algorithm other than BBS, something standards
track and having multiple interoperable implementations.
If any of you are interested in defining a representation for an
additional algorithm.... it could help.
There are a few implementations of these drafts, so we are nearing a
need to do interoperability testing.
Orie: I'd like to see an algorithm that is not based on elliptic curve
discrete log. Perhaps something based on lattices.
Mike Prorock shares: https://eprint.iacr.org/2022/284
John: our charter requires us to use algorithms that have IETF
consensus.
Mike Prorock: I shared a link in the chat, perhaps we might ask CFRG if
they are aware of others.
Mike: See our previous presentation for the "what" and "why".
There has been progress since 118, there was support for adoption, the
call for adoption was held.
There was lots of feedback, post supportive, and asking for changes or
narrowing focus.
WG draft was published, and then WG feedback was applied based on
feedback from the adoption call.
Specifically, we addressed feedback regarding "alg" and "enc" in JWE.
We talked about what fully specified should mean in this context.
We commented on key establishment and key encapsulation.
There are open questions, which were raised in last IETF and discussed
on the list.
What do do about ECDH and related algorithms (ECDH-ES...)
There has been disagreement on if we should address fully specified
ECDH.
Perhaps the WG might address replacing ECDH algorithms in a seperate
document.
Should we create fully specified algorithm identifiers for ECDH?
For example ECDH-ES for P256 for A128 KW.
Some commenters on the list, have said that we should do all of it, or
none of it.
Others suggested it would be fine to do only what people use.
There are perhaps 10 or 12 algorithms.
Mike Prorock: I think we should fully specify these algorithms, for ECDH
algorithms, I believe they should be done in a seperate document... that
can focus on ECDH, and its unique characteristics.
Filip: Brian, where did you get the 10-12 number? is that the full
cartesian, or subset.
Brian: it was the product + what made sense for strength matching... it
was napkin math.
Filip: The cartesian, 20 would be overkill... I see this now focuses on
the ones that make sense.
Brian: even 10 or 12 feels like a lot... and given the current state,
and that there don't seem to be a problem... I feel like maybe these
don't need to be fully specified.
I would be concerned in how much work this might create for little
benefit.
Chris: says in the chat, that fully specified algorithms could have
helped.
Mike: I'm happy to do the work documenting what it would look like to
try to do this... perhaps I could do it as a seperate individual
document, and the WG could then make the call on what to do.
Mike Prorock: HPKE sounds like the path forward, if it seperate, it
seems like people who are passionate can pick it up.
Mike Jones: I will write stuff down, and then ask on list.
I think this is the only open question left in the draft, once that
discussion is finished, it seems maybe ready for WG... Of course thats
up to our chairs and new AD.
Tiru: We presented the draft last time (118), and addressed comments.
We defined the 2 modes of use for JOSE.
Key Encryption and Direct Encryption.
The reason for doing this, is to align with HPKE as it is used
elsewhere, and give a path to hybrid and pq encryption.
We aligned as much as possible for COSE HPKE's 1 and 2 layer structure.
We aligned the algorithm specification with COSE HPKE (fully specified).
We leverage the APIs exposed by HPKE, including Seal and Open.
We added examples which show how HPKE can be used in JOSE.
Richard Barnes: [Thumbs up]
Mike Jones: I'm an author, but it seems its gotten a lot of attention on
list.
Chairs: We will follow up on the list.
Orie presenting without slides -- the previous presentation had
basically the examples this presentation would show.
JOSE and COSE HPKE are happening, developers might appreciate examples,
especially to highlight some subtle differences.
Filip Skokan: Value of this doc isn't the examples, it's the verified
vectors, possibly in a machine-readable format.
Mike Jones: Having the examples in RFC 7520 was invaluable in getting
JOSE implementation started.
Richard Barnes: I was confused when you call it a cookbook; if you call
it a test vector doc, great.
Brian Campbell: Cookbook shouldn't be a replacement for good examples in
the spec itself.
Orie Steele: Completely agree, but we've got two WGs to coordinate, and
partly the examples in the doc are to get them to coordinate better.
Michael Prorock: RFC 7520 is titled "Examples...", "cookbook" framing is
confusing. Can be valuable to have explanations of why things are
different between COSE and JOSE.
Mike Jones: What Matt Miller did in 7520 was create testable examples
for every algorithm. Overlapping, but different objective from spec
examples.
Yaron: Hannes presented the draft in Prague... Filip and Yaron joined.
We did a call for adoption... the feedback was mixed, our scope was
challenged, and rightly so.
Carsten gave a good review.
We plan to make updates to the draft, to address feedback.
We'll ask for adoption after addressing feedback.
Tiru: we discussed this draft on lists, TLDR, we need PQ KEMs.
The KEM interface is simple and useful.
This document is to support a migration to Hybrids and PQ KEMs.
There is discussion in other working groups on skipping to Hybrids or
not doing pure PQ KEMs.
KEMs are similar to ECDH-ES or ECDH-ES+A128KW.
We had to add a kem-ct param, instead of using a epk.
John: chair hat off... I think we should adopt all algorithms
standardized by NIST.
... its not clear if you can be compatible with CNSA and use hybrids.
... I think the overlap should be avoided where possible.
... I'm confused on how to divide drafts between JOSE and COSE.
Richard Barnes: I queed to ask about KMAC...
Tiru: We wanted to address context in the KEM, and to do strength
alignment.
Richar Barnes: Orie seems to be right... this working group does well,
when we invent the least cryptography.
... HPKE does the alignment, we should use HPKE, it addressed both
Hybrid and Pure PQ.
Michael P: I agree with Richard and Orie, its hard to keep things
aligned... HPKE is seeing traction, until we finish HPKE, we should
focus.
... keep an eye on the CRFG comments on KEMs.
... lets try to do this in one consistent way.
Chairs: not hearing momentum to adopt
Tiru: Good to wait, and see.
Paul: We want to add a new algorithm that matches a national ID card
capability, which enables EAC.
It essentially sends plaintext in a symmetric channel.
Its related to the eidas 2.0 wallet.
BSI proposed something similar for VCs.
Issuer signed credentials (traditional approach) vs authenticated
channel credentials (This draft)
This approach supports Repudiable or Deniable credentials.
The goal is to deny to a 3rd party that a transaction happened... with
ECDH + Mac, we can always argue the other party made up the plaintext,
because they share the same key.
Repudiation can easily be argued over.
The point of BSI, is that data breaches are inevitable, and
presentations will be stored, and then stolen... and that will result in
issuer signed data being stolen, and there are concerns that national ID
cards will be stolen.
If there is a data leak from the RP, they don't want the stolen data to
be signed by governments.
There are use cases where traditional signature credentials are still
recommended.
The algorithms we define are fully specified, and are built from the
curve and mac algorithm, and kdf.
Michael P: Has this been analyzed by CFRG?
Richard Barnes: Overall this pattern is not well analyzed, but ECDH+MAC
is called a "designated verifier signature"... this is used in signal
protocol.... its a widely used pattern, but not sure how much its been
analyzed.
John: Chair hat off, I agree with richard, its simple and well known,
don't think we need CRFG.
Paul: I wrote the algorithm from the draft here...
We do ECDH key agreement, but only for keys that are signed by certs.
... (see the slides for the algorithm description)
This algorithm can be used to produce JWTs.
These components are already used in JOSE.
TrustedLogic (Javacard) might be used for privacy preserving
credentials.
Its similar to an IDP flow, where the wallet sits between Issuer and RP.
A disadvantage is the the RP must provide a epk.
Richard Barnes: I think we need to call this a "designated verifier
scheme"... I am uncomfortable about mixing the JWT syntax with this
scheme... Perhaps consider Auth Mode HPKE instead?
John Bradley: Are there any time deadlines that you are facing that we
should know about?
... would you consider the HPKE alternative?
Paul: eiDas... always has time pressure.... the main purpose was to get
the ideas out... these ideas are early, and while it looks odd BSI, is
an important voice, and it should be considered.
moderate time pressure.
Brian: maybe normal HMAC algorithms work, while building the Kex and KDF
on another layer... that might be faster...
I get confused by which key is ephemeral and which is static... and how
that is layered on JOSE.
... Maybe we don't need HPKE, maybe we can use HMAC instead.
Michael Prorock: Good to align terminology, and to account for PQ
considerations for ECDH-ES.
Jinling: First time attending IETF, looking forward to presenting.
(reads slides).
Introduces a JSON object representing access control, composed on
request id, subject, object, resource operation etc...
The solution relies on JWT.
Solution introduces a new encryption algorithm CP-ABE.
John Bradley: As an individual, my observation is that this probably
fits better with the OAuth WG... Seems to be a refinemnet of a JWT.
Unless this is impacting the encryption envelope, it is probably better
to ask a protocol oriented working group.
Michael P: Agree, perhaps OAuth or GNAP.