I think the SIV draft is well suited to COSE - it shares many similar properties to CCM, which is widely used in embedded/IoT applications (and COSE). The misuse resistance is also particularly appealing in those environments (indeed, I created the draft to support some IoT activity at ForgeRock). For example, Teserakt (https://teserakt.io <https://teserakt.io/>) use SIV mode in their IoT platform [1].
The ECDH-1PU draft is also potentially interesting for constrained environments, given that it eliminates the need for a separate signature so would provide a reduction in code size. COSE already has an ECDH-SS mode which is also authenticated, so this would compliment that with some stronger security properties. I think therefore that the COSE WG could be a natural home, so I will send a message there to see if there is interest and otherwise take them to secdispatch. The drafts can then register identifiers for COSE and JOSE at the same time. [1]: https://teserakt-io.github.io/e4-doc/specifications/cryptography-primitives/#authenticated-encryption <https://teserakt-io.github.io/e4-doc/specifications/cryptography-primitives/#authenticated-encryption> — Neil > On 10 Aug 2020, at 20:39, Matthew A. Miller <linuxwolf+i...@outer-planes.net> > wrote: > > 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 <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
