From nobody Sat May 1 14:24:46 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A83A10DB for ; Sat, 1 May 2021 14:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2dgOdGYuAKG for ; Sat, 1 May 2021 14:24:36 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAA83A10E2 for ; Sat, 1 May 2021 14:24:36 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id n32-20020a9d1ea30000b02902a53d6ad4bdso1729675otn.3 for ; Sat, 01 May 2021 14:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/A8fC/y06IUQCpxXUtnwqNKNMEXAPLVQIgkwFkVzgKc=; b=11G7EeuMT2OVhfIffPfFwkJzJlhvMGddlmi9rM9TWu2Qn+YgfmJp/Se8B8lqGuRVcK 5tdrmKGsHUBfJIYzPQnbntfIdvbdSXDDyPHB0OoQpGgKLt2KcOmfOC9c7QxZhMT9PH8Y F6fqkrk5FL5/ipF9nM0HEUJM/D7kzn/9OPKJcBoAuyrzjdszVaMD5DlCX1QaCxx319dI rFUzwgCKENwNUGxtTVjCVGSDwFt7UWqXr8IkqCmZehME6ni2YtLQ/Or29IbcbSlGhepO pHPjRcX2BvHg2yDnrZhx8pmL7kXqkGPWoDrwV0JztgcXbu4U8+X8GmEU9K/uSe6y0HQV hWjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/A8fC/y06IUQCpxXUtnwqNKNMEXAPLVQIgkwFkVzgKc=; b=jcccjuZAyRhT2FV163Rc8+dParS4uNHzg82QumvWKsb4CeKKkwOgTp1DF4/035XF01 u2NG1vV8GpWu6n7O/nBsgtvMYklJAIGQoftjPyIpM7SX3TXd7Ae449QJdjs7QL+Snq7d QyxVxSdw50kiRLKwJYzFCBX2g5rPmDfe4P+J+zmKGts4voFupk0pjzNZ3qgkY3PgMU3t 2rDFwJK+IooIBsTfaU4HQMx+k3zml0lJMV0RoW+3SQ4lsw58/sfSr1UmacXeXT2a8q6K 7cjC3Xoobxj2s2e53y5Jf5/hKvJ6Y7EMp/difPGJa5m730tLAcaKyCg7/AxtDFL73dHb lWcA== X-Gm-Message-State: AOAM530wKj+lispPPdpzikMurTTSct6PKpxBabhzsElU5Un7n6LlJsNc QkrYgWp1uLrtJ3t0Ks8IziHAc0YVGK+Jd0TPVRXL4g== X-Google-Smtp-Source: ABdhPJw/XGFSI7GGw9rZNxUUOAdVfwa8GivwmhyCLXi8eL6riv//NGsByNKYt9FhJPHTLuajOltpyTYum73w1Z3OuOc= X-Received: by 2002:a05:6830:4ca:: with SMTP id s10mr9304681otd.79.1619904273973; Sat, 01 May 2021 14:24:33 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> From: Samuel Erdtman Date: Sat, 1 May 2021 23:24:23 +0200 Message-ID: To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000d212eb05c14b5aeb" Archived-At: Subject: Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 21:24:42 -0000 --000000000000d212eb05c14b5aeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Carsten, Your clarifications were great! See some comments inline. On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: > Hi Samuel, > > > 1. What do you mean with data at rest, data store in database or file? > > The point is that you are not signing the data being transferred, but a > local copy of some (e.g., freshly decoded) data (i.e., at the data model > level) which is then processed a little (potentially taking out all > signatures) and then is run through a rather complicated engine to produc= e > a signing input that is a deterministic function of the decoded and > processed data. > > There are easier ways to get a signing input from JSON-like data at rest. > For a (quite workable) strawman: How about doing a CBOR encoding using > deterministic encoding rules? > This is a good point. Still not convinced other solutions would be orders of magnitude better and the proposed one is easy to implement and easy to understand (maybe too easy since I had not thought about your alternative solution). > > > Or is it data that does not change? Sorry I do not get it. > > > > 2. What is weird with saying "Represented in JSON=E2=80=9D? > > Your scheme does NOT require (or benefit in any way from) representing th= e > data in JSON. > The data could be transferred in YAML (or CBOR for that matter): as long > as your local copy of the decoded data (after the little processing) stic= ks > inside the confines of the I-JSON data model, you can use your scheme for > signing. > But since JSON according to https://tools.ietf.org/html/rfc7159 is fairly flexible, would not fitting it into CBOR require similar limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON limitations= ) > > > is it that the RFC7493 I-JSON subset is not all that JSON could be? (to > me this is a reasonable limitation that I in practice never have had to g= o > outside) > > Well, that has been debated to death, and it is clear that nobody likes > I-JSON (*), but it is the de-facto boundary within which the actually mor= e > capable JSON format needs to be used these days. > (If you need more flexibility, you know where to find CBOR.) > So are you saying that CBOR would not impose the same limitations on the original JSON as RFC8785? > > > 3. So I totally get that one does not like XMLDigSig, in my opinion not > because of the signing procedures but because of the canonicalization > process. When I looked at it I gave up and created a hardcoded template. > The difference in canonicalization of JSON (RFC7493 I-JSON subset) > according to RFC8785 is like night and day compared to XML > canonicalization. In your comment it seems like you are of the opinion th= at > this effort will be as tricky as XMLDigSig. do you think so? > > Indeed, the RFC 8785 encoding is (ignoring potential problems on the > numeric side) simpler than canonicalized XML, even with its weird > regression to UTF16-land. > > Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicaliz= ation, > but in the confusion of how the data at rest was to be processed for > signing, e.g., what part of the data at rest was contributing to the > signing input and what the signature on that part then actually meant. J= WS > is probably flexible enough that a carefully constructed application can > get all this right, but we are talking about non-trivial specifications > needed beyond the boring part of generating the byte-string signing input= . > > > 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain= text" being bad > descriptions. Yes what is signed is the RFC8785 transformation of the inp= ut > data, but the signature are then put into your data keeping the data in i= ts > original =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain text" as opposed = to base64-url encoded. I > guess enveloped JWS is a more accurate name but =E2=80=9Cclear text=E2=80= =9D or =E2=80=9Cplain > text" is easy to understand. > > Well, I understand that the naming you chose is a good strategy for > selling the scheme. > It is, however, not describing what is actually going on, and I try to > minimize the use of misleading terminology. > Fair point > > Gr=C3=BC=C3=9Fe, Carsten > > (*) Over at the JSON mailing list, there has been some fresh discussion > just this week about how to get around some of the implementation > limitations, or JSON=E2=80=99s (deliberate!) lack of extensibility, or bo= th. > Archived-At: < > https://mailarchive.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> > and the thread behind that. > > --000000000000d212eb05c14b5aeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Carsten,

=
Your clarifications were great!

See some comm= ents inline.

On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi Samuel,

> 1. What do you mean with data at rest, data store in database or file?=

The point is that you are not signing the data being transferred, but a loc= al copy of some (e.g., freshly decoded) data (i.e., at the data model level= ) which is then processed a little (potentially taking out all signatures) = and then is run through a rather complicated engine to produce a signing in= put that is a deterministic function of the decoded and processed data.

There are easier ways to get a signing input from JSON-like data at rest. For a (quite workable) strawman: How about doing a CBOR encoding using dete= rministic encoding rules?

This is a goo= d point. Still not convinced other solutions would be orders of magnitude b= etter and the proposed one is easy to implement and easy to understand (may= be too easy since I had not thought about your alternative solution).
<= /div>
=C2=A0

> Or is it data that does not change? Sorry I do not get it.
>
> 2. What is weird with saying "Represented in JSON=E2=80=9D?

Your scheme does NOT require (or benefit in any way from) representing the = data in JSON.
The data could be transferred in YAML (or CBOR for that matter): as long as= your local copy of the decoded data (after the little processing) sticks i= nside the confines of the I-JSON data model, you can use your scheme for si= gning.

But since JSON according to https://tools.ietf.org/html/rfc= 7159 is fairly flexible, would not fitting it into CBOR require similar= limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-= JSON limitations)
=C2=A0

> is it that the RFC7493 I-JSON subset is not all that JSON could be? (t= o me this is a reasonable limitation that I in practice never have had to g= o outside)

Well, that has been debated to death, and it is clear that nobody likes I-J= SON (*), but it is the de-facto boundary within which the actually more cap= able JSON format needs to be used these days.
(If you need more flexibility, you know where to find CBOR.)

So are you saying that CBOR would not impose the same= limitations on the original JSON as RFC8785?
=C2=A0

> 3. So I totally get that one does not like XMLDigSig, in my opinion no= t because of the signing procedures but because of the canonicalization pro= cess. When I looked at it I gave up and created a hardcoded template. The d= ifference in canonicalization of JSON (RFC7493 I-JSON subset) according to = RFC8785 is like night and day compared to XML canonicalization. In your com= ment it seems like you are of the opinion that this effort will be as trick= y as XMLDigSig. do you think so?

Indeed, the RFC 8785 encoding is (ignoring potential problems on the numeri= c side) simpler than canonicalized XML, even with its weird regression to U= TF16-land.

Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicalizat= ion, but in the confusion of how the data at rest was to be processed for s= igning, e.g., what part of the data at rest was contributing to the signing= input and what the signature on that part then actually meant.=C2=A0 JWS i= s probably flexible enough that a carefully constructed application can get= all this right, but we are talking about non-trivial specifications needed= beyond the boring part of generating the byte-string signing input.

> 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplai= n text" being bad descriptions. Yes what is signed is the RFC8785 tran= sformation of the input data, but the signature are then put into your data= keeping the data in its original =E2=80=9Cclear text=E2=80=9D or =E2=80=9C= plain text" as opposed to base64-url encoded. I guess enveloped JWS is= a more accurate name but =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain te= xt" is easy to understand.

Well, I understand that the naming you chose is a good strategy for selling= the scheme.
It is, however, not describing what is actually going on, and I try to mini= mize the use of misleading terminology.

Fair point
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten

(*) Over at the JSON mailing list, there has been some fresh discussion jus= t this week about how to get around some of the implementation limitations,= or JSON=E2=80=99s (deliberate!) lack of extensibility, or both.=C2=A0 Arch= ived-At: <https://mailarchi= ve.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> and the threa= d behind that.

