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
