Hello, Id' like to add that I've made a Gist with a one file implementation in Go to try to make it simple to understand. https://gist.github.com/Zenithar/cf58b003fcf341a3b1593c30b50b0820
I hope it helps new users Regards, Le lun. 10 août 2020 à 19:34, Mike Jones <Michael.Jones= 40microsoft....@dmarc.ietf.org> a écrit : > 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> 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> > wrote: > > Thanks Vladimir, > > Responses below > > > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <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 > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Thibault Normand "Il existe moins bien mais c'est plus cher !" http://www.zenithar.org
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