--000000000000d212eb05c14b5aeb-- From nobody Sat May 1 14:28:59 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20933A1118 for ; Sat, 1 May 2021 14:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVktjQbC9LI9 for ; Sat, 1 May 2021 14:28:44 -0700 (PDT) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA823A1110 for ; Sat, 1 May 2021 14:28:44 -0700 (PDT) Received: by mail-oo1-xc35.google.com with SMTP id c12-20020a4ae24c0000b02901bad05f40e4so419122oot.4 for ; Sat, 01 May 2021 14:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y4K4ms5W8oP/nQiUlcLgssDNUjb+LAcb6PIJKQKny+k=; b=Eb32Jz6yq6vjlMaTlINLMTCO6FugVBqu5wlm6mrd75++tPyl+vNaCtU+30QGBJPnYZ fauGDJfqRgM6VInysuRcHf/3NlvycRggApYeUf3bbdImKMsQ441k81UGpdAM+T8wvEz2 TFREOGi19qSDUR7FaWECTWA8ieZ111NBemIXMddAJkI80CKxHHZwasugIyKpwIik7k0M nFwrRr+pbzF4VR1fP1yWVBfrQ+idShzPB3ycbYGCnExx0e9iwD0TC+/RbpKxcguw8lfc ohUvfK589ZmZ4m10koO7tDveVGGkYa3IeQ0HVxZueFJX5gO9M4DjeQD7Y0SmtfygInnr d+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y4K4ms5W8oP/nQiUlcLgssDNUjb+LAcb6PIJKQKny+k=; b=ZHIky3WfwVaNnhDeLAR0o6Osae+eBZX3dlHZxof8xOAKhjNcXigRGXvMy5sfBqKf6I 98EkZKnTm60CXdGwHHrCTvlE0OBYikC5ASTCC/o3Jb/V3LvxAQ4WKSeZs2EFmlQ/6096 CmNMrVR4YhNHrnCif880YGZCK0wzS3Al7BNJQ0uDTzMBL8LAwXqLHb7zJ0kB8nCTealR qcpB9LwlB5SrhIvuBbdDrz+JQdLbrqh83PpFKb2tu3CG9nxNvzHGAXRUvtalNswhBpwF r17RyD4Hcwhr4/yNweLKBzpdogKgr4Nc+QBFey+7ogIE9vq/QIe3ynqluqc1lBlRh2Sn tNXQ== X-Gm-Message-State: AOAM530ywUaatOxESoFzAa/uQXd/gkCzm3tnAfWHEFfIvPLMKxMXeadB ZFo81iExqDNMUni0uCnuHqT4DyNK1ThQds6aLR0ybQ== X-Google-Smtp-Source: ABdhPJxmJocMe3Ac8LH7n3q9RzZpe1UNPN64HisJO5XfBtgT9anrX8GTpZ4ePTU8l7a4TFeqZ4aYxAeopZv4Q74MT08= X-Received: by 2002:a4a:b4cb:: with SMTP id g11mr9851682ooo.41.1619904518286; Sat, 01 May 2021 14:28:38 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: From: Samuel Erdtman Date: Sat, 1 May 2021 23:28:27 +0200 Message-ID: To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="00000000000062079105c14b6910" Archived-At: Subject: Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 21:28:55 -0000 --00000000000062079105c14b6910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, One more thing, you wrote "Signing data at rest certainly is a use case that is worth addressing.". With my new fond insights (thanks) does this mean that you are in favor of specifying how to do enveloped signatures for JSON (or at least not against it)? Cheers //Samuel On Sat, May 1, 2021 at 11:24 PM Samuel Erdtman wrote: > Thanks Carsten, > > Your clarifications were great! > > See some comments inline. > > On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: > >> Hi Samuel, >> >> > 1. What do you mean with data at rest, data store in database or file? >> >> The point is that you are not signing the data being transferred, but a >> local copy of some (e.g., freshly decoded) data (i.e., at the data model >> level) which is then processed a little (potentially taking out all >> signatures) and then is run through a rather complicated engine to produ= ce >> a signing input that is a deterministic function of the decoded and >> processed data. >> >> There are easier ways to get a signing input from JSON-like data at rest= . >> For a (quite workable) strawman: How about doing a CBOR encoding using >> deterministic encoding rules? >> > > This is a good point. Still not convinced other solutions would be orders > of magnitude better and the proposed one is easy to implement and easy to > understand (maybe too easy since I had not thought about your alternative > solution). > > >> >> > Or is it data that does not change? Sorry I do not get it. >> > >> > 2. What is weird with saying "Represented in JSON=E2=80=9D? >> >> Your scheme does NOT require (or benefit in any way from) representing >> the data in JSON. >> The data could be transferred in YAML (or CBOR for that matter): as long >> as your local copy of the decoded data (after the little processing) sti= cks >> inside the confines of the I-JSON data model, you can use your scheme fo= r >> signing. >> > > But since JSON according to https://tools.ietf.org/html/rfc7159 is fairly > flexible, would not fitting it into CBOR require similar limitations as > RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON limitatio= ns) > > >> >> > is it that the RFC7493 I-JSON subset is not all that JSON could be? (t= o >> me this is a reasonable limitation that I in practice never have had to = go >> outside) >> >> Well, that has been debated to death, and it is clear that nobody likes >> I-JSON (*), but it is the de-facto boundary within which the actually mo= re >> capable JSON format needs to be used these days. >> (If you need more flexibility, you know where to find CBOR.) >> > > So are you saying that CBOR would not impose the same limitations on the > original JSON as RFC8785? > > >> >> > 3. So I totally get that one does not like XMLDigSig, in my opinion no= t >> because of the signing procedures but because of the canonicalization >> process. When I looked at it I gave up and created a hardcoded template. >> The difference in canonicalization of JSON (RFC7493 I-JSON subset) >> according to RFC8785 is like night and day compared to XML >> canonicalization. In your comment it seems like you are of the opinion t= hat >> this effort will be as tricky as XMLDigSig. do you think so? >> >> Indeed, the RFC 8785 encoding is (ignoring potential problems on the >> numeric side) simpler than canonicalized XML, even with its weird >> regression to UTF16-land. >> >> Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicali= zation, >> but in the confusion of how the data at rest was to be processed for >> signing, e.g., what part of the data at rest was contributing to the >> signing input and what the signature on that part then actually meant. = JWS >> is probably flexible enough that a carefully constructed application can >> get all this right, but we are talking about non-trivial specifications >> needed beyond the boring part of generating the byte-string signing inpu= t. >> >> > 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplai= n text" being bad >> descriptions. Yes what is signed is the RFC8785 transformation of the in= put >> data, but the signature are then put into your data keeping the data in = its >> original =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain text" as opposed= to base64-url encoded. I >> guess enveloped JWS is a more accurate name but =E2=80=9Cclear text=E2= =80=9D or =E2=80=9Cplain >> text" is easy to understand. >> >> Well, I understand that the naming you chose is a good strategy for >> selling the scheme. >> It is, however, not describing what is actually going on, and I try to >> minimize the use of misleading terminology. >> > > Fair point > > >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> (*) Over at the JSON mailing list, there has been some fresh discussion >> just this week about how to get around some of the implementation >> limitations, or JSON=E2=80=99s (deliberate!) lack of extensibility, or b= oth. >> Archived-At: < >> https://mailarchive.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> >> and the thread behind that. >> >> --00000000000062079105c14b6910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten,

One more thing, = you wrote "Signing data at rest certainly is a use case that is worth = addressing.". With my new fond insights (thanks) does this mean that y= ou are in favor of specifying how to do enveloped signatures for JSON (or a= t least not against it)?

Cheers
//S= amuel


On Sat, May 1, 2021 at 11:24 PM Samuel Erdtman &l= t;samuel@erdtman.se> wrote:
=
Thanks Carsten,

Your clarifica= tions were great!

See some comments inline.

On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi Samuel,

> 1. What do you mean with data at rest, data store in database or file?=

The point is that you are not signing the data being transferred, but a loc= al copy of some (e.g., freshly decoded) data (i.e., at the data model level= ) which is then processed a little (potentially taking out all signatures) = and then is run through a rather complicated engine to produce a signing in= put that is a deterministic function of the decoded and processed data.

There are easier ways to get a signing input from JSON-like data at rest. For a (quite workable) strawman: How about doing a CBOR encoding using dete= rministic encoding rules?

This is a goo= d point. Still not convinced other solutions would be orders of magnitude b= etter and the proposed one is easy to implement and easy to understand (may= be too easy since I had not thought about your alternative solution).
<= /div>
=C2=A0

> Or is it data that does not change? Sorry I do not get it.
>
> 2. What is weird with saying "Represented in JSON=E2=80=9D?

Your scheme does NOT require (or benefit in any way from) representing the = data in JSON.
The data could be transferred in YAML (or CBOR for that matter): as long as= your local copy of the decoded data (after the little processing) sticks i= nside the confines of the I-JSON data model, you can use your scheme for si= gning.

But since JSON according to https://tools= .ietf.org/html/rfc7159 is fairly flexible, would not fitting it into CB= OR require similar limitations as RFC8785 puts on what you can do with the = JSON? (i.e. the I-JSON limitations)
=C2=A0

> is it that the RFC7493 I-JSON subset is not all that JSON could be? (t= o me this is a reasonable limitation that I in practice never have had to g= o outside)

Well, that has been debated to death, and it is clear that nobody likes I-J= SON (*), but it is the de-facto boundary within which the actually more cap= able JSON format needs to be used these days.
(If you need more flexibility, you know where to find CBOR.)

So are you saying that CBOR would not impose the same= limitations on the original JSON as RFC8785?
=C2=A0

> 3. So I totally get that one does not like XMLDigSig, in my opinion no= t because of the signing procedures but because of the canonicalization pro= cess. When I looked at it I gave up and created a hardcoded template. The d= ifference in canonicalization of JSON (RFC7493 I-JSON subset) according to = RFC8785 is like night and day compared to XML canonicalization. In your com= ment it seems like you are of the opinion that this effort will be as trick= y as XMLDigSig. do you think so?

Indeed, the RFC 8785 encoding is (ignoring potential problems on the numeri= c side) simpler than canonicalized XML, even with its weird regression to U= TF16-land.

Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicalizat= ion, but in the confusion of how the data at rest was to be processed for s= igning, e.g., what part of the data at rest was contributing to the signing= input and what the signature on that part then actually meant.=C2=A0 JWS i= s probably flexible enough that a carefully constructed application can get= all this right, but we are talking about non-trivial specifications needed= beyond the boring part of generating the byte-string signing input.

