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 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
