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