> 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplai= n text" being bad descriptions. Yes what is signed is the RFC8785 tran= sformation of the input data, but the signature are then put into your data= keeping the data in its original =E2=80=9Cclear text=E2=80=9D or =E2=80=9C= plain text" as opposed to base64-url encoded. I guess enveloped JWS is= a more accurate name but =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain te= xt" is easy to understand.

Well, I understand that the naming you chose is a good strategy for selling= the scheme.
It is, however, not describing what is actually going on, and I try to mini= mize the use of misleading terminology.

Fair point
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten

(*) Over at the JSON mailing list, there has been some fresh discussion jus= t this week about how to get around some of the implementation limitations,= or JSON=E2=80=99s (deliberate!) lack of extensibility, or both.=C2=A0 Arch= ived-At: <https://mailarchi= ve.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> and the threa= d behind that.

--00000000000062079105c14b6910-- From nobody Mon May 3 08:37:52 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1446D3A18A5; Mon, 3 May 2021 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quKJ_zcHgsmb; Mon, 3 May 2021 08:37:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366BF3A18A3; Mon, 3 May 2021 08:37:41 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FYnD23HSWzyVM; Mon, 3 May 2021 17:37:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 3 May 2021 17:37:38 +0200 Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" X-Mao-Original-Outgoing-Id: 641749057.865182-4f28f307c53c71d76f6553ebffc36dbc Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> To: Samuel Erdtman X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [Secdispatch] [art] [dispatch] Plain text JSON digital signatures X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:37:46 -0000 On 2021-05-01, at 23:28, Samuel Erdtman wrote: >=20 > Hi Carsten, >=20 > One more thing, you wrote "Signing data at rest certainly is a use = case that is worth addressing.". With my new fond insights (thanks) does = this mean that you are in favor of specifying how to do enveloped = signatures for JSON (or at least not against it)?=20 Signing data at rest doesn=E2=80=99t mean that the signature then needs = to be put into the signed object. This is essentially adulterating that = object, and is part of the XMLDSig =E2=80=9Cwhat was just signed?=E2=80=9D= practicability issue. (Such as, does my countersignature include the previous signature or = not? What does it mean to sign a signed object? Nothing about the existing = signature, or does it mean I endorse the existing signature, or does it = mean my signature actually is conditional on the validity of that = existing signature?) I=E2=80=99m not sure though I know what an =E2=80=9Cenveloped = signature=E2=80=9D is, and whether what I just said above even replies = to what I asked. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 3 09:06:54 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823023A1AC3; Mon, 3 May 2021 09:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZYqBD1MzaAi; Mon, 3 May 2021 09:06:38 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506EE3A1ACB; Mon, 3 May 2021 09:06:33 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FYnsM44y6zyY6; Mon, 3 May 2021 18:06:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 3 May 2021 18:06:31 +0200 Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" X-Mao-Original-Outgoing-Id: 641750791.121515-81ca36c7b085c8c48b5f85ba11209a5e Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> To: Samuel Erdtman X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 16:06:45 -0000 Hi Samuel, I haven=E2=80=99t responded to your message yet as it triggers some = MacOS mail misbehavior. Let me try anyway, I hope you can parse the result. > On 2021-05-01, at 23:24, Samuel Erdtman wrote: >=20 >> Thanks Carsten, >>=20 >> Your clarifications were great! >>=20 >> See some comments inline. >>=20 >> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: >> Hi Samuel, >>=20 >> > 1. What do you mean with data at rest, data store in database or = file? >>=20 >> The point is that you are not signing the data being transferred, but = a local copy of some (e.g., freshly decoded) data (i.e., at the data = model level) which is then processed a little (potentially taking out = all signatures) and then is run through a rather complicated engine to = produce a signing input that is a deterministic function of the decoded = and processed data. >>=20 >> There are easier ways to get a signing input from JSON-like data at = rest. >> For a (quite workable) strawman: How about doing a CBOR encoding = using deterministic encoding rules? >=20 > This is a good point. Still not convinced other solutions would be = orders of magnitude better and the proposed one is easy to implement and = easy to understand (maybe too easy since I had not thought about your = alternative solution).=20 It is hard to measure interoperability in orders of magnitude=E2=80=A6 Doing a CBOR signing input is easy to implement and easy to understand, = though. No UTF-16 needed :-) >> > Or is it data that does not change? Sorry I do not get it. >> >=20 >> > 2. What is weird with saying "Represented in JSON=E2=80=9D? >>=20 >> Your scheme does NOT require (or benefit in any way from) = representing the data in JSON. >> The data could be transferred in YAML (or CBOR for that matter): as = long as your local copy of the decoded data (after the little = processing) sticks inside the confines of the I-JSON data model, you can = use your scheme for signing. >>=20 > But since JSON according to https://tools.ietf.org/html/rfc7159 is = fairly flexible, would not fitting it into CBOR require similar = limitations as RFC8785 puts on what you can do with the JSON? (i.e. the = I-JSON limitations) It does require some thinking. https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 documents what = we arrived at when discussing that in the CBOR WG. (I=E2=80=99m very well aware that many applications would be content = with just I-JSON, because they already have made their peace with it to = enable JavaScript classic processing. So I=E2=80=99m just answering the = question here.) >> > is it that the RFC7493 I-JSON subset is not all that JSON could be? = (to me this is a reasonable limitation that I in practice never have had = to go outside) >>=20 >> Well, that has been debated to death, and it is clear that nobody = likes I-JSON (*), but it is the de-facto boundary within which the = actually more capable JSON format needs to be used these days. >> (If you need more flexibility, you know where to find CBOR.) >>=20 > So are you saying that CBOR would not impose the same limitations on = the original JSON as RFC8785?=20 Yes. Again, please see = https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 Please note that I=E2=80=99m not making these points to push CBOR, even = though I=E2=80=99m really convinced CBOR and its =E2=80=9CJSON mode=E2=80=9D= can play a helpful role in addressing the underlying requirements. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 6 14:00:57 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7ED3A319B for ; Thu, 6 May 2021 14:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PKx3JA73Id7 for ; Thu, 6 May 2021 14:00:44 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24F83A319E for ; Thu, 6 May 2021 14:00:44 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id b5-20020a9d5d050000b02902a5883b0f4bso6143344oti.2 for ; Thu, 06 May 2021 14:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=FxtnDzyxQWLrvXJhm7k6oRBbymaxHTUPIYqJHhOVBZFBWitfUtU0UapfSckOjpj5iZ abFhBtVf4DP/gNLwzMjeYVDN0ed0wE1QcbXfzz07SXEDyMdZeYPtCBepofT3+k4xCANt ma89NSOmDStd8J6vsIREpYHBFYo0CBW1oPtJuHHlrALnMk2Sg0iIwz8K+VWx2JJ7ybnE wmQ66BETeN23muwB7ZebSAAEGnh7sSuYdtU3/8iEoIE1rjanrMVOxhnpnyLTU3TJt5Al Dp8gHSiJPQwZLbr1Mvf7M10DmYZU1oStYZCbodqDGMCC0KrJg6ORkJ3T+5k73WETWbSn cmcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=ZPLc2Rlo9AEHQ2tcEeU1n1dFrRUW6dZWzt/f+8SUgogUrvvTYxFf5uCRtU8uz97hyQ ZvZAhkwsVEgkU75aSx2pdeLySfhlGt8g6m45W7dnct4lVWJrgdhofIindTduy/BD1Uln iyxAtVz4vw2LCzbQFGgxoqnRoRLmSnSVjOfyILIhO6R7XhejDI3VKMDk2cukUVUyPvcm 36EaRh3v9hvpaAJbDW4F4H1oUe6Lbr66RUp/HaAmLSQacH/7Kyw3nNV0c3bB0oNExjjN OI8LdZWMEKg9Cze/0+ASJk3gBIFpNq+kesQrR2ZjWgZB6xORI1CxMa+eWPMqv47F5ipF 7aCg== X-Gm-Message-State: AOAM533xprbxIS/zA1XHrBqGXUwx3LPDCYHo96J1b4gik/m/yMNXtr0X z+AoVxJUYDBEqEfN4F2Of9xESnx7ucfNeV/YhjMKrg== X-Google-Smtp-Source: ABdhPJwAed776sRfTR23xrF0xoJkL+fngj8W6S6nDq2BQAsK8PD4pRTEuSwr09+WCkQM3JftQ+oGCMhuCTh6WJdYdus= X-Received: by 2002:a9d:4b0e:: with SMTP id q14mr5255712otf.254.1620334842872; Thu, 06 May 2021 14:00:42 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: From: Samuel Erdtman Date: Thu, 6 May 2021 23:00:31 +0200 Message-ID: To: Carsten Bormann Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000ba197105c1af9a7e" Archived-At: Subject: Re: [Secdispatch] [art] [dispatch] Plain text JSON digital signatures X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 21:00:51 -0000 --000000000000ba197105c1af9a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again Carsten for sharing your thoughts See comment inline On Mon, May 3, 2021 at 5:37 PM Carsten Bormann wrote: > On 2021-05-01, at 23:28, Samuel Erdtman wrote: > > > > Hi Carsten, > > > > One more thing, you wrote "Signing data at rest certainly is a use case > that is worth addressing.". With my new fond insights (thanks) does this > mean that you are in favor of specifying how to do enveloped signatures f= or > JSON (or at least not against it)? > > Signing data at rest doesn=E2=80=99t mean that the signature then needs t= o be put > into the signed object. This is essentially adulterating that object, an= d > is part of the XMLDSig =E2=80=9Cwhat was just signed?=E2=80=9D practicabi= lity issue. > Agree the signature does not have to go into the signed document, but in my opinion has its benefits compared to the alternatives. if puting the signature somewhere else only referencing the signed document it would be inconvenient to find the signature when needed (yes you could create a system for that, there likely exists multiple of them all working slightly differently). The alternative I see would be to create some structure that would wrap the signed data and the signature but in that way it would not be much different from the ascii armoring done by normal JWS, I would like to cater for the use case where you want your doc unchanged apart from the addition of the signature. (This is my opinion, and I=C2=B4m okay with not agreeing) > (Such as, does my countersignature include the previous signature or not? > What does it mean to sign a signed object? Nothing about the existing > signature, or does it mean I endorse the existing signature, or does it > mean my signature actually is conditional on the validity of that existin= g > signature?) > Yes there are questions that would need to be answered, but to me the questions above would be application questions, what is the specific application trying to achieve, all of the options would be possible to technically construct. > > I=E2=80=99m not sure though I know what an =E2=80=9Cenveloped signature= =E2=80=9D is, and whether > what I just said above even replies to what I asked. > With enveloped signature I was referring to when the document that is signed will contain the signature opposed to enveloping signatures where the signature encapsulated the document being signed. (maybe not an established naming) > > Gr=C3=BC=C3=9Fe, Carsten > > --000000000000ba197105c1af9a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks again Carsten = for sharing your thoughts

