Friday, 10 November 2023
Berlin 1/2; 15:30 - 17:00 CET (UTC+1)
Samuel Schlesinger
Mike Ounsworth
Hannes Tchofenig (HT)
* JSON Web Proofs https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
* JSON Proof Algorithms https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-algorithms/
* JSON Proof Token https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-token/
Presenting: Mike Jones (MJ)
ACTION: JOSE WG will need to review CFRG BBS -05, once published. Mike
Jones will send a reminder to the JOSE mail list when it's time.
Hannes Tschofenig (HT): I saw a gigantic list of open issues, is that
corret?
MJ: Yes, that's correct, I need to work through them with my co-authors.
HT: You mentioned a related COSE document; SCITT also wants the CBOR
version of this
MJ: we have not yet written CBOR versions. The JSON version is easier,
so we wanted to do that first.
HT: In CFRG the BBS draft keeps changing. Is it stable enough to use
here?
MJ: My understanding is that the BBS proof primitives are stable, but
it's a fair question.
Samuel ?? (Google): Advertisement: Google has been working on Bullet
Proofs.
Orie: When the work was initially chartered there were different
constructions being discussed. Some of those are accomplished by batch
issuing, selective disclosure. Other technologies have been proposed,
such as U-Prove. I don't know the status of the work.
MJ: What is the use case of Google.
Samuel: Cannot disclose. It is similar to PrivacyPass. Passing low
entropy data between contexts which can't have any tracking ID between
them.
MJ: If you want to contribute, you know where to find us.
David Waite: Working on BBS, the latest version contains a core protocol
and some signing. It leaves the door open for predicate proofs, creating
pseudonmous identifiers, etc. There is something we definitely want,
such as predicate proofs. We have to work on this. Feel free to reach
out to me.
John Bradley: BBS has been segmented in CFRG - the first part is being
completed. The second part is the blinded BBS. For the VC use case
presentable unlinkable proofs to multiple verifiers has JWP taken into
account the additional things that are needed for the blinded BBS.
Mike: Not yet. We need to put this in our queue. When I had the side
conversations with the implementer, he confirmed that there are
implementations for the blinded signatures.
John: Being able to support the VC use cases would be very fundamental.
David: The next draft of BBS is changing the proof. For the next version
I hope they don't have to change the ciphersuite. The blinded signature will become an extension and we have to find
out how to support extensions.
Brian: I suggest we focus on the container formats for the new types of
cryptography rather than using legacy algorithm. It just makes the
document more complex.
Kristina Yasuda: +1 to Brian. Majority of the examples use P256.
Focusing the draft on modern crypto like BBS and Bulletproofs is needed
and a really good idea.
Mike: Timeframe of the draft is dependent on the CFRG.
David: When draft -05 of BBS gets published then this draft will get
updated.
ACTION: Brian to start a discussion on-list.
John Preuß Mattsson: I think JWP need to wait for CFRG even if it
unstable. We should work with CFRG to process the parts of
draft-irtf-cfrg-bbs-signatures that is needed for JWP.
* https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/
Filip Skokan: You are currently only registering the base mode.
Tiru: Yes. You could register other ciphersuites and modes later.
Filip: I learned about this today and I started implementing it. I am
working on a cook-book for JOSE.
Tiru: I am happy to work with you.
Yaron: You don't have any test vectors. Is this TBD?
Tiru: We are working on an implementation and there will be test
vectors.
Brian: Can you explain why the encapsulated key has been pulled out into
a header?
Orie: HPKE has two formats: a one-shot message, and a two-shot that
looks like ECDHE-ES. We would hope that HPKEs look similar to
traditional JWE, but building an envelop on top of HPKE, the envelop
ends up looking a bit different.
Hannes: For alignment with the COSE-based version; we have tried to
incorporate into this version the feedback that we recieved on the COSE
draft. It looks a bit confusing with the two layers that Orie described,
I would love a better way to explain it.
Hannes: It is important to do the JOSE-based version of the HPKE draft.
We have worked on the COSE-based version and it triggered others to ask
for the same functionality for JOSE.
ADOPTION QUESTION: We will send a call-for-adoption to the mailing list.
* https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/
John: I don't have a personal opinion. What is the view from the COSE
WG? Is there consensus in COSE
Mike: I did give a heads-up to Ivo, my COSE co-chair, and he was fine
with doing it in JOSE. There are a lot of examples of making guidance
for COSE and JOSE in one of the group. Ilari said that this makes sense.
Nobody said it was a bad idea.
John: This does not remove the existing registrations. It just adds
fully specified algorithm numbers. We could immediately go to the FIDO
specs and use the new values in the registry.
Paul Bastian: I like the idea. Just a small remark. I had no idea what
the draft does after looking at the title of the document. I suggest a
new title, maybe using the word "prameter-less".
Mike: I am fine with the WG bikeshedding the doc
Tiru: I like the approach. The polymorphic approach is quite
complicated, particularly for the PQC algorithms.
Jonathan Hammell: I will put in some text aout semantics of what to dif
there is a conflicting curve parameter.
Mike: Give me an example
Jonathan: If the header also contain a curve then a conflict can happen.
Mike: I could imagine that a key being used that does not match the
curve. I would return an error.
Orie: If you have algorithm restrictions in the key represestations then
it needs to be considered. The cross-mode attack is not addressed by
this fully specified draft. Be very clear what the key is for and don't
use it for other purposes.
Filip: I am glad that you mentioned the K curve registration. I can
still feel the ripple through the issuer tracker. Before this would be
adopted I know it is hard to get a buy-in, the change of having the
algorithm id change. I wish this would have come 1/2 earlier before we
have locked down the Web Crypto API. It would be a shame if that API
would be published and so I changed the spec. It is already in two
implementations of browsers.
Mike: In JOSE we didn't change the algorithm identifies. Since reviewers
came back to us within two days of the publication of the draft, I
believe the values in the JOSE spec are stable. In the COSE side it is
almost certain that the numbers will change because it is
first-come-first-serve. So, the ids in the drafts will change.
John: Do know which registrations come through JOSE and through COSE? We
need to know what algorithms the group needs.
Mike: Should this be adopted? Should this be loaded up with more
algorithms? I want to move this fast.
John: I don't see how this draft prevents a key for being used with
different algorithms.
Carsten: Our registries are run by people. If they become aware of an
issue then they can react to it. If you can generate a statement and
last call it in the working group then you can reserve the numbers.
Roman: (no hat) Is this technique of ciphersuite naming a new strategy?
John: It does not change the registry but gives guidance.
Roman: in the future the expert would reject if the registration is not
fully specified.
Will do a call for adoption on the mailing list
* https://datatracker.ietf.org/doc/draft-tschofenig-jose-cose-guidance/
Samuel: A lot of people try to revoke previously issued JWTs. Having
patterns for that would help people not get it wrong.
Roman (RD): Question to Chairs: can we close the call on charter change
and add that missing sentence about doing maintenance work?
Karen O'Donoghue (Chair): we did ask this on the mailing list, but we
received very few responses; around 5. Let's do a straw pole.
Straw Pole results: YES: 30, No: 0
Yaron: What does "Globally Unique whithin the scope of the issuer" mean?
Hannes: "Global to your environment".
RD: ACTION: I will take the draft text and put them in the charter. We
should also add dates to the milestones -- there are currently none.
Karen: so we should hold CfA of maintenance drafts until the charter has
been updated to allow maintenence?
Roman: I don't want to see the call for adoption before the charter has
been approved. It is on the telechat for November 30th.
Karen: ACTIONS:
Hannes: Will issue another document version and work with Filip (and
anyone who likes to join). Then, we can do a call for adoption with the
other documents.