I’m likewise supportive of the work. Note that COSE working group is currently open whereas JOSE is closed, so if you want working group review, I’d submit specs to COSE soon.
As background, I worked the spec https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-08 in COSE which also performs JOSE registrations. So that’s definitely a viable path forward. (This document is currently in AUTH48 status, and so is about to become an RFC.) Filip, the JOSE working group closed after RFCs 7515-7518 and 7520 were completed. Note that it’s possible to register algorithms, etc. in the IANA JOSE registries https://www.iana.org/assignments/jose/jose.xhtml without the spec coming from a working group – and indeed, without coming from a working group at all. -- Mike From: OAuth <oauth-boun...@ietf.org> On Behalf Of Dick Hardt Sent: Monday, August 10, 2020 10:27 AM To: Filip Skokan <panva...@gmail.com> Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm I'm supportive of this work. It is not clear that it is in the charter of the OAuth WG. On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan <panva...@gmail.com<mailto:panva...@gmail.com>> wrote: Hi Neil, I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how to go about it tho since JOSE is a concluded WG. Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider the need to further maintain/expand the JOSE algorithms as time goes on? S pozdravem, Filip Skokan On Mon, 10 Aug 2020 at 10:29, Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>> wrote: Thanks Vladimir, Responses below > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov > <vladi...@connect2id.com<mailto:vladi...@connect2id.com>> wrote: > > Hi Neil, > > I definitely like the elegance of the proposed alg for JOSE, it provides > something that isn't currently available in the various classes of algs > made standard in JOSE. > > I also wanted to ask what's happening with AES SIV for JOSE, if there's > traction / feedback / support there as well? > > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02 Thanks for bringing this up. I’ve not received much feedback about this one, and I haven’t been very good at pushing it. If there is interest then I’d certainly be interested in bringing this forward too. That draft might be a better fit for eg the COSE WG though, which could then also register identifiers for JOSE. What do you think? > > Vladimir > > >>> On 05/08/2020 13:01, Neil Madden wrote: >> Hi all, >> You may remember me from such I-Ds >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which >> proposes adding a new encryption algorithm to JOSE. I’d like to >> reserve a bit of time to discuss it at one of the upcoming interim >> meetings. >> The basic idea is that in many cases in OAuth and OIDC you want to >> ensure both confidentiality and authenticity of some token - for >> example when transferring an ID token containing PII to the client >> through the front channel, or for access tokens intended to be handled >> by a specific RS without online token introspection (such as the JWT >> access token draft). If you have a shared secret key between the AS >> and the client/RS then you can use symmetric authenticated encryption >> (alg=dir or alg=A128KW etc). But if you need to use public key >> cryptography then currently you are limited to a nested >> signed-then-encrypted JOSE structure, which produces much larger token >> sizes. >> The draft adds a new “public key authenticated encryption” mode based >> on ECDH in the NIST standard “one-pass unified” model. The primary >> advantage for OAuth usage is that the tokens produced are more compact >> compared to signing+encryption (~30% smaller for typical access/ID >> token sizes in compact serialization). Performance-wise, it’s roughly >> equivalent. I know that size concerns are often a limiting factor in >> choosing whether to encrypt tokens, so this should help. >> In terms of implementation, it’s essentially just a few extra lines of >> code compared to an ECDH-ES implementation. (Some JOSE library APIs >> might need an adjustment to accommodate the extra private key needed >> for encryption/public key for decryption). >> I’ve received a few emails off-list from people interested in using it >> for non-OAuth use-cases such as secure messaging applications. I think >> these use-cases can be accommodated without significant changes, so I >> think the OAuth WG would be a good venue for advancing this. >> I’d be interested to hear thoughts and discussion on the list prior to >> any discussion at an interim meeting. >> — Neil _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