See comment inline

On Mon, May 3, 2021 at 5:37 PM Carsten Bormann <cabo@tzi.org> wrote:
On 2021-05-01, at 23:28, Samuel Erdtman <samuel@erdtman.se&g= t; wrote:
>
> Hi Carsten,
>
> One more thing, you wrote "Signing data at rest certainly is a us= e case that is worth addressing.". With my new fond insights (thanks) = does this mean that you are in favor of specifying how to do enveloped sign= atures for JSON (or at least not against it)?

Signing data at rest doesn=E2=80=99t mean that the signature then needs to = be put into the signed object.=C2=A0 This is essentially adulterating that = object, and is part of the XMLDSig =E2=80=9Cwhat was just signed?=E2=80=9D = practicability issue.

Agree the signatu= re does not have to go into the signed document, but in my opinion has its = benefits compared to the alternatives. if puting the signature somewhere el= se only referencing the signed document it would be inconvenient to find th= e signature when needed (yes you could create a system for that, there like= ly exists multiple of them all working slightly differently). The alternati= ve I see would be to create some structure that would wrap the signed data = and the signature but in that way it would not be much different from the a= scii armoring done by normal JWS, I would like to cater for the use case wh= ere you want your doc unchanged apart from the addition of the signature. (= This is my opinion, and I=C2=B4m okay with not agreeing)
=C2= =A0
(Such as, does my countersignature include the previous signature or not? What does it mean to sign a signed object?=C2=A0 Nothing about the existing= signature, or does it mean I endorse the existing signature, or does it me= an my signature actually is conditional on the validity of that existing si= gnature?)

Yes there are questions that = would need to be answered, but to me the questions above would be applicati= on questions, what is the specific application trying to achieve, all of th= e options would be possible to technically construct.
=C2=A0<= /div>

I=E2=80=99m not sure though I know what an =E2=80=9Cenveloped signature=E2= =80=9D is, and whether what I just said above even replies to what I asked.=

With enveloped signature I was referri= ng to when the document that is signed will contain the signature opposed t= o enveloping signatures where the signature encapsulated the document being= signed. (maybe not an established naming)
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten

--000000000000ba197105c1af9a7e-- From nobody Thu May 6 14:17:17 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7260C3A3219 for ; Thu, 6 May 2021 14:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dNE18c2Wo4p for ; Thu, 6 May 2021 14:17:03 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327253A3220 for ; Thu, 6 May 2021 14:17:03 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id n184so6767172oia.12 for ; Thu, 06 May 2021 14:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tSiN6yRnSZsCBJdF8dx4UOf22aRuoXZzEn9Et1bpmwM=; b=Rh9ax3ZlR1hIrQbHumCPiDxK+O3CTDTUP7iCpFpAwXpa7UTCDoYee/zOBchkWxvV3/ TQrFhNQfwby0xhGh75eIgDzJe3NzZPsqPRs47obuyDmKTsJAUl2/ubWZFH++YarAsAzO TGM4tKvr4T65J1Xs/4J9zk97zQ+/29MoSY2rX/Wux6a/msQiNi3SZq620/wCGWvHQP18 BIG2fwm3OPoaa/A1U91G3a6MqXNkm53cnak2KJcQfIRyhdT3/D8l8Hf5YpK9Ao0bn5ar KQUHuh7HnVs3eP6gO5pWMoCmGYXlC5ZddY7yozreLjdieoV3cLCANKzwRW3Kr52uBN/l u1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tSiN6yRnSZsCBJdF8dx4UOf22aRuoXZzEn9Et1bpmwM=; b=FLM8Uoem9KKdsw+5j7cK1A/Fad73xLS/EGPXPKFpWEQTHwLnRejsswMvYJRJVIoDh0 8sdag9OI8/VhjixHHR2G+dcZJrdz5/JK4X+8/LjOS/+zezABssbnHZn7QYyxQCNoyfY1 cHdQeFjx0u4sxoe/0zCAF2cgxel5XNOedkNN1kdWn8tzTNemusjevAMsNggUX8fTDdIO qqSytST8x7Kvpx8+j1/fCzePlUrnlmkevsHm2jM8hEalzn6BlbDOGs84XOMPw0jdIzFU SJaoD3yh8PrTg04YPiGfmlHlqx363X8xuP9Rbbw/GHNdpUxenU2yTJ+oBOl8GqY4mcBy pdjw== X-Gm-Message-State: AOAM5305fOq17L8Oh4fig2RlVtmq2VgezJatubLYgM17mRlbSRIkTFrN fw/cHt7NlJOT/dwKyUnJj4Y8b4m0a5IIHkZuHa613A== X-Google-Smtp-Source: ABdhPJzsHhfd3fLNG612+su/nYa3XQrUi51ALE/bbtzILc0yT3ODMih548v+pg/XreIKOLbXjT81fLUKwDwTTxn0MUE= X-Received: by 2002:aca:902:: with SMTP id 2mr2160060oij.59.1620335819547; Thu, 06 May 2021 14:16:59 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: From: Samuel Erdtman Date: Thu, 6 May 2021 23:16:48 +0200 Message-ID: To: Carsten Bormann Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000f0fac505c1afd472" Archived-At: Subject: Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 21:17:09 -0000 --000000000000f0fac505c1afd472 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Carsten, There was not problem reading the reply :), To summarize my understanding you have (at least) two issues with the current doc https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ * It uses RFC8785 to create the signature input which you do not like, since it limits the expressiveness of JSON (and uses UTF-16), CBOR could be an alternative (but you are not pushing for it) * You do not like putting the signature into the signed document because it can cause all kinds of confusion, with e.g. counter signatures. Did I capture that correctly? Cheers //Samuel On Mon, May 3, 2021 at 6:06 PM Carsten Bormann wrote: > Hi Samuel, > > I haven=E2=80=99t responded to your message yet as it triggers some MacOS= mail > misbehavior. > Let me try anyway, I hope you can parse the result. > > > On 2021-05-01, at 23:24, Samuel Erdtman wrote: > > > >> Thanks Carsten, > >> > >> Your clarifications were great! > >> > >> See some comments inline. > >> > >> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: > >> Hi Samuel, > >> > >> > 1. What do you mean with data at rest, data store in database or fil= e? > >> > >> The point is that you are not signing the data being transferred, but = a > local copy of some (e.g., freshly decoded) data (i.e., at the data model > level) which is then processed a little (potentially taking out all > signatures) and then is run through a rather complicated engine to produc= e > a signing input that is a deterministic function of the decoded and > processed data. > >> > >> There are easier ways to get a signing input from JSON-like data at > rest. > >> For a (quite workable) strawman: How about doing a CBOR encoding using > deterministic encoding rules? > > > > This is a good point. Still not convinced other solutions would be > orders of magnitude better and the proposed one is easy to implement and > easy to understand (maybe too easy since I had not thought about your > alternative solution). > > It is hard to measure interoperability in orders of magnitude=E2=80=A6 > Doing a CBOR signing input is easy to implement and easy to understand, > though. > No UTF-16 needed :-) > > >> > Or is it data that does not change? Sorry I do not get it. > >> > > >> > 2. What is weird with saying "Represented in JSON=E2=80=9D? > >> > >> Your scheme does NOT require (or benefit in any way from) representing > the data in JSON. > >> The data could be transferred in YAML (or CBOR for that matter): as > long as your local copy of the decoded data (after the little processing) > sticks inside the confines of the I-JSON data model, you can use your > scheme for signing. > >> > > But since JSON according to https://tools.ietf.org/html/rfc7159 is > fairly flexible, would not fitting it into CBOR require similar limitatio= ns > as RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON > limitations) > > It does require some thinking. > https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 documents what we > arrived at when discussing that in the CBOR WG. > > (I=E2=80=99m very well aware that many applications would be content with= just > I-JSON, because they already have made their peace with it to enable > JavaScript classic processing. So I=E2=80=99m just answering the questio= n here.) > > >> > is it that the RFC7493 I-JSON subset is not all that JSON could be? > (to me this is a reasonable limitation that I in practice never have had = to > go outside) > >> > >> Well, that has been debated to death, and it is clear that nobody like= s > I-JSON (*), but it is the de-facto boundary within which the actually mor= e > capable JSON format needs to be used these days. > >> (If you need more flexibility, you know where to find CBOR.) > >> > > So are you saying that CBOR would not impose the same limitations on th= e > original JSON as RFC8785? > > Yes. Again, please see > https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 > > Please note that I=E2=80=99m not making these points to push CBOR, even t= hough I=E2=80=99m > really convinced CBOR and its =E2=80=9CJSON mode=E2=80=9D can play a help= ful role in > addressing the underlying requirements. > > Gr=C3=BC=C3=9Fe, Carsten > > --000000000000f0fac505c1afd472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Carsten,

There was no= t problem reading the reply :),

To summarize my un= derstanding you have (at least) two issues with the current doc ht= tps://datatracker.ietf.org/doc/draft-jordan-jws-ct/
* It uses= RFC8785 to create the signature input which you d= o not like, since it limits the expressiveness of JSON (and uses UTF-16), C= BOR could be an alternative (but you are not pushing for it)
* You do not like putting the signature int= o the signed document because it can cause all kinds of confusion, with e.g= . counter signatures.

=
Did I capture that correctly?

Cheers
//Samuel

On Mon, May 3, 2021 at 6:06 PM Carsten Bormann <cabo@tzi.org> wrote:
Hi Samuel,

I haven=E2=80=99t responded to your message yet as it triggers some MacOS m= ail misbehavior.
Let me try anyway, I hope you can parse the result.

