Re: [OAUTH-WG] ECDH-1PU encryption algorithm

"Matthew A. Miller" <> Mon, 10 August 2020 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E00423A0C67 for <>; Mon, 10 Aug 2020 12:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uuPS4Lrxef7h for <>; Mon, 10 Aug 2020 12:39:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D724C3A0C6C for <>; Mon, 10 Aug 2020 12:39:56 -0700 (PDT)
Received: by with SMTP id y30so2143456ooj.3 for <>; Mon, 10 Aug 2020 12:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qM0+2LlfjyLYojljWqFx+kmGfv7ph+sTlBUoyx10FO8=; b=OwVud2ZD2pA2O7VSfiFOqIlAGsmpvPQ0wArEVWfLKnzyOspHmmojypiiXtWMwe2BOB Tp1S3ErndcdDFPjA5C8VwsAngkLRlkqbR0Svi1DmxCbNxzLUTGVyg6fQ/+59n6RDI5WO BjszK46Dt1JRsbycFKVV1ZdkfB0nT2rTuvuWBHpP/roSO50gOZV/VmKG/LqIu7vQcj5A 0XOP9v07qh0x9B0tVdaLrW+MJOFvoPRNtd/mNTP4nwiwrZSk859VGo8hEOHkgIG+VWC4 oDcKsZPLbBq+58IHuL6kbFgfLH6A1mhhLsU8CxR69eS4m91oSESFwPa2H2iKGeYT8j2B xvFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qM0+2LlfjyLYojljWqFx+kmGfv7ph+sTlBUoyx10FO8=; b=IQil7CI40mnWs4S1Cu3lJbxx3JZcB8JlhmuJVLT9JP4Q9Ahfi02FBl7jIN+0mHhD8R 0rHQ6KhHRlo9RA3Xl0psdOslpisBu3VbDFGsrarCWz94YgmHXSPoEiMOiSSYj0Mt4tjJ qpv4nr6nf31owIrg2lj5/pZ2CtSXIZEJ4XWGNh3Izc8bD6gf0eFUAlgefkfEEHsgcKP8 Y/kGwHxBd2J7RG/iQmTcQYmX8nUbR/izZAgK74wk8H4lGRM+XXA1QQNKGvgblzsSmXgY kMesx9ug4+5jwIcxGF4Af7wLd03hkq8AhZm1lRkS26RaWjGoLTCnvgOUouwaDD+0hXMu 0piA==
X-Gm-Message-State: AOAM530gIhANq1ZzFRfv7sTSc1doTYitMyZSifJnHWsvFR4p74rvKEIm JDnscBHrV0e2uE4Vx9N/GKqXloDmk7cEcg==
X-Google-Smtp-Source: ABdhPJwNbMuUzvVZ0BpuLwjTFUct2ACkySe1xj1AlZcNkJbq+wr5kga3WZ8JoykSbhoHt7dkrHOuiw==
X-Received: by 2002:a4a:e92e:: with SMTP id a14mr2099692ooe.23.1597088395567; Mon, 10 Aug 2020 12:39:55 -0700 (PDT)
Received: from mmiller-44677.local ([2601:280:4f00:14a:2994:7b7a:c8fe:8ca0]) by with ESMTPSA id h90sm3603204oth.38.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 12:39:54 -0700 (PDT)
To: Vladimir Dzhuvinov <>
References: <> <> <>
From: "Matthew A. Miller" <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE=
Message-ID: <>
Date: Mon, 10 Aug 2020 13:39:52 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2020 19:40:06 -0000

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, 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 <> 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?
>> 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, 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