Hi all, I have not read these drafts yet, so please forgive me if speaking out of turn.
Speaking as co-chair of COSE WG, we're intermittently discussing a recharter, and accepting new algorithms without recharter has consensus so far. Note, though, that the COSE WG is focused on COSE and not JOSE. Not to say the work couldn't be done there, but if there's little-to-no interest in COSE then it is not likely to make progress. Also, if there's not a clear place to progress work, I would strongly suggest bringing it up on secdispa...@ietf.org, whose purpose is to find homes for new work. - m&m Matthew A. Miller On 20/08/10 11:38, Vladimir Dzhuvinov wrote: > On 10/08/2020 11:28, Neil Madden 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? > > If the COSE is the "proper" WG to get the spec completed and the algs > registered, then let it be COSE. We can continue the conversation there. > I support both drafts. > >> >>> 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