> On 2021-05-01, at 23:24, Samuel Erdtman <samuel@erdtman.se> wrote:
>
>> Thanks Carsten,
>>
>> Your clarifications were great!
>>
>> See some comments inline.
>>
>> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <cabo@tzi.org> wrote:
>> Hi Samuel,
>>
>> > 1. What do you mean with data at rest, data store in database= or file?
>>
>> The point is that you are not signing the data being transferred, = but a local copy of some (e.g., freshly decoded) data (i.e., at the data mo= del level) which is then processed a little (potentially taking out all sig= natures) and then is run through a rather complicated engine to produce a s= igning input that is a deterministic function of the decoded and processed = data.
>>
>> There are easier ways to get a signing input from JSON-like data a= t rest.
>> For a (quite workable) strawman: How about doing a CBOR encoding u= sing deterministic encoding rules?
>
> This is a good point. Still not convinced other solutions would be ord= ers of magnitude better and the proposed one is easy to implement and easy = to understand (maybe too easy since I had not thought about your alternativ= e solution).

It is hard to measure interoperability in orders of magnitude=E2=80=A6
Doing a CBOR signing input is easy to implement and easy to understand, tho= ugh.
No UTF-16 needed :-)

>> > Or is it data that does not change? Sorry I do not get it. >> >
>> > 2. What is weird with saying "Represented in JSON=E2=80= =9D?
>>
>> Your scheme does NOT require (or benefit in any way from) represen= ting the data in JSON.
>> The data could be transferred in YAML (or CBOR for that matter): a= s long as your local copy of the decoded data (after the little processing)= sticks inside the confines of the I-JSON data model, you can use your sche= me for signing.
>>
> But since JSON according to https://tools.ietf.org/html/rfc7= 159 is fairly flexible, would not fitting it into CBOR require similar = limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-J= SON limitations)

It does require some thinking.
https://www.rfc-editor.org/rfc/rfc8949.html#s= ection-6.2 documents what we arrived at when discussing that in the CBO= R WG.

(I=E2=80=99m very well aware that many applications would be content with j= ust I-JSON, because they already have made their peace with it to enable Ja= vaScript classic processing.=C2=A0 So I=E2=80=99m just answering the questi= on here.)

>> > is it that the RFC7493 I-JSON subset is not all that JSON cou= ld be? (to me this is a reasonable limitation that I in practice never have= had to go outside)
>>
>> Well, that has been debated to death, and it is clear that nobody = likes I-JSON (*), but it is the de-facto boundary within which the actually= more capable JSON format needs to be used these days.
>> (If you need more flexibility, you know where to find CBOR.)
>>
> So are you saying that CBOR would not impose the same limitations on t= he original JSON as RFC8785?

Yes.=C2=A0 Again, please see https://www.rfc-= editor.org/rfc/rfc8949.html#section-6.2

Please note that I=E2=80=99m not making these points to push CBOR, even tho= ugh I=E2=80=99m really convinced CBOR and its =E2=80=9CJSON mode=E2=80=9D c= an play a helpful role in addressing the underlying requirements.

Gr=C3=BC=C3=9Fe, Carsten

--000000000000f0fac505c1afd472-- From nobody Mon May 17 01:51:56 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7063A2F04 for ; Mon, 17 May 2021 01:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoT5ATQDzOTJ for ; Mon, 17 May 2021 01:51:50 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53793A2F02 for ; Mon, 17 May 2021 01:51:49 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id y14so3397244wrm.13 for ; Mon, 17 May 2021 01:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=aLXQEDiQxpIwH2UhG4Xu2auXEQ39RBkcJ8o08JRM3co=; b=DH8EtIMydcTRtNXPH55CF6qlw+MKiE8xnnQlglRkSvun8yLhUW4HxBFPxQ0yjuFlIM fIhvMjXlleTzdpLlq13UWHf1wTbSty8khtsZihClXlpuvWKsiuZM5lB/gUsTVBe6w+Tg j7UYjqmE6jqyOgX3tQ1IC6W2FxDoCinE3O5gA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=aLXQEDiQxpIwH2UhG4Xu2auXEQ39RBkcJ8o08JRM3co=; b=fYGVKDOgJ+uThyo1zAnny2x1XRE53fR8MMI6VKx0wza1IIeBK01yN/lj+wxQ10EAUN 4tJ6cNIVO9h7Tg/FbitFF/GnuEMW+/DZL4mrkRmuor7r++GqCv7BaiMLPHV2VMrH46a7 7LAZqGZNNlQTisbhZ4tP2kxmjoon4PL13puGJKx/+hBXxL9tZwwlJ6XsffxkvJ9YfuH6 9pafqHFnzBZz9/c5D7jwUd5wjFxf8345/ynJqDwuYcubQFyuAFcrNIWgcpetsNFhIQRi Bo5TZMbQhv99FKzSN4luHnvSEIjyq+cQwzfQiYDJzgqWr2ume82mK3mRenUH+n0WJeaR ljXw== X-Gm-Message-State: AOAM532/LXCPa/Ymnj5MO+IQMEEIeKOtZ2vqHY3nGFefK0DVvxtZLD58 Dd2VWDoqw8io0ReF+c70Rl08BtkymZ0wJVaAUbGLFnhbSRq8jqrFa24WKbxudQQPkMdoddl97bg 9nT9qtL+pxjp1plUCPuHUoYCaUIpo8JmYvY9OERnZJ1YElcYo5FhL4+BqLFs1wyEKSDXOauJOxw == X-Google-Smtp-Source: ABdhPJy5wBXdIgXLrHJaEmPnGaisfhIs2rTH1ROAhew7D6ldgOThxLNppxReivQ7QZkpbDy0LZMKWg== X-Received: by 2002:a5d:6445:: with SMTP id d5mr4178882wrw.235.1621241507632; Mon, 17 May 2021 01:51:47 -0700 (PDT) Received: from [10.0.0.8] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y17sm18161618wrw.90.2021.05.17.01.51.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 01:51:47 -0700 (PDT) From: Neil Madden Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Message-Id: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> Date: Mon, 17 May 2021 09:51:46 +0100 To: secdispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.6) Content-Type: multipart/alternative; boundary="Apple-Mail=_0339A4E6-674B-40F2-977B-56A9753079CB" Archived-At: Subject: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 08:51:56 -0000 --Apple-Mail=_0339A4E6-674B-40F2-977B-56A9753079CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" I am looking for a home for this draft that defines a new public key authen= ticated encryption algorithm for JOSE (JWE): https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ Existing JWE algorithms provide authenticated encryption only in the case o= f symmetric algorithms (i.e., AES) and all the existing public key encrypti= on algorithms provide only confidentiality with some level of ciphertext in= tegrity - no sender/origin authentication. When sender authentication is re= quired in a public key context, currently users must resort to a nested com= bination of a digital signature JWS wrapped in a JWE. This can be inefficie= nt, somewhat error-prone, and the stronger security properties provided by = signatures (non-repudiation, 3rd-party verifiability) can be undesirable in= some applications where deniability or privacy are important. The draft was originally created to support work within the OAuth WG around= JWT-format access tokens. However, the WG declined to adopt the draft, so = it=E2=80=99s looking for a new home. I believe the draft is ideally suited = to many applications within OAuth and OpenID Connect, and it has already be= en adopted by other standards work outside the IETF (https://identity.found= ation/didcomm-messaging/spec/#key-wrapping-algorithms ). It may also be a= worthwhile addition to the COSE WG as it has some advantages in code size = compared to combined signature+encryption schemes, but I am primarily inter= ested in the JOSE applications. Kind regards, Neil Madden --=20 ForgeRock values your Privacy --Apple-Mail=_0339A4E6-674B-40F2-977B-56A9753079CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" I am looking for a home fo= r this draft that defines a new public key authenticated encryption algorit= hm for JOSE (JWE):

https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/

Existing JWE algorith= ms provide authenticated encryption only in the case of symmetric algorithm= s (i.e., AES) and all the existing public key encryption algorithms provide= only confidentiality with some level of ciphertext integrity - no sender/o= rigin authentication. When sender authentication is required in a public ke= y context, currently users must resort to a nested combination of a digital= signature JWS wrapped in a JWE. This can be inefficient, somewhat error-pr= one, and the stronger security properties provided by signatures (non-repud= iation, 3rd-party verifiability) can be undesirable in some applications wh= ere deniability or privacy are important.

The draft was originally created to support work w= ithin the OAuth WG around JWT-format access tokens. However, the WG decline= d to adopt the draft, so it=E2=80=99s looking for a new home. I believe the= draft is ideally suited to many applications within OAuth and OpenID Conne= ct, and it has already been adopted by other standards work outside the IET= F (https://identity.foundation/didcomm-messaging/sp= ec/#key-wrapping-algorithms). It may also be a worthwhile addition to t= he COSE WG as it has some advantages in code size compared to combined sign= ature+encryption schemes, but I am primarily interested in the JOSE applica= tions.

Kind regards,

Nei= l Madden

ForgeRock values your Privacy --Apple-Mail=_0339A4E6-674B-40F2-977B-56A9753079CB-- From nobody Mon May 17 02:53:55 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306043A0E0B for ; Mon, 17 May 2021 02:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQq-ZOPF-610 for ; Mon, 17 May 2021 02:53:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EB33A30F6 for ; Mon, 17 May 2021 02:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8442B3901E; Mon, 17 May 2021 06:03:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OAx81SJBIVav; Mon, 17 May 2021 06:03:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 30BEB3901C; Mon, 17 May 2021 06:03:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DFAD81675; Mon, 17 May 2021 05:53:43 -0400 (EDT) From: Michael Richardson To: Neil Madden cc: secdispatch@ietf.org In-Reply-To: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> References: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 09:53:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Neil Madden wrote: > The draft was originally created to support work within the OAuth WG > around JWT-format access tokens. However, the WG declined to adopt the > draft, so it=E2=80=99s looking for a new home. I believe the draft is= ideally Did the WG give a reason? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCiPScACgkQgItw+93Q 3WWoBgf8Dpspg/doYP6bNO2NNVJA1ULUwhGSD+jtdWANUDjtWOWl6yyHHoGVJVav R5W1nw1VjKiICRDcIYucfrSH9FnzASGXuIGb1MAHJ2BbxrI8pAaBQ5KnVtwEeCRE eDQ/WLNiOx8xce72akq7GMw3ejBVa6U8xPkcdnpD0froAEZ2O+ca7pSnddOHMzqw AyM4BttwFgnROBVtPjBZmUIgCy2G/58D6jyNWst/hK1Rb+LsB479Osuxzcc4v9Pg 9rvRftVQaZ9K2Cu7XqVMiWjL877LXNMH2y8OKUldYmxdsL4uZtjBo1mEcFJpvs4N nO46QlRP51e5BI3vkTeetCMZtTsYDg== =29WO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 17 03:04:12 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34963A3142 for ; Mon, 17 May 2021 03:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8BLuwL5mJ-h for ; Mon, 17 May 2021 03:04:06 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58A73A3143 for ; Mon, 17 May 2021 03:04:05 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id l18-20020a1ced120000b029014c1adff1edso4802062wmh.4 for ; Mon, 17 May 2021 03:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to:content-transfer-encoding; bh=X5qIZbqmpptNMTALrHwwJWsXtsgUx304/0atDYda+bI=; b=CHDp5eX5LngCmYU9SON7jv0uE/ACZbZRg2r3m5GWG+k1yPFosQmWOgmPD2En9wz4g8 mH02KL/EouY0VeuTCTHFd66reZePFXo4W2hhlVSFVNsaDR0cYpvY6JZ008zGMGjd4fCT BTt602ezNSv4HyxXKqLah+9Qb+lH0QWJvCOAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:content-transfer-encoding; bh=X5qIZbqmpptNMTALrHwwJWsXtsgUx304/0atDYda+bI=; b=RC47NSBUJ6Tc4F6fIGbx9Rty3xN/xSGuT1PTns/jHcK3IY3qu1+Fzi64pn7enm1kzn uBapQIckbVbsDTgydaxaXec22CSb/2i7grntb3eh8YfpyB6+1DF8pdqJs7Abk3eCqwo9 jBak3b5lnPTAYBs2/C8GIxcnf0E5HTXcQNGzK3nuOYymjov4C5oukMeaKUlE7pqscYje Rl2SonvolXS/3b088yrxfaVq8bgbGTUQvFetuYbOc465Vf5ecnTAAVzDtvHLXvyxw613 /S1BaneBEsBwpMqzPuxcpSEMy1zESL9x3SCgssYSELBzu12DCuVez+pL0cA8Mn/fQE6L Satg== X-Gm-Message-State: AOAM530TtHjucFxFEug5rq3QIxCTfSYNLNb7CbgmkPkWbOct0sS0E0Ed DnGRKRY/d6ArlFjHDlDIval+m7MHCpyIV60mDb8uGPi0rtMl8eJ4flRw06J6zshNGSEIy5pzXGI miUi1iQ== X-Google-Smtp-Source: ABdhPJyv5RjW8MsWr6XHDc6y/0CN8fSZGzV8cJXTPIqAyNp+1qp7sTYorYQxzXIKVNX6d6jnmOfSmw== X-Received: by 2002:a7b:c8cb:: with SMTP id f11mr22709993wml.163.1621245843119; Mon, 17 May 2021 03:04:03 -0700 (PDT) Received: from [10.0.0.8] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id q13sm15151240wrw.56.2021.05.17.03.04.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 03:04:02 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Neil Madden In-Reply-To: <5069.1621245223@localhost> Date: Mon, 17 May 2021 11:04:02 +0100 Cc: secdispatch@ietf.org Message-Id: References: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> <5069.1621245223@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.6) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 10:04:11 -0000 > On 17 May 2021, at 10:53, Michael Richardson wrot= e: >=20 >=20 > Neil Madden wrote: >> The draft was originally created to support work within the OAuth WG >> around JWT-format access tokens. However, the WG declined to adopt the >> draft, so it=E2=80=99s looking for a new home. I believe the draft is id= eally >=20 > Did the WG give a reason? >=20 The meeting was some time ago now, but as I remember it essentially they fe= lt that it was outside of their charter and area of expertise. Although the= OAuth WG have done work around JWTs specifically in the past, they have no= t ever approved new cryptographic algorithms. =E2=80=94 Neil --=20 ForgeRock values your Privacy From nobody Mon May 17 07:06:06 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08013A3902 for ; Mon, 17 May 2021 07:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gph_CCQ2c2UG for ; Mon, 17 May 2021 07:05:58 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EB93A38FE for ; Mon, 17 May 2021 07:05:58 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id q6so3134225qvb.2 for ; Mon, 17 May 2021 07:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JJH/aI8nvkEGGujPmTzGSByq+wROHnGO+utAniNszbk=; b=cYsJgQuBTfCuTWobB0dON9uHIIc5McF+4cB2VZUCCEaTPaOiefyDb5n9WRsk0N21jg 3uYu0Y6FrUpW0/L5PWvi/t6SXhZftSnot9GxnU4wEdDYH131lYYP7T7WVH675dpmlUcV TxJ+L7hz0vusoyYQg5BysX7j1YA5VX9itLU1eOBHpmRxzzCsenyUgMHPJMDnBtprbWgD avKwibW/RCXWPp8XNwDKhYnYXljNbj1T5pFbdVfUpCwztmOW/bmssJUfwtLD4hgufptA NgQy311I55xhTUG28xolF5QEa3zRSUQrTFFxsvTOnQfLHyIPPhe9oVawxeCe8RSpxDII MTTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JJH/aI8nvkEGGujPmTzGSByq+wROHnGO+utAniNszbk=; b=Ek8f9reoQYZsiboKT4yIOr3wWdPEMLRKo1EfKqrSiphhopTmCWTVs4j0c2q+2uohSO xe2HN/c41G6cVKZ60hmz1UBdtXvtQl69b07TPUSrTTYEOCInCne/qJoo++/qRZppOEMM 7cZey7vuFGETe3m2tA6wR7kunCAB1ylJc58hji9OBT/LAIK7yqw495Sw4kJZgMqKuc3P 1eHYYtobr3pfBG1LP1SZwWjUA5P/dg+EUTNMUwCi5ksF9dyAEwvBfLIjSHYM9AfI4chm TT035J5FIFRg6gsQelWQfeCO0pL0v30/aDKZwcEfY+Xcc1pFI+DHIjwDE0SJ5reDz5G4 FyAw== X-Gm-Message-State: AOAM530F0C1sagn3nOb8G9ETjHyICahYqEaa4uE5QppcCIqBUpTkKP11 n+4tfcVTYi9iqrMZP7781v/bDDaJxMtzbBb6Kbh0lA== X-Google-Smtp-Source: ABdhPJyK/NILnguNvKCAjQYX8thgOWfLJPFYoudPvZ0jRvXtcNKK0vI0aCQpWmMmabhfUCrpF4+8Ca4Sf+Z05W+zMFE= X-Received: by 2002:a05:6214:18d3:: with SMTP id cy19mr21115740qvb.47.1621260355948; Mon, 17 May 2021 07:05:55 -0700 (PDT) MIME-Version: 1.0 References: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> <5069.1621245223@localhost> In-Reply-To: From: Richard Barnes Date: Mon, 17 May 2021 10:05:44 -0400 Message-ID: To: Neil Madden Cc: Michael Richardson , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000009bb66d05c287171f" Archived-At: Subject: Re: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 14:06:04 -0000 --0000000000009bb66d05c287171f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil, Thanks for bringing up this idea. I wasn't in the WG for the discussion, but if I were there, I would have been worried about the new crypto construction that is laid out in this draft. An interesting alternative approach here might be to use HPKE [1] as the public-key encryption primitive here. HPKE has been through CFRG review already, and has security proofs. It is already being used in protocols like TLS ECH [2] and MLS [3], so there's starting to be some support for it in libraries like boringssl [4]. And in addition to getting a sender-authenticated mode as you do with 1PE, you would also get to upgrade the base JWE ECDH mode to something with better proofs, and you would get a PSK option, all basically for free. Cheers, --Richard [1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke [2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07#section-4 [3] https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol#section-7.7 [4] https://boringssl.googlesource.com/boringssl/+/chromium-stable/crypto/hpke/ On Mon, May 17, 2021 at 6:04 AM Neil Madden wrote: > > > On 17 May 2021, at 10:53, Michael Richardson > wrote: > > > > > > Neil Madden wrote: > >> The draft was originally created to support work within the OAuth WG > >> around JWT-format access tokens. However, the WG declined to adopt the > >> draft, so it=E2=80=99s looking for a new home. I believe the draft is = ideally > > > > Did the WG give a reason? > > > > The meeting was some time ago now, but as I remember it essentially they > felt that it was outside of their charter and area of expertise. Although > the OAuth WG have done work around JWTs specifically in the past, they ha= ve > not ever approved new cryptographic algorithms. > > =E2=80=94 Neil > -- > ForgeRock values your Privacy > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000009bb66d05c287171f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil,

Thanks for bringing= up this idea.=C2=A0 I wasn't in the WG for the discussion, but if I we= re there, I would have been worried about the new crypto construction that = is laid out in this draft.

An interesting alte= rnative approach here might be to use HPKE [1] as the public-key encryption= primitive here.=C2=A0 HPKE has been through CFRG review already, and has s= ecurity proofs.=C2=A0 It is already being used in protocols like TLS ECH [2= ] and MLS [3], so there's starting to be some support for it in librari= es like boringssl [4].=C2=A0 And in addition to getting a sender-authentica= ted mode as you do with 1PE, you would also get to upgrade the base JWE ECD= H mode to something with better proofs, and you would get a PSK option, all= basically for free.

Cheers,
--Richa= rd


On Mon, May 17, 2021 at 6:04 AM Neil Madden <neil.madden@forgerock.com> wrote:
<= /div>

> On 17 May 2021, at 10:53, Michael Richardson <mcr+ietf@sandelman.ca> wrote= :
>
>
> Neil Madden <neil.madden@forgerock.com> wrote:
>> The draft was originally created to support work within the OAuth = WG
>> around JWT-format access tokens. However, the WG declined to adopt= the
>> draft, so it=E2=80=99s looking for a new home. I believe the draft= is ideally
>
> Did the WG give a reason?
>

The meeting was some time ago now, but as I remember it essentially they fe= lt that it was outside of their charter and area of expertise. Although the= OAuth WG have done work around JWTs specifically in the past, they have no= t ever approved new cryptographic algorithms.

=E2=80=94 Neil
--
ForgeRock values your Privacy <https://www.forgerock.com/yo= ur-privacy>

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000009bb66d05c287171f-- From nobody Mon May 17 07:57:30 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334A43A3ADF for ; Mon, 17 May 2021 07:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvMPBfJDAu8g for ; Mon, 17 May 2021 07:57:23 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953323A3ADB for ; Mon, 17 May 2021 07:57:22 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id k5-20020a05600c4785b0290174b7945d7eso3359441wmo.2 for ; Mon, 17 May 2021 07:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/G8X4xijeWS495wJ2xjEiFg71DsSIaa7vGdcPxrZqWo=; b=T63u4iZbwVePlJW4FoVVzIDekq1DgBVA0DKKK39scT4k9TIjE4Ueo1tmuSswU5Vxfl 8EbqE3LKnEecDmJnrClNEvPgbogMxgypHymXUFM6H4kbwwNjLzkbU1puYVac6wGMo1iL d7D0L5U4wgPdExGnYcDzkDkE6GjEApxR97Cws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/G8X4xijeWS495wJ2xjEiFg71DsSIaa7vGdcPxrZqWo=; b=SxtE3xw1Wt/yR2jwuTfTUGMlhP3ug1yuUV/BQ1Tz6YCBxKTHOJfBWumWhcj6IyXTG4 OAWBCJV5nYSfWsZHTLWhds3zPqrb/uBVX4wnTOtH7YEG22NIDzuxUzzBN58MgvmRB7K7 u6aTGkY2+uKBgfRJgw9CEiRUDIrZslUVzXGLhhYGzRf7X8vIyZ2c0WVAQgCDHX2V04p1 5AyMnFG0TVw0+NT+EthMEuvqd3nmWNCgwEtNNo/0oCGie8Uo6O5TLEiLUH/9NogkaWuz ZvRZfP2/0o6QV+Mhv1hgyavMuvc3Xaeq+6NRSdh9Sh0HbE8/95o95oaFclGj+ISMehVV 4nag== X-Gm-Message-State: AOAM533M4lIz2TTLpa6jHQ9MGtVBB2YRurwc6+VorOMnrLxN7tz4udJ4 dP9R4W72lROiLNM44Q+jP2kiQ2d22Cc/mJ0dSxoXjBE8zdMUGzf2dMPUeDSpmeAH2G1FhDuqZVm Ilycr9J63rOnjtw== X-Google-Smtp-Source: ABdhPJzLEGvub/1BBc8OMua6W5xTio/I5ekovu9s4xOEgc/OaL2ShxVhig3Ey7rMLDyE5FNluSWKrQ== X-Received: by 2002:a1c:f614:: with SMTP id w20mr118175wmc.70.1621263438868; Mon, 17 May 2021 07:57:18 -0700 (PDT) Received: from [10.0.0.8] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y21sm21864326wmi.15.2021.05.17.07.57.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 May 2021 07:57:18 -0700 (PDT) From: Neil Madden Message-Id: <00603DAA-BA62-4856-BCD5-E444D27AB187@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Date: Mon, 17 May 2021 15:57:17 +0100 In-Reply-To: Cc: Michael Richardson , secdispatch@ietf.org To: Richard Barnes References: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> <5069.1621245223@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.6) Content-Type: multipart/alternative; boundary="Apple-Mail=_9B09FDBD-93D8-41E7-819E-C34AFE0C871E" Archived-At: Subject: Re: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 14:57:28 -0000 --Apple-Mail=_9B09FDBD-93D8-41E7-819E-C34AFE0C871E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Thanks, replies inline below: > On 17 May 2021, at 15:05, Richard Barnes wrote: >=20 > Hi Neil, >=20 > Thanks for bringing up this idea. I wasn't in the WG for the discussion,= but if I were there, I would have been worried about the new crypto constr= uction that is laid out in this draft. > An interesting alternative approach here might be to use HPKE [1] as the = public-key encryption primitive here. HPKE has been through CFRG review al= ready, and has security proofs. It is already being used in protocols like= TLS ECH [2] and MLS [3], so there's starting to be some support for it in = libraries like boringssl [4].=20 ECDH-1PU is broadly similar to the DHKEM HPKE construction: it differs main= ly in the key derivation process. The DH AuthEncap/AuthDecap process in sec= tion 4.1 is very similar. (It=E2=80=99s also similar to e.g. the Noise K on= e-way handshake pattern [1]).=20 However, HPKE has one serious disadvantage for the use-cases I (and others)= want it for, in that it explicitly rules out of scope what the HPKE draft = (and related papers) refer to as =E2=80=9CInsider-Auth=E2=80=9D security [2= ]. That is, a recipient of a message sent using HPKE can construct a forger= y that, to the other recipients of the original message, appears to come fr= om the original sender. This is a critical weakness in, for example, an OAu= th system built upon this, as shown in this example: 1. Alice talks to an OAuth authorization server and obtains an access token= to access API1, API2, and API3. 2. The authorization server authenticates and encrypts a JWT-based access t= oken using the public keys of API1, API2, and API3. 3. Alice uses the encrypted access token to access API1. The problem here is that API1 can now construct their own access tokens to = access API2 and API3 with whatever scope they wish. As the security analysi= s in [3] section 5.4 says: We can show that for any AKEM, KS, and AEAD, the construction APKE[AKEM,KS,= AEAD] given in Listing 8 is not (n,qe,qd)-Insider-Auth secure. The inheren= t reason for this construction to be vulnerable against this attack is that= the KEM ciphertext does not depend on the message. Thus, the KEM ciphertex= t can be reused and the DEM ciphertext can be exchanged by the encryption o= f any other message.=20 ECDH-1PU is not vulnerable to this issue precisely because, in the multi-re= cipient case, it ensures that the AKEM ciphertext *does* depend on the mess= age, through the use of a compactly-committing AEAD [4] - the tag of which = is effectively included as associated data in the KEM. > And in addition to getting a sender-authenticated mode as you do with 1PE= , you would also get to upgrade the base JWE ECDH mode to something with be= tter proofs, and you would get a PSK option, all basically for free. I don=E2=80=99t think at this point implementers would thank us for changin= g how the existing ECDH-ES encryption mode of operation works. ECDH-1PU is = deliberately kept quite similar to that existing mode, and in fact can be i= mplemented with just a few additional lines of code in a typical existing i= mplementation. [1]: http://noiseprotocol.org/noise.html#one-way-handshake-patterns =20 [2]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke#section-8.2= .2 =20 [3]: https://eprint.iacr.org/2020/1499.pdf =20 [4]: https://eprint.iacr.org/2017/664.pdf =20 =E2=80=94 Neil >=20 > Cheers, > --Richard >=20 > [1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke > [2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07#section-= 4 > [3] https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol#section= -7.7 > [4] https://boringssl.googlesource.com/boringssl/+/chromium-stable/crypto= /hpke/ > On Mon, May 17, 2021 at 6:04 AM Neil Madden > wrote: >=20 > > On 17 May 2021, at 10:53, Michael Richardson > wrote: > >=20 > >=20 > > Neil Madden > wrote: > >> The draft was originally created to support work within the OAuth WG > >> around JWT-format access tokens. However, the WG declined to adopt the > >> draft, so it=E2=80=99s looking for a new home. I believe the draft is = ideally > >=20 > > Did the WG give a reason? > >=20 >=20 > The meeting was some time ago now, but as I remember it essentially they = felt that it was outside of their charter and area of expertise. Although t= he OAuth WG have done work around JWTs specifically in the past, they have = not ever approved new cryptographic algorithms. >=20 > =E2=80=94 Neil > --=20 > ForgeRock values your Privacy > >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --=20 ForgeRock values your Privacy --Apple-Mail=_9B09FDBD-93D8-41E7-819E-C34AFE0C871E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Thanks, replies inline bel= ow:

On= 17 May 2021, at 15:05, Richard Barnes <rlb@ipv.sx> wrote:

Hi = Neil,

Thanks for bringing up this idea.  I wasn't in the WG = for the discussion, but if I were there, I would have been worried about th= e new crypto construction that is laid out in this draft.
=
An interesting alternative approach here might be to use HP= KE [1] as the public-key encryption primitive here.  HPKE has been thr= ough CFRG review already, and has security proofs.  It is already bein= g used in protocols like TLS ECH [2] and MLS [3], so there's starting to be= some support for it in libraries like boringssl [4]. 

ECDH-1PU is broadly si= milar to the DHKEM HPKE construction: it differs mainly in the key derivati= on process. The DH AuthEncap/AuthDecap process in section 4.1 is very simil= ar. (It=E2=80=99s also similar to e.g. the Noise K one-way handshake patter= n [1]). 

However, HPKE has one ser= ious disadvantage for the use-cases I (and others) want it for, in that it = explicitly rules out of scope what the HPKE draft (and related papers) refe= r to as =E2=80=9CInsider-Auth=E2=80=9D security [2]. That is, a recipient o= f a message sent using HPKE can construct a forgery that, to the other reci= pients of the original message, appears to come from the original sender. T= his is a critical weakness in, for example, an OAuth system built upon this= , as shown in this example:

1. Alice ta= lks to an OAuth authorization server and obtains an access token to access = API1, API2, and API3.
2. The authorization server authenticates a= nd encrypts a JWT-based access token using the public keys of API1, API2, a= nd API3.
3. Alice uses the encrypted access token to access API1.=

The problem here is that API1 can now = construct their own access tokens to access API2 and API3 with whatever sco= pe they wish. As the security analysis in [3] section 5.4 says:
<= br class=3D"">
=09 =09 =09

We can show that for any AK= EM, KS, and AEAD, the construction APKE[AKEM,KS, AEAD] given in Listing 8 is not (n,q<= span style=3D"font-size: 7.000000pt; font-family: 'LMMathItalic7'; vertical= -align: -1.000000pt" class=3D"">e,qd)-Insider-Auth secure. = The inherent reason for this construction to be vulnerable against this attack is that the KEM ciphertex= t does not depend on the message. Thus, the KEM ciphertext can be reused and the DEM c= iphertext can be exchanged by the encryption of any other message. 


ECDH-1PU is not vulnerable to = this issue precisely because, in the multi-recipient case, it ensures that = the AKEM ciphertext *does* depend on the message, through the use of a comp= actly-committing AEAD [4] - the tag of which is effectively included as ass= ociated data in the KEM.


And in addition to getting a s= ender-authenticated mode as you do with 1PE, you would also get to upgrade = the base JWE ECDH mode to something with better proofs, and you would get a= PSK option, all basically for free.

I don=E2=80=99t think at this point implemente= rs would thank us for changing how the existing ECDH-ES encryption mode of = operation works. ECDH-1PU is deliberately kept quite similar to that existi= ng mode, and in fact can be implemented with just a few additional lines of= code in a typical existing implementation.

=
[2]: https://da= tatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke#section-8.2.2 
[4]: <= a href=3D"https://eprint.iacr.org/2017/664.pdf" class=3D"">https://eprint.i= acr.org/2017/664.pdf 

=E2=80= =94 Neil


Cheers,
--Richard

[1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke
[2] https://datatracker.ietf.org/doc/htm= l/draft-ietf-tls-esni-07#section-4
[3] https://datatracker.ietf.org/doc/= html/draft-ietf-mls-protocol#section-7.7
[4] https://boringssl.googlesource.= com/boringssl/+/chromium-stable/crypto/hpke/

On Mon, May 17, 2021 at 6:04 AM Neil = Madden <neil.mad= den@forgerock.com> wrote:

> On 17 May 2021, at 10:53, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> Neil Madden <neil.madden@forgerock.com> wrote:
>> The draft was originally created to support work within the OAuth = WG
>> around JWT-format access tokens. However, the WG declined to adopt= the
>> draft, so it=E2=80=99s looking for a new home. I believe the draft= is ideally
>
> Did the WG give a reason?
>

The meeting was some time ago now, but as I remember it essentially they fe= lt that it was outside of their charter and area of expertise. Although the= OAuth WG have done work around JWTs specifically in the past, they have no= t ever approved new cryptographic algorithms.

=E2=80=94 Neil
--
ForgeRock values your Privacy <https://www.forge= rock.com/your-privacy>

_______________________________________________
Secdispatch mailing list
Secdis= patch@ietf.org
https://www.ietf.org/mailman/listinfo/se= cdispatch


ForgeRock values your Privacy --Apple-Mail=_9B09FDBD-93D8-41E7-819E-C34AFE0C871E-- From nobody Mon May 17 07:59:16 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF3A3A3AEA for ; Mon, 17 May 2021 07:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5_WZWiwWeYC for ; Mon, 17 May 2021 07:59:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010B73A3AEB for ; Mon, 17 May 2021 07:59:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9BAFD38AD1; Mon, 17 May 2021 11:08:27 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RegYVqjy0lS7; Mon, 17 May 2021 11:08:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BC6B838A30; Mon, 17 May 2021 11:08:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A7C9A5FB; Mon, 17 May 2021 10:59:05 -0400 (EDT) From: Michael Richardson To: Neil Madden , secdispatch@ietf.org In-Reply-To: References: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> <5069.1621245223@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 14:59:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Neil Madden wrote: >> Neil Madden wrote: >>> The draft was originally created to support work within the OAuth WG >>> around JWT-format access tokens. However, the WG declined to adopt >>> the draft, so it=E2=80=99s looking for a new home. I believe the dr= aft is >>> ideally >> >> Did the WG give a reason? >> > The meeting was some time ago now, but as I remember it essentially > they felt that it was outside of their charter and area of > expertise. Although the OAuth WG have done work around JWTs > specifically in the past, they have not ever approved new cryptograph= ic > algorithms. So, "good idea", sounds like OAUTH would use it, but they feel it is the wrong place. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCihLkACgkQgItw+93Q 3WXanggAmOwr3higALWulyTDSh4T+kFTQrshGzYmYTiDxID9n0JphY7Q14FJqdN5 /FdI2qSBcb75pHzDhPHjllqKDbZpNknrHCiYxS8zQwORqMAB20yBcOcMBi0fzgtc G/R1jO6/UxIyDJjstlW8RqmF4RTp1Ohad1ZHwHXNfcMIdnX4Rz/X63YE3aAxoBgh Hfn3BxSpusaIBQIV/1zURowuxtVhTFmWFTtcwgUZwv8Rlf2FmOURhteV8Si/9VSV 28Kv3hqqrRsyB9M1ym5UGx9Rntk5wG8E54FMYaveOUCA1ROX95E44wbjD717oz2Q ApjcvTotr1gcnVMbz0VvFswu+anYlw== =8lsj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 27 10:41:01 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86FA3A0D93 for ; Thu, 27 May 2021 10:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhWxCjaR8sQZ for ; Thu, 27 May 2021 10:40:54 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD1F3A0D95 for ; Thu, 27 May 2021 10:40:54 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id x8so673111wrq.9 for ; Thu, 27 May 2021 10:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LoeSX4lu5bpj0MyC65yqn7B34MIcFfvZ3uRMZJAEIUc=; b=Oz0u47ruSG1Rilh71cme37HtCQBWEZAGRkWEhBL6xsniv9SnDFDFqFF4M/tkpRCi7u T/mhUDFc8VVj5k7bRQMJ3lmXd7MPfVjPP0VALxI/PaE57dG6DbYCTiS7bYIsLTt+iOZa x6iRkh8IAHSGrlSgD/QsuETUOt6Oe9iTdEBrU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LoeSX4lu5bpj0MyC65yqn7B34MIcFfvZ3uRMZJAEIUc=; b=efsEjEIpuW1HmTv/yLB8FatBgP7WyIybIGUkY4ZNTDegeNYxysqDayweORRhM3d+gU +AGUxHiKofBQ59YrxD+bfmAywQFAtcMq6L0uAajMtR+IiAnabWniw8dDYDXt7bk0VEdV dHj5aitS3TyXFDKTha1FG7c+eyorTsoXpriJUGu7R02c7FA/h00hiXwhDRCGdCPzPy1q 4zEdmeWItvZM0ynduZHcF3d6haRN+KvClxSGb5SRajBce9a2OT9tCblVNzaV9XcoVefz m9qnFDMH3aFKX9nSZUu8RXrTSxsabz2j2v1Y+M6Md5jh5Fziw7FQqB9d33TTiCXB4Kbc QM1w== X-Gm-Message-State: AOAM533yp1DQZ1KRuiRpG0eGRrVpPVZZgY1TEyohs8gWfEBmD8PKDjWM 2+ivMu9EdxkSFqWkopXQQTengAHz0hvYTbQQGmlQpcHjF9oOT+W5vYFgARf7tLK4MqnL/u26SGG maSBSoDtQLcyrnA== X-Google-Smtp-Source: ABdhPJzxDQ3iNfzkX3FpwDnY7QbauJQ7UR29bqOioiTw2vtgn9SAR5k04x5PrE6u49Q0QhWwoVapmg== X-Received: by 2002:a05:6000:148:: with SMTP id r8mr4738811wrx.311.1622137251984; Thu, 27 May 2021 10:40:51 -0700 (PDT) Received: from [10.0.0.8] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id z17sm4499735wrt.81.2021.05.27.10.40.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 May 2021 10:40:51 -0700 (PDT) From: Neil Madden Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Date: Thu, 27 May 2021 18:40:50 +0100 In-Reply-To: <31585.1621263545@localhost> Cc: secdispatch@ietf.org To: Michael Richardson References: <63EC3EF1-C24B-4EFD-A904-12E510193EB3@forgerock.com> <5069.1621245223@localhost> <31585.1621263545@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.6) Content-Type: multipart/alternative; boundary="Apple-Mail=_C1D86696-E3A5-4ADC-B09D-E739038B24B5" Archived-At: Subject: Re: [Secdispatch] draft-madden-jose-ecdh-1pu X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 17:41:00 -0000 --Apple-Mail=_C1D86696-E3A5-4ADC-B09D-E739038B24B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > On 17 May 2021, at 15:59, Michael Richardson wrot= e: >=20 >=20 > Neil Madden wrote: >>> Neil Madden wrote: >=20 >>>> The draft was originally created to support work within the OAuth WG >>>> around JWT-format access tokens. However, the WG declined to adopt >>>> the draft, so it=E2=80=99s looking for a new home. I believe the draft= is >>>> ideally >>>=20 >>> Did the WG give a reason? >>>=20 >=20 >> The meeting was some time ago now, but as I remember it essentially >> they felt that it was outside of their charter and area of >> expertise. Although the OAuth WG have done work around JWTs >> specifically in the past, they have not ever approved new cryptographic >> algorithms. >=20 > So, "good idea", sounds like OAUTH would use it, but they feel it is the > wrong place. Yes, pretty much. I=E2=80=99m actually wondering if re-chartering the JOSE working group may = be a good way to proceed here? I have another (now expired) draft for a new= algorithm [1] that I know at least one other vendor was keen to implement,= and I believe there have been other potential ideas for JOSE improvements/= changes. For example, I believe there is some interest in deprecating the = =E2=80=9Cnone=E2=80=9D algorithm, which was the cause of some attacks. At s= ome point in the not-too-distant future I would think that JOSE should real= ly standardise at least one post-quantum encryption and signature algorithm= too. [1]: https://datatracker.ietf.org/doc/draft-madden-jose-siv-mode/ =20 =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail=_C1D86696-E3A5-4ADC-B09D-E739038B24B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
On 17 May 2021, at 15:59, Mi= chael Richardson <mc= r+ietf@sandelman.ca> wrote:


Neil Madden <neil.madden@forgerock.com> wrote:
Neil Madden <neil.madden@forgerock.com> wrote:

The draft= was originally created to support work within the OAuth WG
a= round JWT-format access tokens. However, the WG declined to adopt
the draft, so it=E2=80=99s looking for a new home. I believe the draf= t is
ideally

Did th= e WG give a reason?

=
The meeting was some ti= me ago now, but as I remember it essentially
they felt that i= t was outside of their charter and area of
expertise. Althoug= h the OAuth WG have done work around JWTs
specifically in the= past, they have not ever approved new cryptographic
algorith= ms.

So, "good idea", sounds like = OAUTH would use it, but they feel it is the
wrong place.

Yes, pretty much.

I=E2=80=99m actually wondering if re-char= tering the JOSE working group may be a good way to proceed here? I have ano= ther (now expired) draft for a new algorithm [1] that I know at least one o= ther vendor was keen to implement, and I believe there have been other pote= ntial ideas for JOSE improvements/changes. For example, I believe there is = some interest in deprecating the =E2=80=9Cnone=E2=80=9D algorithm, which wa= s the cause of some attacks. At some point in the not-too-distant future I = would think that JOSE should really standardise at least one post-quantum e= ncryption and signature algorithm too.


=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail=_C1D86696-E3A5-4ADC-B09D-E739038B24B5--