From nobody Tue Apr 27 08:27:45 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 639AE3A10C7; Tue, 27 Apr 2021 08:27:39 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 W5ebtYXOGOPk; Tue, 27 Apr 2021 08:27:35 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 D3FB23A10C5; Tue, 27 Apr 2021 08:27:31 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id n21so13883423eji.1; Tue, 27 Apr 2021 08:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Su1b6AwVPUEry3M5HdAShW9WgyxwpjHbHuDsX3YB7cQ=; b=PBQ2CvrhAgd00SDMM4iHGX8qGmkPPvZyX0vpr27/4RXmywQjVFmzWG/zZsBLJ5C/N5 92P2rEmX5KG4hs8bxzzm9cKgac0cHQgst3WPI5Jt2RGs9GsUtW2c3dPp3UOKgEkEy50f IH2x6GsPsH1cqufXlHD24FfnGiYXVsEK8wLt+e417ShtFgDDKy0Z+H3OVi3UxTwt5l5t yJG2stdJqUvry3CJH94LjN8m0/BK4y6vKD8o6X0Ilqwo59/SuZNP70ARoULpzOkcMkHF t/j8KId0Ee1nKq1PhHlOXFLRwni+gKWFEb42xjAIhJufNGqZFRG5KkdtVCDoL0kbu4AR B6Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Su1b6AwVPUEry3M5HdAShW9WgyxwpjHbHuDsX3YB7cQ=; b=f/5cp22hEtibt2nt8RvZuaDaY/NmhmSXQrNLL1FW9GkNBjCA8N+0CHy8IcK6c9Me+a kFrekVzEtYAMTp5Swr7IADgkGbz5OiU66lZKKJiN7Nn9d9M3CywuFkEoZqmCMiV3aiq3 plWXYoU26K8NmoSwZRbXm4r64Ew8ENjUZzQns9M/yzsyz9wnb82A1BBn3rG5NiWlLjYt TULuiOKGWBoVKNL/pO/7zKipxtaN5t4oANMwO4ufmuCsIZGaML1rtAP9gdzI+5PygoCw kg5dS1MAPNNydK2GuE8ghPlSF7Dy1jzSj8HjD6cLsZhlFSfXx2BV1l4gPwSXcNi6SAfU GO9Q== X-Gm-Message-State: AOAM533H8pr5oj7NqXwcm8vetuIpvZaa/tQvuMEXYCmoY/XkwbYmir2a byx8mTuUCgEzgxsT4P4c+Ys6dvx4m01MvUCtdhthehniD/I= X-Google-Smtp-Source: ABdhPJwSomPkLTIMvp4E5sxZtS7tV4/7MLzSfCOlP+u/GZIcDkxk92mqCa8CuF966qIk1IUNEV8O57O2BrMy16N5w7A= X-Received: by 2002:a17:906:c290:: with SMTP id r16mr23952010ejz.241.1619537248667; Tue, 27 Apr 2021 08:27:28 -0700 (PDT) MIME-Version: 1.0 From: Bret Jordan Date: Tue, 27 Apr 2021 09:27:17 -0600 Message-ID: To: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org Content-Type: multipart/alternative; boundary="000000000000684d2105c0f5e645" Archived-At: Subject: [Secdispatch] 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: Tue, 27 Apr 2021 15:27:39 -0000 --000000000000684d2105c0f5e645 Content-Type: text/plain; charset="UTF-8" Dear Dispatch, Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows: This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT. By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing). In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging. The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward. The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response. We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct Thanks Bret -- Sent from my TI-99/4A PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 --000000000000684d2105c0f5e645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Dispatch,

Anders Rundgren, Samuel, Erdtman, an= d I have been working on an ID for your consideration. This document descri= bes how to use JWS and JCS to create plain-text JSON signatures. The abstra= ct reads as follows:

This document describes a method for extending = the scope of the JSON Web Signature (JWS) standard, called JWS/CT.=C2=A0 By= combining the detached mode of JWS with the JSON Canonicalization Scheme (= JCS), JWS/CT enables JSON objects to remain in the JSON format after being = signed (aka "Clear Text" signing).=C2=A0 In addition to supportin= g a consistent data format, this arrangement also simplifies documentation,= debugging, and logging.=C2=A0 The ability to embed signed JSON objects in = other JSON objects, makes the use of counter-signatures straightforward.
The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-j= ws-ct/

As you know there are large ecosystems that needs digital= signatures for plain text JSON data, meaning where the JSON data is not ba= se64 encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and organi= zations from financial services, threat intelligence, and incident response= .

We are not sure what direction would be best for this work in the= IETF, should we send to the ISE for publication or do you want to create a= working group. Ultimately there is a lot of work that could be done in thi= s space to meet the needs of the market. We would be happy with releasing t= hese IDs for ISE publication, or for creating a working group to move them = forward. It is just important to note that the market is in desperate need = of these solutions. If you want to take it for a spin, there is a JWS/CT pl= ayground at: https://mobilepki.org= /jws-ct

Thanks
Bret
=
--

Sent from my TI-99/4A

PGP Fing= erprint:=C2=A063B4 FC53 680A= 6B7D 1447 =C2=A0F2C0 74F8 ACAE=C2=A07415 0050
--000000000000684d2105c0f5e645-- From nobody Tue Apr 27 08:47:23 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 6C46C3A11E5 for ; Tue, 27 Apr 2021 08:47:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=brianrosen-net.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 hP7JfV54d_mc for ; Tue, 27 Apr 2021 08:47:11 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 8FDD43A11E2 for ; Tue, 27 Apr 2021 08:47:11 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id o1so2826726qta.1 for ; Tue, 27 Apr 2021 08:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=52erJvHyH211Q+bUlVrzfZOPr8C/5MWHC+YGVbtO83o=; b=1q9NPBKHdjC12o5GTxJOs75Q202SY+VF8VG5aPFA2zlGuCF+C8iRwoq791cwlx/Cau fDDZ7zrImFABE5jyJC3fhGXLm3Oexi14gTqiZkTbju4i/IWH0axNDel0Qna1W3TGzC2R Dzi+4OuAn+DO84LnxoyzEab6jCGzP/ziDn2aEmYDp2vp7TW37vJC9owAm/gLiJb34cAm A7O3a0FAU+pQnabtdhSSa80bsDQ9F6sFx4Y/hq+Hbwxm2mPXuhn5V0dV4V+TRygti4GG /A4PQvXaeHph+9ULR2mrWRpoD612qFrd3y29OFR81b7AGrojZVBqQ1iCzD1zlsE+8sQd tdvA== 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=52erJvHyH211Q+bUlVrzfZOPr8C/5MWHC+YGVbtO83o=; b=gcdGBpNyXF5OjHAt1nk9jTvS6MY60gUO5BkD8VwCMxpFICZxKp8TMheqHqXnnPV5Ub kMvBbK10muBIQ+CBodCQUvYypQdjC3dtW/q0KjA5Vc/Lu1DU0ppXK0Vdt6bO9Sn7czIq nu5PLoRdO6fUzhYhgpZWh4zr5QyfCW3lhpMVKxPkbzG8AHjAph1zvzp32+Og3xI13Nzu Iw/98V9O+C/KoKSbEWKomsV/2yC9XPGcABU6KHpgaAODHgUATNYJcDW3OsVFreVXorZq 6oQciIFNDwygjwDhRIRWpody0w+MPJ4Jp06rCnYtb/a1FAegi3hxd+kgRQe7hzhvqrHF eiZA== X-Gm-Message-State: AOAM532Qd/v+et06/biY5hNa/T6t5JL2coAeLuXw8oP1Udz1BSZ/Ipvc bJfBdFGNDzqt99duoUEBoYsQhw== X-Google-Smtp-Source: ABdhPJyvwSd59fOf4gmHHNFK3B7uifstEscZKI3Wgj8BZMUSVE8mbPNnw0jNtdQtZjlHMgBGnNPgSw== X-Received: by 2002:ac8:4658:: with SMTP id f24mr22451505qto.375.1619538429846; Tue, 27 Apr 2021 08:47:09 -0700 (PDT) Received: from brians-mbp.lan (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id p186sm2846105qka.66.2021.04.27.08.47.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Apr 2021 08:47:09 -0700 (PDT) From: Brian Rosen Message-Id: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 27 Apr 2021 11:47:03 -0400 In-Reply-To: Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org To: Bret Jordan References: X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Secdispatch] [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: Tue, 27 Apr 2021 15:47:17 -0000 --Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am very much interested in this work. My preference would be for a = Proposed Standard. There was a lot of opposition to the idea = previously, so it may be that ISE is all we can get, but I would be = willing to work towards PS, either in a new, short lived work group or = as part of another work group. =20 Brian > On Apr 27, 2021, at 11:27 AM, Bret Jordan = wrote: >=20 > Dear Dispatch, >=20 > Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for = your consideration. This document describes how to use JWS and JCS to = create plain-text JSON signatures. The abstract reads as follows: >=20 > This document describes a method for extending the scope of the JSON = Web Signature (JWS) standard, called JWS/CT. By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing). In addition to supporting a consistent data format, = this arrangement also simplifies documentation, debugging, and logging. = The ability to embed signed JSON objects in other JSON objects, makes = the use of counter-signatures straightforward. >=20 > The data tracker page for this: = https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ = >=20 > As you know there are large ecosystems that needs digital signatures = for plain text JSON data, meaning where the JSON data is not base64 = encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and = organizations from financial services, threat intelligence, and incident = response.=20 >=20 > We are not sure what direction would be best for this work in the = IETF, should we send to the ISE for publication or do you want to create = a working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct = >=20 > Thanks > Bret >=20 > --=20 >=20 > Sent from my TI-99/4A >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = am very much interested in this work.  My preference would be for a = Proposed Standard.  There was a lot of opposition to the idea = previously, so it may be that ISE is all we can get, but I would be = willing to work towards PS, either in a new, short lived work group or = as part of another work group.  

Brian

On Apr = 27, 2021, at 11:27 AM, Bret Jordan <jordan.ietf@gmail.com> wrote:

Dear Dispatch,

Anders Rundgren, = Samuel, Erdtman, and I have been working on an ID for your = consideration. This document describes how to use JWS and JCS to create = plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending = the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  = By combining the detached mode of JWS with the JSON Canonicalization = Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format = after being signed (aka "Clear Text" signing).  In addition to = supporting a consistent data format, this arrangement also simplifies = documentation, debugging, and logging.  The ability to embed signed = JSON objects in other JSON objects, makes the use of counter-signatures = straightforward.

The data tracker page for = this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that = needs digital signatures for plain text JSON data, meaning where the = JSON data is not base64 encoded. This ID provides a solution using = existing IETF RFCs to make this work. Further, this work looks to be = adopted by many groups and organizations from financial services, threat = intelligence, and incident response.

We = are not sure what direction would be best for this work in the IETF, = should we send to the ISE for publication or do you want to create a = working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_0A9A5627-118A-43D8-8B5C-CB5BFC966A29-- From nobody Tue Apr 27 09:22:23 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 2D0A83A143C; Tue, 27 Apr 2021 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6pdlzGfdiGpK; Tue, 27 Apr 2021 09:22:09 -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 99D2D3A1410; Tue, 27 Apr 2021 09:22:09 -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 4FV6V54M8Jzyb8; Tue, 27 Apr 2021 18:22:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> Date: Tue, 27 Apr 2021 18:21:59 +0200 Cc: Bret Jordan , art@ietf.org, DISPATCH , rfc-ise@rfc-editor.org, IETF SecDispatch X-Mao-Original-Outgoing-Id: 641233319.424724-28203518ffff9156d9f15176ac24627d Content-Transfer-Encoding: quoted-printable Message-Id: <38EA765F-6FF9-4C45-95D9-7429612B08EC@tzi.org> References: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Tue, 27 Apr 2021 16:22:14 -0000 On 2021-04-27, at 17:47, Brian Rosen wrote: >=20 > There was a lot of opposition to the idea previously, Yes. But there is also some opposition to the weird way this is presented: >> On Apr 27, 2021, at 11:27 AM, Bret Jordan = wrote: >> JWS/CT enables JSON objects to remain in the JSON format after being = signed (aka "Clear Text" signing). =20 We have a lot of ways that enable signed objects to remain in the format = in which they were at signature time. Maybe we can fix the presentation of the idea more towards =E2=80=9Cwe = really liked XMLDsig and want it back for JSON=E2=80=9D, which is = certainly a position one can take. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 27 10:42:37 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 5F8F33A1983; Tue, 27 Apr 2021 10:42:36 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 BHyB5JF1Y75b; Tue, 27 Apr 2021 10:42:31 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 EB71B3A197C; Tue, 27 Apr 2021 10:42:30 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id d10so4492468pgf.12; Tue, 27 Apr 2021 10:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HQL5Wqf3iRLxMjvIGI4OPl0Sd4/TKZ/qOX9ujzTIWVU=; b=K9nHfXu0geV4cePric67yELZVZBVb5od4rVWHn89jcV7cVv1Pf/tlD5SFLhstWHHzX 2ARVi0ZX3gX3EETQha/R/iEepR+XU5iCDefkCgIxt7i06ezZLWdhdS9cFfQJ3y4l+f31 d/O6C78uVTUk5iJN3fgSfDFI2v2hJkRE6IA1lht+VrCoRXRkqssWidQ3DOkSC0jlMTus MpLDRXhTQa+kn6jk8QpOlJTMpSJ/dvpoABR6+zeg1dT9P9o9JyqhV04bPc314vLOM27x 8XoI5Gsu8lI6YhrWJB8dNANItCKF1vcyLW3K1D8rrpT3y3/f7G8JFhWNgSOtRGM1S4WX HQew== 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=HQL5Wqf3iRLxMjvIGI4OPl0Sd4/TKZ/qOX9ujzTIWVU=; b=O/3dNV0wG5wDuMxk5BSBkLilt3cj5y+6Jnl6ObjVNQiN700iM/mcGysxpshyvAonq+ t4f9xVxrA2uf7Pn6YIOMSZJ5yCxkRU2mFT6H1UUsxFFbgsa/m2LCJyYI7dHSLuoLZVwf jCjk23i7rtlBhGnYekSvg+RZ3GZUZwRSQmYDMk8KP0v6YunAVqA6weeIlOYi3YIdVkwk 8p1Mg+p5DreeSXXdJWdNRzxIoNzubiCYQHoFp7LtbPXj5nX2nfJp9erB6D1oHi8mHPcA Ifs/WXJuiCR7hCLbJESGWidp4/InXHABRC9MVoOM5qjY/EWfRIHair+/6bA99l/lUmzu wcPw== X-Gm-Message-State: AOAM532/dU56NJZuQCj/4paG8ss7Cy/2DSnl40vKG6tNSoV8AjCSzX+m lWrrfUO9Y6af5vaSQOpxo9xCTlVlHBk= X-Google-Smtp-Source: ABdhPJwNO+WwxktDW8hDxLzBvx4km7rafVhuv1yWs9XHML4s6w4e4PiGcAXMO2jLJouP/iJhxgdQ2g== X-Received: by 2002:a62:4c3:0:b029:27c:892f:8e22 with SMTP id 186-20020a6204c30000b029027c892f8e22mr155737pfe.6.1619545349138; Tue, 27 Apr 2021 10:42:29 -0700 (PDT) Received: from smtpclient.apple ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id k17sm2876516pji.47.2021.04.27.10.42.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Apr 2021 10:42:28 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 27 Apr 2021 11:42:26 -0600 In-Reply-To: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org To: Brian Rosen References: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [Secdispatch] [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: Tue, 27 Apr 2021 17:42:36 -0000 --Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, Yes, there are are lot of people and organizations that are looking for = a solution like this. There are several that I know of that are already = looking to adopt this or something similar in production. I also know = Anders has been doing a lot of work in the financial sector using this = for payment processing. What people need to realize is that plain text = signatures and plain text JSON is a fundamental requirement. The proof = of concept code I have written so far shows that this works, and works = really well.=20 It is great to hear that you would support this work, either through a = PS or via the ISE. Please let us know if you have any feedback on the = ID.=20 Thanks Bret > On Apr 27, 2021, at 9:47 AM, Brian Rosen wrote: >=20 > I am very much interested in this work. My preference would be for a = Proposed Standard. There was a lot of opposition to the idea = previously, so it may be that ISE is all we can get, but I would be = willing to work towards PS, either in a new, short lived work group or = as part of another work group. =20 >=20 > Brian >=20 >> On Apr 27, 2021, at 11:27 AM, Bret Jordan > wrote: >>=20 >> Dear Dispatch, >>=20 >> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID = for your consideration. This document describes how to use JWS and JCS = to create plain-text JSON signatures. The abstract reads as follows: >>=20 >> This document describes a method for extending the scope of the JSON = Web Signature (JWS) standard, called JWS/CT. By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing). In addition to supporting a consistent data format, = this arrangement also simplifies documentation, debugging, and logging. = The ability to embed signed JSON objects in other JSON objects, makes = the use of counter-signatures straightforward. >>=20 >> The data tracker page for this: = https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ = >>=20 >> As you know there are large ecosystems that needs digital signatures = for plain text JSON data, meaning where the JSON data is not base64 = encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and = organizations from financial services, threat intelligence, and incident = response.=20 >>=20 >> We are not sure what direction would be best for this work in the = IETF, should we send to the ISE for publication or do you want to create = a working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct = >>=20 >> Thanks >> Bret >>=20 >> --=20 >>=20 >> Sent from my TI-99/4A >>=20 >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 --Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Brian,

Yes, there = are are lot of people and organizations that are looking for a solution = like this. There are several that I know of that are already looking to = adopt this or something similar in production. I also know Anders has = been doing a lot of work in the financial sector using this for payment = processing. What people need to realize is that plain text signatures = and plain text JSON is a fundamental requirement. The proof of concept = code I have written so far shows that this works, and works really = well. 

It = is great to hear that you would support this work, either through a PS = or via the ISE. Please let us know if you have any feedback on the = ID. 

Thanks
Bret





On Apr = 27, 2021, at 9:47 AM, Brian Rosen <br@brianrosen.net> wrote:

I am very much = interested in this work.  My preference would be for a Proposed = Standard.  There was a lot of opposition to the idea previously, so = it may be that ISE is all we can get, but I would be willing to work = towards PS, either in a new, short lived work group or as part of = another work group.  

Brian

On Apr 27, 2021, at 11:27 AM, = Bret Jordan <jordan.ietf@gmail.com> wrote:

Dear Dispatch,

Anders Rundgren, = Samuel, Erdtman, and I have been working on an ID for your = consideration. This document describes how to use JWS and JCS to create = plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending = the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  = By combining the detached mode of JWS with the JSON Canonicalization = Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format = after being signed (aka "Clear Text" signing).  In addition to = supporting a consistent data format, this arrangement also simplifies = documentation, debugging, and logging.  The ability to embed signed = JSON objects in other JSON objects, makes the use of counter-signatures = straightforward.

The data tracker page for = this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that = needs digital signatures for plain text JSON data, meaning where the = JSON data is not base64 encoded. This ID provides a solution using = existing IETF RFCs to make this work. Further, this work looks to be = adopted by many groups and organizations from financial services, threat = intelligence, and incident response.

We = are not sure what direction would be best for this work in the IETF, = should we send to the ISE for publication or do you want to create a = working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


= --Apple-Mail=_9EA67B10-5CE9-4BAB-B068-859BEB87D62A-- From nobody Tue Apr 27 16:49:08 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 2AE6F3A25DC; Tue, 27 Apr 2021 16:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 mbyaJyerCugv; Tue, 27 Apr 2021 16:48:53 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 7E3083A25D9; Tue, 27 Apr 2021 16:48:53 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id i21-20020a05600c3555b029012eae2af5d4so8033445wmq.4; Tue, 27 Apr 2021 16:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IwfoDDY9l4QVtUBqexOAOFzt0mCO2fk8g0w3v01ySEM=; b=W5vgFXE6jXcIh07my29QfBM6ydkOnhDOsAYakaMDjQ9NnNln/ip2LU1UktTVpfOhEy +L+oKt+R9tWrwzLi+hzt+Q3FKfYqvxp73D6eFltMHcFsdAV0uh8uSKUPy6m7DmSp9PvH 962BbXaREG/lSk03fOvgYqAduadEl1fo7z2fUPdCJTyVvG3b0P50mQMNdU2X4R/VTlxs XyHHBC2HSniq0ZXWVggsMuJ+bka5uA8IPzCyabXhZIHPBM76XxDOgLOUVmXLtO0iexGb IApVw9+NN3gJqbnI3hFPhFxjTsFFWoVyvVVmk/ovxiOrAc42Lh9OpXAxudgK6dQchxOm DcJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IwfoDDY9l4QVtUBqexOAOFzt0mCO2fk8g0w3v01ySEM=; b=JBBt5p1sh2oRq0H5olgvjJ3yVJA3wRjewU+Jh6aWHbyMgOJ8dYaGNrtsYsKkpQSD06 a8Ff9ifaXq0TVkWWNQyS2H+bw82EQqaiImovDdrKllEJWbbOLTUMBS1xyYb3dpPxB+2Z DuSc8AkbkxegFO3B/tDkSZ5ifZCsFUnhomChtdg1P9woLQFd9Jch1QMneaTH8hdlcyKj JB4J23xDv0IOemdbt7CYEjCaLPtvi4v7UcXti6wJ8q279v2BWRUUpcs4aIY0HOKUD0OQ Eg/OJbQnbrHzNhQ3noM4nRC1TCQGUchdCcRhl76GtVuvMQSTmKxiOD2LFpCJE8kgEonQ Ti+w== X-Gm-Message-State: AOAM533n8Y/nJbGvfW7F2H8aOC7ONZyiVlwTZ9kDHbg0L+aOhbFO+34D lvcWC2TzHWLMgAImZ5vIBTM= X-Google-Smtp-Source: ABdhPJxy4TVFD1/fZjExeGXbBd8KtIuvHovfaaJy3crmN6BmKMuCn7EEUJjvPnWDxMB3Wk3SzUTTXQ== X-Received: by 2002:a1c:e089:: with SMTP id x131mr9262910wmg.102.1619567330353; Tue, 27 Apr 2021 16:48:50 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id l12sm5770171wrm.76.2021.04.27.16.48.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Apr 2021 16:48:49 -0700 (PDT) To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , rfc-ise@rfc-editor.org References: <19176491-A66F-41E9-9670-C842F82FCE68@brianrosen.net> <38EA765F-6FF9-4C45-95D9-7429612B08EC@tzi.org> From: Anders Rundgren Message-ID: Date: Wed, 28 Apr 2021 01:48:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <38EA765F-6FF9-4C45-95D9-7429612B08EC@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Tue, 27 Apr 2021 23:48:58 -0000 On 2021-04-27 18:21, Carsten Bormann wrote: > On 2021-04-27, at 17:47, Brian Rosen wrote: >> >> There was a lot of opposition to the idea previously, > > Yes. Dear Carsten, There were indeed a lot of opposition at IETF-104 but nobody has to date bothered providing a single example showing why this idea {w|sh}ould not work [1]. If we take the better [and fully standardized] alternative (JWS), it transforms a JSON object into a Base64Url-encoded string and then puts it into a specific signature container. That is, the result bears very little similarity to the original which obviously is a drawback. Then a [moderately] skillful attacker replaces the algorithm in the JWS header with the standardized "none" and the whole thing passes validation with flying colors [2]. Anyway, variants of detached (enveloped) JWS signatures in JSON are likely to become a de-facto standard. Here is an example from a very active group withing the W3C: https://w3c-ccg.github.io/ld-proofs/#example-2-a-simple-signed-linked-data-document Feel free rearchitecting https://fido-web-pay.github.io/ using the current JOSE stack; it might even be fun :) BTW, I have just started the design of a CBOR library needed for dealing with CTAP2/FIDO for the project above. CBOR seems pretty cool. Regards, Anders 1] In all fairness, it does require a bit of work for the application developer who may have to adjust the parsing scheme (not the parser) for things like RFC3339 data. 2] In a n00b world, where developers do not understand that a compliant JWS library does not necessarily come with suitable default policies. > > But there is also some opposition to the weird way this is presented: > >>> On Apr 27, 2021, at 11:27 AM, Bret Jordan wrote: >>> JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing). > > We have a lot of ways that enable signed objects to remain in the format in which they were at signature time. > > Maybe we can fix the presentation of the idea more towards “we really liked XMLDsig and want it back for JSON”, which is certainly a position one can take. > > Grüße, Carsten > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Apr 27 18:39:26 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 C9CA13A0D12; Tue, 27 Apr 2021 18:39:17 -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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 HIkFvXT5-N-h; Tue, 27 Apr 2021 18:39:13 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 A7FCF3A0D06; Tue, 27 Apr 2021 18:39:12 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id b23so14034673lfv.8; Tue, 27 Apr 2021 18:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0LlPwsYif1ZdRk37XhKly0/3Vk0+Il3lcnWntqEHkFY=; b=LkhdzZPvGAng3qQAX0ZwvLZW9l1gQK36exdwWmKJlZFZs5ByClGuHgeAwodBYfA13Y OKIbBveJXFZ1dNV+51HyeB65Vu4X0DYGsXGLWi0nLBvzstZ1c2t7HrhPngWqpvFTqNsX TR1JQ7ofRnte1Gw5V3BUM5rugvA8CxQ7tgbFhMmii/WIW6kZGDODxDmSWvnfP0ZDCXqJ G22mHJvfsjF0S/PnFoqsQDI/GEJR+Qi+nOmgehT+mkiYhZszLPQyJDXewXB+fLx4p+SS C2DuNw+0RnwzHtcyI3NPvDOQZC1gtxsSUxtK8vkG4S0KFUYcp7kDVCWBZf4Ut06jNoTe 0NDQ== 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=0LlPwsYif1ZdRk37XhKly0/3Vk0+Il3lcnWntqEHkFY=; b=gckhtn99oOwOrk2jB49xtRPoGp1DqmhrZT+pcIHKc5QX/P44yDhAtUsBOI+y5Iylru DpKmIA/alxc2JCvAkY+gQDIZWRNM4e2J3LGBy+YMkv5i+6DGg9sYK9WPaP9Db9wXvDfk mO0VEGoFmZu3DqSi2/VhEDUGBrRmxvXzUA95JldtK8mSP7DFSxY/wPG0skBFEvUAo0Ze KlG7qRgZrHyqU/F3ZLLjbGS2kzrSbO4WfcFMvSH01/NudYSmqZI7sn4saiwGj5gWMzM4 5EXoNwDV6X3vxEF3D+VqIQAr64LmRcgw5uYL8eUBEFEpy2bZ5UWKV+ncQf9h8mmTcQZ7 wDEg== X-Gm-Message-State: AOAM532zu8xI0PUtth2DYBxfOcIWW6Y7z7HVwPzRsIhWWvyBb+R7fkLo D9zlb2RumCItviw19KhxcaN7Kj25xfj/d9MKmjM= X-Google-Smtp-Source: ABdhPJw8f5eT1yM5MK/Ggfat3cQ3wyTcYolJiPv06wYMOyOecG7fHYeQkelj4Cu+KrqZh468QqAqHi1ZRKNT/CrXsYg= X-Received: by 2002:a05:6512:92e:: with SMTP id f14mr18721818lft.347.1619573949962; Tue, 27 Apr 2021 18:39:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 27 Apr 2021 18:38:33 -0700 Message-ID: To: Bret Jordan Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org Content-Type: multipart/alternative; boundary="000000000000f9a0a505c0fe71c7" Archived-At: Subject: Re: [Secdispatch] [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: Wed, 28 Apr 2021 01:39:18 -0000 --000000000000f9a0a505c0fe71c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS. Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing. For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token. Our requirements were: - URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted= ) - HTTP header safe - richer than name / value pairs Options we considered: ASN.1 - the 60s are calling and want their data back XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages) JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist. Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set. And Simple Web Tokens were born -- to be renamed JSON Web Tokens. /Dick =E1=90=A7 On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote: > Dear Dispatch, > > Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for > your consideration. This document describes how to use JWS and JCS to > create plain-text JSON signatures. The abstract reads as follows: > > This document describes a method for extending the scope of the JSON Web > Signature (JWS) standard, called JWS/CT. By combining the detached mode = of > JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON > objects to remain in the JSON format after being signed (aka "Clear Text" > signing). In addition to supporting a consistent data format, this > arrangement also simplifies documentation, debugging, and logging. The > ability to embed signed JSON objects in other JSON objects, makes the use > of counter-signatures straightforward. > > The data tracker page for this: > https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ > > As you know there are large ecosystems that needs digital signatures for > plain text JSON data, meaning where the JSON data is not base64 encoded. > This ID provides a solution using existing IETF RFCs to make this work. > Further, this work looks to be adopted by many groups and organizations > from financial services, threat intelligence, and incident response. > > We are not sure what direction would be best for this work in the IETF, > should we send to the ISE for publication or do you want to create a > working group. Ultimately there is a lot of work that could be done in th= is > space to meet the needs of the market. We would be happy with releasing > these IDs for ISE publication, or for creating a working group to move th= em > forward. It is just important to note that the market is in desperate nee= d > of these solutions. If you want to take it for a spin, there is a JWS/CT > playground at: https://mobilepki.org/jws-ct > > Thanks > Bret > > -- > > Sent from my TI-99/4A > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --000000000000f9a0a505c0fe71c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am supportive of this work, and would also be willing to= work towards a PS. I am seeing rapid growth in the demand to embed JWS in = JWS.

Given my experience with XML-DSig (see below) makin= g it more XML-DSig like does not sound like a good thing.
=C2=A0
For any interested=C2=A0in some JWT history, when we were brewing up = what became OAuth 2.0, we did not want to tie a token format to the impleme= ntation as many deployments had their own proprietary token formats -- but = we knew new deployments would benefit=C2=A0from standardizing a token.

Our requirements were:
- URL safe (access to= kens at the time were often passed as a query parameter=C2=A0-- I know, not= the best idea, but working=C2=A0with what people wanted)
- HTTP = header safe
- richer than name / value pairs

=
Options we considered:
ASN.1 - the 60s are calling and want = their data back
XML-DSig - not URL safe, large size, and I person= ally had many scars canonicalizing XML. (An earlier company of mine had a c= ontract to build XML-DSig libraries for a few languages)
=C2=A0
JSON was becoming very cool at that time, and with base 64 URL saf= e encoding the string, it was URL safe, and treating the JSON text as binar= y dealt with the canonicalization concerns -- and JSON canonicalization did= not exist.

Using a dot as the separator=C2=A0betw= een header, payload, and signature made it easy to parse. The dot was URL s= afe, but not in the base 64 set.

And Simple Web To= kens were born -- to be renamed JSON Web Tokens.

/= Dick




=E1=90=A7

On Tue, Apr 27, 2021 at 8:28 AM Bre= t Jordan <jor= dan.ietf@gmail.com> wrote:
Dear Dispatch,

Anders Rundgren, S= amuel, Erdtman, and I have been working on an ID for your consideration. Th= is document describes how to use JWS and JCS to create plain-text JSON sign= atures. The abstract reads as follows:

This document describes a met= hod for extending the scope of the JSON Web Signature (JWS) standard, calle= d JWS/CT.=C2=A0 By combining the detached mode of JWS with the JSON Canonic= alization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON f= ormat after being signed (aka "Clear Text" signing).=C2=A0 In add= ition to supporting a consistent data format, this arrangement also simplif= ies documentation, debugging, and logging.=C2=A0 The ability to embed signe= d JSON objects in other JSON objects, makes the use of counter-signatures s= traightforward.

The data tracker page for this: https://dat= atracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are= large ecosystems that needs digital signatures for plain text JSON data, m= eaning where the JSON data is not base64 encoded. This ID provides a soluti= on using existing IETF RFCs to make this work. Further, this work looks to = be adopted by many groups and organizations from financial services, threat= intelligence, and incident response.

We are not sure what directio= n would be best for this work in the IETF, should we send to the ISE for pu= blication or do you want to create a working group. Ultimately there is a l= ot of work that could be done in this space to meet the needs of the market= . We would be happy with releasing these IDs for ISE publication, or for cr= eating a working group to move them forward. It is just important to note t= hat the market is in desperate need of these solutions. If you want to take= it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct

<= /div>
Thanks
Bret

--

Sent from my TI-99/4A
PGP Fingerprint:= =C2=A063B4 FC53 680A 6B7D 14= 47 =C2=A0F2C0 74F8 ACAE=C2=A07415 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--000000000000f9a0a505c0fe71c7-- From nobody Tue Apr 27 19:29:22 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 66EC83A1062; Tue, 27 Apr 2021 19:29:12 -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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 P3B8DUKI29gA; Tue, 27 Apr 2021 19:29:07 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 45C583A1060; Tue, 27 Apr 2021 19:29:07 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id v191so921588pfc.8; Tue, 27 Apr 2021 19:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ImyPWRB0TPrgYbHBaH1s6y5suW8JVeP8WJQwwdM+NuE=; b=uldO5ph3HQ6tize5lfZnibljd4hfjiw2dVFg0AySJWsBh8qzNs8ovo8PoyDuUQrm0U JiPJHYtI8VIA1WK5Y6sRPr80ybhGWhZHFznH8jU4Bw4JIMShLZgtvokDjxcBA4gwTyX8 C0h/PGbS6Ml3fZvQQRrS8shOJjV2NRo1VfMrNBLT/+fwtjEgMgvZHu3WpFdLt8Ur3PbX UH+n/7b6W0CiG8I1LA8PNTaZnFLQXYJ1euZAtv8nrV9cIVBmMLfqsxHT91n9QheXmpOF /DYJudYhRkk38h88es2lBPecuF8O6lik+5ET7W8Vs1S5gC5Mi+nUqv5CNPzrqHNyD6fm K2gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ImyPWRB0TPrgYbHBaH1s6y5suW8JVeP8WJQwwdM+NuE=; b=Gqn3/xO8tO9IigTYw2xJppBNk/HjNE5QHJ+3Xrkh2l2G0GBoH58l/qrJiQ8IRasg78 DeFn1QIifVHsy7FQGeAuahvhqkJrhebGHNQiMCvEpeHKVKJOLYNdMrTwxCFxTZz4Hzea oCTu2UQtDPxG7O/KMWpJwr1IBrBF/wZina+jvpmI61TY0FCgOMusDuuROu4mRB2m/d0p gy9aOAoQvjGiPJ4Tfkw6GAi+JFlsMZX7fEU+HRpyzHBFMVznJPOudlV3STmOOVJ+yuah d+Zr+Djf8PRbQ3/OR/jTnZJuSoOUND8SZmG9n2B5oym8IS5FwwhJoa52mSLGIYW2tCCf sTRg== X-Gm-Message-State: AOAM531CSlAILe+nUO6G7gZu7ttMCbrowRvGZPlTXvenvHSWK+0WvDGs CIy9rGi4xPIrdP/L28LUMctidDQ6JG0= X-Google-Smtp-Source: ABdhPJwu0LDVUuFHjGFhT23YsF+2R0tGCe4+j3y7BQy8+St96kdI5/f+HbAIQrjd+koMElDjBRjpjw== X-Received: by 2002:a63:6c06:: with SMTP id h6mr25448864pgc.95.1619576945200; Tue, 27 Apr 2021 19:29:05 -0700 (PDT) Received: from [10.128.64.110] ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id gf21sm3535887pjb.20.2021.04.27.19.29.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Apr 2021 19:29:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6 Content-Transfer-Encoding: 7bit From: Bret Jordan Mime-Version: 1.0 (1.0) Date: Tue, 27 Apr 2021 20:29:03 -0600 Message-Id: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> References: Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (18D70) Archived-At: Subject: Re: [Secdispatch] [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: Wed, 28 Apr 2021 02:29:13 -0000 --Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Luckily this time we have RFC8785 that solves the canonicalization problem f= or JSON.=20 Bret=20 Sent from my Commodore 64 PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >=20 > =EF=BB=BF > I am supportive of this work, and would also be willing to work towards a P= S. I am seeing rapid growth in the demand to embed JWS in JWS. >=20 > Given my experience with XML-DSig (see below) making it more XML-DSig like= does not sound like a good thing. > =20 > For any interested in some JWT history, when we were brewing up what becam= e OAuth 2.0, we did not want to tie a token format to the implementation as m= any deployments had their own proprietary token formats -- but we knew new d= eployments would benefit from standardizing a token. >=20 > Our requirements were: > - URL safe (access tokens at the time were often passed as a query paramet= er -- I know, not the best idea, but working with what people wanted) > - HTTP header safe > - richer than name / value pairs >=20 > Options we considered: > ASN.1 - the 60s are calling and want their data back > XML-DSig - not URL safe, large size, and I personally had many scars canon= icalizing XML. (An earlier company of mine had a contract to build XML-DSig l= ibraries for a few languages) > =20 > JSON was becoming very cool at that time, and with base 64 URL safe encodi= ng the string, it was URL safe, and treating the JSON text as binary dealt w= ith the canonicalization concerns -- and JSON canonicalization did not exist= . >=20 > Using a dot as the separator between header, payload, and signature made i= t easy to parse. The dot was URL safe, but not in the base 64 set. >=20 > And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >=20 > /Dick >=20 >=20 >=20 >=20 > =E1=90=A7 >=20 >> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote= : >> Dear Dispatch, >>=20 >> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for yo= ur consideration. This document describes how to use JWS and JCS to create p= lain-text JSON signatures. The abstract reads as follows: >>=20 >> This document describes a method for extending the scope of the JSON Web S= ignature (JWS) standard, called JWS/CT. By combining the detached mode of J= WS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects t= o remain in the JSON format after being signed (aka "Clear Text" signing). I= n addition to supporting a consistent data format, this arrangement also sim= plifies documentation, debugging, and logging. The ability to embed signed J= SON objects in other JSON objects, makes the use of counter-signatures strai= ghtforward. >>=20 >> The data tracker page for this: https://datatracker.ietf.org/doc/draft-jo= rdan-jws-ct/ >>=20 >> As you know there are large ecosystems that needs digital signatures for p= lain text JSON data, meaning where the JSON data is not base64 encoded. This= ID provides a solution using existing IETF RFCs to make this work. Further,= this work looks to be adopted by many groups and organizations from financi= al services, threat intelligence, and incident response.=20 >>=20 >> We are not sure what direction would be best for this work in the IETF, s= hould we send to the ISE for publication or do you want to create a working g= roup. Ultimately there is a lot of work that could be done in this space to m= eet the needs of the market. We would be happy with releasing these IDs for I= SE publication, or for creating a working group to move them forward. It is j= ust important to note that the market is in desperate need of these solution= s. If you want to take it for a spin, there is a JWS/CT playground at: https= ://mobilepki.org/jws-ct >>=20 >> Thanks >> Bret >>=20 >> --=20 >>=20 >> Sent from my TI-99/4A >>=20 >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art --Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Luckily this time we have RFC8785 that solv= es the canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C= 0 74F8 ACAE 7415 0050

<= blockquote type=3D"cite">On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.ha= rdt@gmail.com> wrote:

=EF=BB=BF
I am supportive of this work, an= d would also be willing to work towards a PS. I am seeing rapid growth in th= e demand to embed JWS in JWS.

Given my experience with XM= L-DSig (see below) making it more XML-DSig like does not sound like a good t= hing.
 
For any interested in some JWT history, wh= en we were brewing up what became OAuth 2.0, we did not want to tie a token f= ormat to the implementation as many deployments had their own proprietary to= ken formats -- but we knew new deployments would benefit from standardi= zing a token.

Our requirements were:
- UR= L safe (access tokens at the time were often passed as a query parameter&nbs= p;-- I know, not the best idea, but working with what people wanted)
- HTTP header safe
- richer than name / value pairs
<= div>
Options we considered:
ASN.1 - the 60s are call= ing and want their data back
XML-DSig - not URL safe, large size, a= nd I personally had many scars canonicalizing XML. (An earlier company of mi= ne had a contract to build XML-DSig libraries for a few languages)
 
JSON was becoming very cool at that time, and with base 64= URL safe encoding the string, it was URL safe, and treating the JSON text a= s binary dealt with the canonicalization concerns -- and JSON canonicalizati= on did not exist.

Using a dot as the separator = ;between header, payload, and signature made it easy to parse. The dot was U= RL safe, but not in the base 64 set.

And Simple Web= Tokens were born -- to be renamed JSON Web Tokens.

/Dick




=E1=90=A7

On Tue, Apr 27= , 2021 at 8:28 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dear Dispatch,

A= nders Rundgren, Samuel, Erdtman, and I have been working on an ID for your c= onsideration. This document describes how to use JWS and JCS to create plain= -text JSON signatures. The abstract reads as follows:

This document d= escribes a method for extending the scope of the JSON Web Signature (JWS) st= andard, called JWS/CT.  By combining the detached mode of JWS with the J= SON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in t= he JSON format after being signed (aka "Clear Text" signing).  In addit= ion to supporting a consistent data format, this arrangement also simplifies= documentation, debugging, and logging.  The ability to embed signed JS= ON objects in other JSON objects, makes the use of counter-signatures straig= htforward.

The data tracker page for this: https://datatracke= r.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large e= cosystems that needs digital signatures for plain text JSON data, meaning wh= ere the JSON data is not base64 encoded. This ID provides a solution using e= xisting IETF RFCs to make this work. Further, this work looks to be adopted b= y many groups and organizations from financial services, threat intelligence= , and incident response.

We are not sure what direction would be bes= t for this work in the IETF, should we send to the ISE for publication or do= you want to create a working group. Ultimately there is a lot of work that c= ould be done in this space to meet the needs of the market. We would be happ= y with releasing these IDs for ISE publication, or for creating a working gr= oup to move them forward. It is just important to note that the market is in= desperate need of these solutions. If you want to take it for a spin, there= is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415= 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
= --Apple-Mail-01B157E7-5699-4FBC-BA95-089ED16BBAC6-- From nobody Wed Apr 28 00:01: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 B40BD3A1D01 for ; Wed, 28 Apr 2021 00:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 bm0E4MdJb80m for ; Wed, 28 Apr 2021 00:01:51 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9753A1CFA for ; Wed, 28 Apr 2021 00:01:49 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with UTF8SMTP id 2FBC41A92211 for ; Wed, 28 Apr 2021 08:52:07 +0200 (CEST) Received: from s630.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with UTF8SMTP id 1E62B2E2B083; Wed, 28 Apr 2021 08:52:07 +0200 (CEST) Received: from s475.loopia.se (unknown [172.22.191.5]) by s630.loopia.se (Postfix) with UTF8SMTP id CA91213B9437; Wed, 28 Apr 2021 08:52:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s934.loopia.se ([172.22.191.5]) by s475.loopia.se (s475.loopia.se [172.22.190.15]) (amavisd-new, port 10024) with UTF8LMTP id e98z6PW06j4v; Wed, 28 Apr 2021 08:52:05 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.219] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s934.loopia.se (Postfix) with UTF8SMTPSA id 46D997CEA0F; Wed, 28 Apr 2021 08:52:05 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------2LurtlQsQhRwHdctf4Ws9n0f" Message-ID: <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> Date: Wed, 28 Apr 2021 08:52:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Thunderbird/88.0 Content-Language: en-US To: Bret Jordan , Dick Hardt Cc: art@ietf.org, DISPATCH , rfc-ise@rfc-editor.org, IETF SecDispatch References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> From: Stefan Santesson Organization: 3xA Security AB In-Reply-To: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> Archived-At: Subject: Re: [Secdispatch] [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: Wed, 28 Apr 2021 07:01:56 -0000 This is a multi-part message in MIME format. --------------2LurtlQsQhRwHdctf4Ws9n0f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload? /Stefan On 2021-04-28 04:29, Bret Jordan wrote: > Luckily this time we have RFC8785 that solves the canonicalization > problem for JSON.  > > Bret  > > Sent from my Commodore 64 > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > >> On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >> >>  >> I am supportive of this work, and would also be willing to work >> towards a PS. I am seeing rapid growth in the demand to embed JWS in >> JWS. >> >> Given my experience with XML-DSig (see below) making it more XML-DSig >> like does not sound like a good thing. >>   >> For any interested in some JWT history, when we were brewing up what >> became OAuth 2.0, we did not want to tie a token format to the >> implementation as many deployments had their own proprietary token >> formats -- but we knew new deployments would benefit from >> standardizing a token. >> >> Our requirements were: >> - URL safe (access tokens at the time were often passed as a query >> parameter -- I know, not the best idea, but working with what >> people wanted) >> - HTTP header safe >> - richer than name / value pairs >> >> Options we considered: >> ASN.1 - the 60s are calling and want their data back >> XML-DSig - not URL safe, large size, and I personally had many scars >> canonicalizing XML. (An earlier company of mine had a contract to >> build XML-DSig libraries for a few languages) >>   >> JSON was becoming very cool at that time, and with base 64 URL safe >> encoding the string, it was URL safe, and treating the JSON text as >> binary dealt with the canonicalization concerns -- and JSON >> canonicalization did not exist. >> >> Using a dot as the separator between header, payload, and signature >> made it easy to parse. The dot was URL safe, but not in the base 64 set. >> >> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >> >> /Dick >> >> >> >> >> ᐧ >> >> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan >> wrote: >> >> Dear Dispatch, >> >> Anders Rundgren, Samuel, Erdtman, and I have been working on an >> ID for your consideration. This document describes how to use JWS >> and JCS to create plain-text JSON signatures. The abstract reads >> as follows: >> >> This document describes a method for extending the scope of the >> JSON Web Signature (JWS) standard, called JWS/CT.  By combining >> the detached mode of JWS with the JSON Canonicalization Scheme >> (JCS), JWS/CT enables JSON objects to remain in the JSON format >> after being signed (aka "Clear Text" signing).  In addition to >> supporting a consistent data format, this arrangement also >> simplifies documentation, debugging, and logging.  The ability >> to embed signed JSON objects in other JSON objects, makes the use >> of counter-signatures straightforward. >> >> The data tracker page for this: >> https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >> >> As you know there are large ecosystems that needs digital >> signatures for plain text JSON data, meaning where the JSON data >> is not base64 encoded. This ID provides a solution using existing >> IETF RFCs to make this work. Further, this work looks to be >> adopted by many groups and organizations from financial services, >> threat intelligence, and incident response. >> >> We are not sure what direction would be best for this work in the >> IETF, should we send to the ISE for publication or do you want to >> create a working group. Ultimately there is a lot of work that >> could be done in this space to meet the needs of the market. We >> would be happy with releasing these IDs for ISE publication, or >> for creating a working group to move them forward. It is just >> important to note that the market is in desperate need of these >> solutions. If you want to take it for a spin, there is a JWS/CT >> playground at: https://mobilepki.org/jws-ct >> >> Thanks >> Bret >> >> -- >> >> Sent from my TI-99/4A >> >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 >> 0050 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --------------2LurtlQsQhRwHdctf4Ws9n0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload?

/Stefan


On 2021-04-28 04:29, Bret Jordan wrote:
Luckily this time we have RFC8785 that solves the canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS.

Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing.
 
For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token.

Our requirements were:
- URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted)
- HTTP header safe
- richer than name / value pairs

Options we considered:
ASN.1 - the 60s are calling and want their data back
XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages)
 
JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist.

Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set.

And Simple Web Tokens were born -- to be renamed JSON Web Tokens.

/Dick




ᐧ

On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dear Dispatch,

Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows:

This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing).  In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging.  The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward.

The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response.

We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct

Thanks
Bret

--

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
--------------2LurtlQsQhRwHdctf4Ws9n0f-- From nobody Wed Apr 28 02:00:26 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 A3FFA3A2102; Wed, 28 Apr 2021 02:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 zG2fS327xRHc; Wed, 28 Apr 2021 02:00:15 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 C31273A2100; Wed, 28 Apr 2021 02:00:14 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 26-20020a05600c22dab029013efd7879b8so6819542wmg.0; Wed, 28 Apr 2021 02:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AnzUbNxb5tujKdkXBudu1u/IXBIzwS0gNOhT+HnKzPQ=; b=ZdC6piseFOw/QESRPtr4AEnxiZ+WxXVoeExtM08B9Ue+jmswHV7t+XL7KpCswa8bIn e1Qwj9jhC7+pOjQ2CEmssWaIYWBvrRt1LpyZKRt3jetPxImsjyuRfsUVwyOLsRmeJ4Q7 LXYKyHMJghUUctZxhq8lW1WbhxqI6ZRn9uCPjzAuGzzADQtENvky7qAvcpuT4iD32KP4 +sZaj6O9n2gHdH7+X27lURdQe5KUn29t68XW4sRe+BJcjWEt2Ia3dpQYL20PKif+GiH0 Et26GtYreBq9vvA9Lz9RUNN67gMuGxvvrkV1xeIg6QHDEGWENmfEGGiz4/9JImvgID2m 57rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AnzUbNxb5tujKdkXBudu1u/IXBIzwS0gNOhT+HnKzPQ=; b=ANe+LsVw6ZHFw6gg03kH+4W2DgkWW0wknmMhZdiVGCzM0f2yAjw01pT/l3BNT5V3wf BOZ8pqG3LmnQ0mH8emSqeOrP4w8aGyWA0TyVFY5EqVFuS3WI9/3thdmNbdHTd81MXY1C n//CMulQh49GjYtzTBHYjoMXgEPTbcJ6lJxt4NyyNECYk8E8/GzbG6bWcXRHS2yArQls UwyoUIlRfEBZilwysKYDVa429Ga3C3PmZ6FbKd2AgUvl/YoGMfI4lQwn5JGHCUTJygMV hTh9jaMzxtyzqxvUqWz0sQYYdZIjj8SusO/CEYEu+Z/v8c0fSgRcfrGE8m2k03rZnIkW DAQQ== X-Gm-Message-State: AOAM531ZtMWI8+ciIm8s4cDVFl4CvF0YTyfgR1ij7p4ewsDV1gkYnmYK wWWrSIEObRPfE6aeWbM+xkg= X-Google-Smtp-Source: ABdhPJxJTKzpX1hhkYmixGh4ZMiDrlS6BVDv7nFDlEDWojXG1jqW9vSZ8Zn/K4DTAW8SPdzNZPxHbA== X-Received: by 2002:a7b:c05a:: with SMTP id u26mr3140166wmc.172.1619600408064; Wed, 28 Apr 2021 02:00:08 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d5sm7256303wrv.43.2021.04.28.02.00.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 02:00:07 -0700 (PDT) From: Anders Rundgren To: Stefan Santesson Cc: art@ietf.org, IETF SecDispatch , DISPATCH , rfc-ise@rfc-editor.org References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> Message-ID: <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> Date: Wed, 28 Apr 2021 11:00:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Wed, 28 Apr 2021 09:00:20 -0000 On 2021-04-28 8:52, Stefan Santesson wrote: > How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload? Good question! Apart from the fact that the data becomes embedded in the JWS signature container (=changing the structure), you cannot really put JSON there: https://tools.ietf.org/html/rfc7797#section-5.2 My guess that the only real-world use of this option is to save an internal-only (but technically redundant) Base64Url-operation for truly detached data, be it it JSON, PNG, etc. JWS/CT was designed for signing JSON Objects ({}), and let them remain as such. Thanx, Anders > > /Stefan > > > On 2021-04-28 04:29, Bret Jordan wrote: >> Luckily this time we have RFC8785 that solves the canonicalization problem for JSON. >> >> Bret >> >> Sent from my Commodore 64 >> >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >> >>> On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >>> >>>  >>> I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS. >>> >>> Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing. >>> >>> For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token. >>> >>> Our requirements were: >>> - URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted) >>> - HTTP header safe >>> - richer than name / value pairs >>> >>> Options we considered: >>> ASN.1 - the 60s are calling and want their data back >>> XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages) >>> JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist. >>> >>> Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set. >>> >>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >>> >>> /Dick >>> >>> >>> >>> >>> ᐧ >>> >>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote: >>> >>> Dear Dispatch, >>> >>> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for your consideration. This document describes how to use JWS and JCS to create plain-text JSON signatures. The abstract reads as follows: >>> >>> This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT.  By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (aka "Clear Text" signing).  In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging.  The ability to embed signed JSON objects in other JSON objects, makes the use of counter-signatures straightforward. >>> >>> The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >>> >>> As you know there are large ecosystems that needs digital signatures for plain text JSON data, meaning where the JSON data is not base64 encoded. This ID provides a solution using existing IETF RFCs to make this work. Further, this work looks to be adopted by many groups and organizations from financial services, threat intelligence, and incident response. >>> >>> We are not sure what direction would be best for this work in the IETF, should we send to the ISE for publication or do you want to create a working group. Ultimately there is a lot of work that could be done in this space to meet the needs of the market. We would be happy with releasing these IDs for ISE publication, or for creating a working group to move them forward. It is just important to note that the market is in desperate need of these solutions. If you want to take it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct >>> >>> Thanks >>> Bret >>> >>> -- >>> >>> Sent from my TI-99/4A >>> >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >>> _______________________________________________ >>> art mailing list >>> art@ietf.org >>> https://www.ietf.org/mailman/listinfo/art >>> >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 28 02:21:25 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 5D6CD3A21B6; Wed, 28 Apr 2021 02:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 RSLzxYa5FP9h; Wed, 28 Apr 2021 02:21:14 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110066.outbound.protection.outlook.com [40.107.11.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0611C3A21E4; Wed, 28 Apr 2021 02:21:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S9bcuZlzV7jisr31RKXbI9fU2PhEeMOk4gawqcTH6YV5UK+x4FkCdIcFmI7YnO9kPwSjT6ra5vsIbwjBjIoOflxwF9blwqXDjPGXfsMJPf8H96kDGwR9N/hr3rVq9El20H1kFkEZQKpXi6o7n0IuAKiFyhAhCAXYQ/8ur/4hBGGtnOiiaQntagHhJrpzxUkb5+TSMftKMdS6w6aTMUz1Ryo/6/90/TLR6VTe89w5Zyxac+/AViovlhAQfXJUswe7cgdGC6/YGcbT1QcG4UJ9Uno8CIGa65rpj435EfmqKLBu24zrMRnVBgX+972fDtYTaoHVDm8xa3XxQSo4QI0cdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IY+D3HAZtUcjiYW/rWlGxZx3V7M/nyswEH2pGRXCNjI=; b=cvqPHLfQdkCZIuwRpQ9M6r0mkIEYWpIP0u8Z6K6kVQwmy/6unOuDXIME/t0zldROpj95Dg6M7eFImVqwG1cwl75flXth9h8wTbqgzl9hEZLOu9EHVDlNJAtlR6DWfm8S9uTc38GPdxWnMxiC8WjC4rzgxZMxT3af2N5BcsS1BgXIs9dMTXKieOpkf2oGBcpQ8qE7RgAQ7uca1Xg3okiczkDwnvuGYlFHhPFGKt/ekZnrzEJpKRKTbCYc9W71c+KuF+oJlaRRgMKoCm85SXB5Zpi1xbbDpsuIRcWIoJ/22x68jLPM2s+92WjC1uDZQBOv1VmFSVr8Ayuvakyq0H3zng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LO2P265MB3514.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:1a3::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Wed, 28 Apr 2021 09:21:10 +0000 Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4065.027; Wed, 28 Apr 2021 09:21:10 +0000 From: Stian Soiland-Reyes To: Bret Jordan , Dick Hardt CC: "art@ietf.org" , DISPATCH , "rfc-ise@rfc-editor.org" , IETF SecDispatch Thread-Topic: [art] Plain text JSON digital signatures Thread-Index: AQHXO3n9Ux7vg67F8E+dTqNYh8wUoarJJ3GAgAAOHICAAIPpAA== Date: Wed, 28 Apr 2021 09:21:10 +0000 Message-ID: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> In-Reply-To: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=manchester.ac.uk; x-originating-ip: [2001:8b0:a657:68e3:4d0d:8981:d3ab:c2c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 443c858e-811a-489f-76b8-08d90a26f64a x-ms-traffictypediagnostic: LO2P265MB3514: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +089s9coeIKCtVAfKJvCPKfoRx3lv2QqxRiJGnFOg4Lj0DBuNz9BwtM5KKlTj/m0XWaQJCyhbvumiuvzqPh+KMn0JsN1BanxyL+BjbjSLYaogyu67GYCsykr+f4P8XKQYix3RkFhGy3tU69yF1HaVy+kEF025KqfL6BNyf1pmsHfNms0WfQbmKRhB2fiIuXEsv2MftpjAf3sz7fTV7JE6+sqNaXoiO2EqYT6L68N5ctZ7cTMfTV9zgjqEmILfOdYeURA2rJkp1SPTRicTjXzmZ65C9lbXuQw2YOKDaax+79npSC1KtE097XuBvQ5E4HunGJxjuZhvl60hizFmz9iqzq3YFivXNx7+rEmb50Bdf0zlcmgkM0LU3DQSZW6qPS5vt7G2p7rGyG42I9PuAv5tveX66JwmqtV5k+lWtO0yOmWgB2LyVxTIqsjrYLqUrclCBUnOMqv7TwEzt9AWW+kz/HbvTmeFo+jTnMkFUoepzlhszBNw7DsJvCJ5OHEY3LXlNrfzU03BvcfJjHMrX+hhOy+plj5hSlKrNtkuwA2crRsEd9LQjZdVYEjqf8BxMNeN9Xg9oHBrbRDs5mRcx/nWguBHUkcj5SSRRrUpuqoQgKbZ6TgTvgwKaQxPRZttnZXRBOk3YtqxrXy8v2DB57SoiyXg8OVf/3GybkeS7djgM6j59tMnPN/TeH4IA96ar/HHdIHNM4wg3Z9X0Pk9ocaWiFiXfP5bwI4PkEHFS5WHg4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(86362001)(33656002)(8676002)(8936002)(6512007)(21615005)(6506007)(2616005)(122000001)(5660300002)(71200400001)(53546011)(166002)(2906002)(36756003)(76116006)(4326008)(66946007)(110136005)(66476007)(6486002)(66446008)(186003)(64756008)(966005)(478600001)(66556008)(786003)(83380400001)(38100700002)(316002)(54906003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UnZWTzlMSkpNakZoaHNOVFFwdGtMZzk1bUxMcVNlakxkcC9CMzFsZm1oRDhM?= =?utf-8?B?UnhreFQyZW80TVp6aGVaeWF4Z1dmNVVBc1A2ZU9keVo4OWJLYjhRRkdvdFZ2?= =?utf-8?B?M1N1N21UakhjZTJVZ2lCMVVCanRWY0xpdWtTdTRRQUIyM09GbjNxZVZnMTgy?= =?utf-8?B?aFprS3hIZ0xHT1FuNEVwYlh1WC9nQ0MxYU9sNjJFOFZOSEw0NWNndUl0QWhT?= =?utf-8?B?VnlXQ09MbUJuRDh3Y00xZUgzcjJTb2szYzhURUY3K1cwYlJiaDZCNXBUU0F2?= =?utf-8?B?YmIzaXJQanRlMVU4akI5T2t4QUFIMGt0RDRsVFVMWmxQaDFDY291YUg3VjJK?= =?utf-8?B?S3pUcTJFZE1QeGlxRkxmdThxK3BuQTMxaTFsMlphY3J0d2tiaXdReDVpZ2t3?= =?utf-8?B?UkpvZVNRN2R3bW10WDU5czB5YklOeXNMOXlzUFlPUk1LL09iR3NIOWhLRlpG?= =?utf-8?B?aWNxcXBvRFh0a0lqbjVSdFF6SDhBd0t6NkgybHhTK0dRaTV0YmczT0pWcEl0?= =?utf-8?B?VVRDMXVwWnNhUVVQanBSUTBQeDd4YmtrOXo1NUhxMDhRTVV4UnhOeDVtUnBS?= =?utf-8?B?STZib1pGc256eDJuOHFFTUx5OXhyVnNqaWJrbUk3WC9aVU04dHlFOWo3c1lz?= =?utf-8?B?K1pLeVprR2hjb1JybDZtUCtXVVg4NWZGYjFFRVpLS1lOUkxJZXF2U1EzZlZD?= =?utf-8?B?dHJXTTJ2OWpzV2pGRzJhSVkwVGF5N2xINmdySXpGeStEN3ErSnJhbUFqMDdK?= =?utf-8?B?Q0tlVkdoR0NqMUUzYktQWEVIK3RhdnlUYm1WZllLc0RiQ0pGTnZESHRHc3Fz?= =?utf-8?B?TW9aNjVCSzJIQzVub0dJVm40N0N2NmkrQ2QxUWo0dFhrdnB6Z1NGWFp4YkhO?= =?utf-8?B?UGQ2VlVrM01IbVVUYXcyM0thWWwyQmZ6Z3g4YlBlV1NGekpEMHU1QWtGN0tM?= =?utf-8?B?VkRaamRwWlNiTktvSDJRZWZKRWZsdndKZ29zNjJiMFZ0ZThsRTRYU0dWL2xm?= =?utf-8?B?elR3cTB5cjlGNStWcE12Tk9GY0xMTzhxSEtwelVhODd6Sjlnam84UHIyWTI0?= =?utf-8?B?Wm9qVWkra1JaK25XbGluaE5zMkI4dDluYkd3UW1lV2Q1TGtEV0hUdFpTL0c3?= =?utf-8?B?OVpEMkRZZFdoRkg1L3QyQ216a29RelRYQzd4dVgxZGJCN3NGWGV5bU5lQ3JY?= =?utf-8?B?NzA3QTM5TTBCY0gxVENJandQcjlCZHoyUUQ2QU4zN2x1MVBtUnlFMEdtNVd5?= =?utf-8?B?dkpPcmVIZWQ2M0lqbU9NVTdlcCt2aE40RkVMS3I1cUxDbmdSZDRUYjU5UzYv?= =?utf-8?B?MFhwNGZwb01sZFZVV2MxdkhOT09CWkY3WDI1aVdqdlpkTVRNeG5sQ2VGT2xJ?= =?utf-8?B?U0pXNFdWdm9zTEcrSysyU1NCUkRKTldWTWlNQ2pldUZDRThBVEhFMUxaQmNk?= =?utf-8?B?TW4zeWcxVThMQnl2NnlRMnRPVk4wQ3RrOGt2ZHV1ZEZqeFN1S2IrZGZ6N0sv?= =?utf-8?B?bGpSemtBS3RCWUthKzlsVGE1WTJxMDU2b29oT2NhWEpIaDBTelU1UjJYaXh0?= =?utf-8?B?VWsvUVlXSlRCNnhmTEtxYS93a2c4TDF0bk41T3h0dGVpUXhyeWM4T3hpL0hj?= =?utf-8?B?MVdxaW9RYUU0OGZ5Z1lsZU9Nd2xTNzVLV29FS0lrQjNMeUFBZHVRV2JEZmRW?= =?utf-8?B?MkdNeU1xTmF1MGlaK1JkSHpaUnBWdlhRNnIyUVdQMWg3VGp6ZldOaERZUExT?= =?utf-8?B?Ukx4UTlWcENmOXFJOHBPbTl5YUN1azRHVDY4SXJZUm5TL01GcmRXbElMc1ky?= =?utf-8?B?UGViaGpuK0dhbVFqMHFmcWp2TlJNaWlmSWJOVDFJQ2g2ZjVIZUxUV24yVlJm?= =?utf-8?B?TTgyUzR6d3k2THJWaURyeHZoQk9RckxWTHBZK1pNUlFCYmc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_" MIME-Version: 1.0 X-OriginatorOrg: manchester.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 443c858e-811a-489f-76b8-08d90a26f64a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 09:21:10.5710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZqETygmx1jNlAWODRrCR2Gv3u4gBCrVuCHh/tQbIHGjqmWd4q7zXZcMjzKijYnm3pju8GgON4+rkaw3XlWnb4cd9j7Immw0ReQYjVo52xFA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3514 Archived-At: Subject: Re: [Secdispatch] [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: Wed, 28 Apr 2021 09:21:21 -0000 --_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkcmFmdCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGFuIGFwcHJvYWNoIHdlIHdvdWxkIGxpa2Ug dG8gdXNlIGluIElFRUUgMjc5MSwgYW5kIGZyb20geW91ciB0ZXh0IGl0IHdpbGwgZml0IHJpZ2h0 IGludG8gb3VyIOKAnGV0YWfigJ0gZmllbGQ8aHR0cHM6Ly9vcGVuc291cmNlLmllZWUub3JnLzI3 OTEtb2JqZWN0L2llZWUtMjc5MS1zY2hlbWEvLS9ibG9iL21hc3Rlci8yNzkxb2JqZWN0Lmpzb24j TDEyOT4gd2hlcmUgd2UgaG9wZSBmb3IgYSBjb25zaXN0ZW50IGhhc2hpbmcgbWVjaGFuaXNtIHRv IGRldGVjdCBjaGFuZ2VzLg0KDQpUaGUgZHJhZnQgc2VlbXMgdG8gYnVpbGQgb24gSlNPTiBXZWIg U2lnbmF0dXJlIChSRkM3NTE1PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NTE3 Lmh0bWw+KSBhbmQgSlNPTiBXZWIgS2V5IChSRkM3NTE3PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JmYy9yZmM3NTE3Lmh0bWw+KSwgYnV0IHRoZSAzLjEuMyBpcyBhIGJpdCB0b28gYnJpZWYg Zm9yIHJlYWRlcnMgbmV3IHRvIHRoZXNlIHN0YW5kYXJkcywgcGVyaGFwcyBnaXZlIGEgYnJpZWYg c3VtbWFyeSBmb3IgdGhpcyBleGFtcGxlLCBlc3BlY2lhbGx5IGFzIFJGQzc1MTcgaXMgcXVpdGUg Y29tcHJlaGVuc2l2ZSB3aXRoIG1hbnkgb3B0aW9ucz8NCg0KSW4gcGFydGljdWxhciBpdCBpcyB1 bmNsZWFyIGlmIHRoZSBKV1MgSGVhZGVyIGFsc28gbmVlZHMgdG8gYmUgSlNPTiBjYW5vbmljYWxp emVkIOKAkyB3aGljaCBtYXkgYmUgYSBnb29kIGlkZWEgZm9yIGNvbnNpc3RlbnQg4oCcaGFzaOKA nSBwdXJwb3NlcyBsaWtlIGluIG91ciB1c2UgY2FzZT8NCg0KSGVyZeKAmXMgbXkgcm91Z2ggc3Vn Z2VzdGlvbiDigJMgcHJvYmFibHkgd3JvbmchIE15IGFkZGl0aW9ucyB1bmluZGVudGVkLg0KDQoN CjMuMS4zLiAgR2VuZXJhdGUgYSBKV1MgU3RyaW5nDQoNCg0KDQogICBVc2UgdGhlIHJlc3VsdCBv ZiB0aGUgcHJldmlvdXMgc3RlcCBhcyAiSldTIFBheWxvYWQiIHRvIHRoZSBzaWduYXR1cmUNCg0K ICAgcHJvY2VzcyBkZXNjcmliZWQgaW4gQXBwZW5kaXggRiBvZiBKV1MgW1JGQzc1MTVdLg0KDQoN Cg0KSW4gc2hvcnQgYSBkZXRhY2hlZCBKV1MgaXMgcmVwcmVzZW50ZWQgYXMgdGhlIHN0cmluZyBj b25jYXRlbmF0ZWQgZnJvbQ0KDQoNCg0KICAgICAgQkFTRTY0VVJMKFVURjgoSldTIFByb3RlY3Rl ZCBIZWFkZXIpKSB8fCAnLicgfHwNCg0KICAgICAgfHwgJy4nIHx8DQoNCiAgICAgIEJBU0U2NFVS TChKV1MgU2lnbmF0dXJlKQ0KDQoNCg0KTm90aWNlLCBmb3IgY29tcGFyaXNvbiB3aXRoIHRoZSBK V1MgQ29tcGFjdCBTZXJpYWxpemF0aW9uLA0KDQp0aGF0IHRoZSBKV1MgUGF5bG9hZCBpcyBub3Qg aW5jbHVkZWQgaW4gdGhlIGRldGFjaGVkIEpXUyBTdHJpbmcsDQoNCmJ1dCByZXBsYWNlZCBieSBh biBlbXB0eSBzdHJpbmcuDQoNCg0KDQogICBGb3IgdGhlIGV4YW1wbGUsIHRoZSBKV1MgaGVhZGVy IGlzIGFzc3VtZWQgdG8gYmU6DQoNCg0KDQogICB7ImFsZyI6IkhTMjU2In0NCg0KDQoNClRoZSBh Ym92ZSBleGFtcGxlIGlzIGVxdWFsIHRvIGl0cyBvd24gSkNTIGNhbm9uaWNhbGl6YXRpb24uDQoN CkpTT04gQ2Fub25pY2FsaXphdGlvbiBpcyBub3QgYSByZXF1aXJlbWVudCBmb3IgdGhlDQoNCkpX UyBIZWFkZXIsIGhvd2V2ZXIgdGhpcyBpcyBSRUNPTU1FTkRFRCwgY29tYmluZWQgd2l0aA0KDQph IGZpeGVkIGFsZ29yaXRobSBjaG9pY2UsIGlmIGdlbmVyYXRpbmcgYSBjb25zaXN0ZW50IEpXUy9D VCBzaWduYXR1cmUNCg0KdGhhdCBpcyBzIGFsc28gdG8gYmUgdXNlZCBhcyBhcyBhIGNhbm9uaWNh bCB2ZXJzaW9uIGlkZW50aWZpZXINCg0Kb2YgdGhlIEpTT04gcGF5bG9hZCBjb250ZW50LCBlLmcu IGFzIGEgc3Ryb25nIEVUYWcgKFJGQzcyMzIpLg0KDQoNCg0KVGhlIEpXUyBTaWduYXR1cmUgb2Yg dGhlIGNhbm9uaWNhbGl6ZWQgSlNPTiBwYXlsb2FkLCB1c2luZyB0aGUga2V5DQoNCnNwZWNpZmll ZCBpbiBTZWN0aW9uIDMsIGlzIHRoZSBieXRlcw0KDQoNCg0KNTQgNzUgNDggYjQgMjAgNDIgNmYg YzQgMzkgeDggOGUgM2QgOGEgNjYgYWIgeGUNCg0KZDIgNWUgNGIgMTEgZjYgYjggYjUgMzQgeGUg MWEgOTAgM2YgOTYgNjMgYzMNCg0KDQoNCg0KDQpFbmNvZGluZyBhcyBCYXNlNjQNCg0KDQoNClRo ZSByZXN1bHRpbmcgY29uY2F0ZW5hdGVkIEpXUyBzdHJpbmcgc2hvdWxkIHRoZW4gcmVhZCBhcyBm b2xsb3dzOg0KDQoNCg0KICAgZXlKaGJHY2lPaUpJVXpJMU5pSjkuLlZIVkl0Q0JDYjhRNUNJLTQ5 aW1hckR0SmVTeEgydUxVMERocVFQNVpqdzQNCg0KDQpZb3UgbWF5IHdhbnQgdG8gbW92ZSBteSBF VGFnIHJlY29tbWVuZGF0aW9uIHRvIGFuIGFwcGVuZGl4LCBhcyBJIGRvbuKAmXQgZmVlbCBpdCBm aXRzIHdlbGwgd2hlcmUgSSBwdXQgaXQsIGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIHBvaW50aW5n IG91dC4gQXMgYSB1c2UgY2FzZS4NCg0KSSBkb27igJl0IGtub3cgZW5vdWdoIGFib3V0IFJGQzc1 MTUsIGlzIGl0IHBvc3NpYmxlIHRvIGRvIHNvbWV0aGluZyBsaWtlIHJlZ3VsYXIgU0hBMyBvciB3 b3VsZCBteSBmaW5nZXJwcmludCB1c2UgY2FzZSBuZWVkIHRvIGp1c3QgcHVibGljbHkgZGVjbGFy ZSB0aGUgc2lnbmF0dXJlIGtleSB0byB1c2U/DQoNCg0KLS0NClN0aWFuIFNvaWxhbmQtUmV5ZXMs IFRoZSBVbml2ZXJzaXR5IG9mIE1hbmNoZXN0ZXINCmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9y Zy51ay8NCmh0dHBzOi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgNCiAgICBQbGVhc2Ug bm90ZSB0aGF0IEkgbWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxzdCBpdCBzdWl0cyBtZSB0byBl bWFpbCBub3csDQogICAgSSBkbyBub3QgZXhwZWN0IGEgcmVzcG9uc2Ugb3IgYWN0aW9uIG91dHNp ZGUgb2YgeW91ciBvd24gd29ya2luZyBob3Vycy4NCg0KDQpGcm9tOiBhcnQgPGFydC1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNv bT4NCkRhdGU6IFdlZG5lc2RheSwgMjggQXByaWwgMjAyMSBhdCAwMzoyOQ0KVG86IERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KQ2M6ICJhcnRAaWV0Zi5vcmciIDxhcnRAaWV0Zi5v cmc+LCBESVNQQVRDSCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAicmZjLWlzZUByZmMtZWRpdG9yLm9y ZyIgPHJmYy1pc2VAcmZjLWVkaXRvci5vcmc+LCBJRVRGIFNlY0Rpc3BhdGNoIDxTZWNkaXNwYXRj aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbYXJ0XSBQbGFpbiB0ZXh0IEpTT04gZGlnaXRhbCBz aWduYXR1cmVzDQoNCkx1Y2tpbHkgdGhpcyB0aW1lIHdlIGhhdmUgUkZDODc4NSB0aGF0IHNvbHZl cyB0aGUgY2Fub25pY2FsaXphdGlvbiBwcm9ibGVtIGZvciBKU09OLg0KDQpCcmV0DQpTZW50IGZy b20gbXkgQ29tbW9kb3JlIDY0DQoNClBHUCBGaW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEgNkI3 RCAxNDQ3ICBGMkMwIDc0RjggQUNBRSA3NDE1IDAwNTANCg0KDQpPbiBBcHIgMjcsIDIwMjEsIGF0 IDc6MzkgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiB3cm90ZToNCkkgYW0g c3VwcG9ydGl2ZSBvZiB0aGlzIHdvcmssIGFuZCB3b3VsZCBhbHNvIGJlIHdpbGxpbmcgdG8gd29y ayB0b3dhcmRzIGEgUFMuIEkgYW0gc2VlaW5nIHJhcGlkIGdyb3d0aCBpbiB0aGUgZGVtYW5kIHRv IGVtYmVkIEpXUyBpbiBKV1MuDQoNCkdpdmVuIG15IGV4cGVyaWVuY2Ugd2l0aCBYTUwtRFNpZyAo c2VlIGJlbG93KSBtYWtpbmcgaXQgbW9yZSBYTUwtRFNpZyBsaWtlIGRvZXMgbm90IHNvdW5kIGxp a2UgYSBnb29kIHRoaW5nLg0KDQpGb3IgYW55IGludGVyZXN0ZWQgaW4gc29tZSBKV1QgaGlzdG9y eSwgd2hlbiB3ZSB3ZXJlIGJyZXdpbmcgdXAgd2hhdCBiZWNhbWUgT0F1dGggMi4wLCB3ZSBkaWQg bm90IHdhbnQgdG8gdGllIGEgdG9rZW4gZm9ybWF0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhcyBt YW55IGRlcGxveW1lbnRzIGhhZCB0aGVpciBvd24gcHJvcHJpZXRhcnkgdG9rZW4gZm9ybWF0cyAt LSBidXQgd2Uga25ldyBuZXcgZGVwbG95bWVudHMgd291bGQgYmVuZWZpdCBmcm9tIHN0YW5kYXJk aXppbmcgYSB0b2tlbi4NCg0KT3VyIHJlcXVpcmVtZW50cyB3ZXJlOg0KLSBVUkwgc2FmZSAoYWNj ZXNzIHRva2VucyBhdCB0aGUgdGltZSB3ZXJlIG9mdGVuIHBhc3NlZCBhcyBhIHF1ZXJ5IHBhcmFt ZXRlciAtLSBJIGtub3csIG5vdCB0aGUgYmVzdCBpZGVhLCBidXQgd29ya2luZyB3aXRoIHdoYXQg cGVvcGxlIHdhbnRlZCkNCi0gSFRUUCBoZWFkZXIgc2FmZQ0KLSByaWNoZXIgdGhhbiBuYW1lIC8g dmFsdWUgcGFpcnMNCg0KT3B0aW9ucyB3ZSBjb25zaWRlcmVkOg0KQVNOLjEgLSB0aGUgNjBzIGFy ZSBjYWxsaW5nIGFuZCB3YW50IHRoZWlyIGRhdGEgYmFjaw0KWE1MLURTaWcgLSBub3QgVVJMIHNh ZmUsIGxhcmdlIHNpemUsIGFuZCBJIHBlcnNvbmFsbHkgaGFkIG1hbnkgc2NhcnMgY2Fub25pY2Fs aXppbmcgWE1MLiAoQW4gZWFybGllciBjb21wYW55IG9mIG1pbmUgaGFkIGEgY29udHJhY3QgdG8g YnVpbGQgWE1MLURTaWcgbGlicmFyaWVzIGZvciBhIGZldyBsYW5ndWFnZXMpDQoNCkpTT04gd2Fz IGJlY29taW5nIHZlcnkgY29vbCBhdCB0aGF0IHRpbWUsIGFuZCB3aXRoIGJhc2UgNjQgVVJMIHNh ZmUgZW5jb2RpbmcgdGhlIHN0cmluZywgaXQgd2FzIFVSTCBzYWZlLCBhbmQgdHJlYXRpbmcgdGhl IEpTT04gdGV4dCBhcyBiaW5hcnkgZGVhbHQgd2l0aCB0aGUgY2Fub25pY2FsaXphdGlvbiBjb25j ZXJucyAtLSBhbmQgSlNPTiBjYW5vbmljYWxpemF0aW9uIGRpZCBub3QgZXhpc3QuDQoNClVzaW5n IGEgZG90IGFzIHRoZSBzZXBhcmF0b3IgYmV0d2VlbiBoZWFkZXIsIHBheWxvYWQsIGFuZCBzaWdu YXR1cmUgbWFkZSBpdCBlYXN5IHRvIHBhcnNlLiBUaGUgZG90IHdhcyBVUkwgc2FmZSwgYnV0IG5v dCBpbiB0aGUgYmFzZSA2NCBzZXQuDQoNCkFuZCBTaW1wbGUgV2ViIFRva2VucyB3ZXJlIGJvcm4g LS0gdG8gYmUgcmVuYW1lZCBKU09OIFdlYiBUb2tlbnMuDQoNCi9EaWNrDQoNCg0KDQoNCltJbWFn ZSByZW1vdmVkIGJ5IHNlbmRlci5d4ZCnDQoNCk9uIFR1ZSwgQXByIDI3LCAyMDIxIGF0IDg6Mjgg QU0gQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86am9yZGFuLmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQpEZWFyIERpc3BhdGNoLA0KDQpBbmRlcnMgUnVuZGdyZW4sIFNh bXVlbCwgRXJkdG1hbiwgYW5kIEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYW4gSUQgZm9yIHlvdXIg Y29uc2lkZXJhdGlvbi4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHVzZSBKV1MgYW5k IEpDUyB0byBjcmVhdGUgcGxhaW4tdGV4dCBKU09OIHNpZ25hdHVyZXMuIFRoZSBhYnN0cmFjdCBy ZWFkcyBhcyBmb2xsb3dzOg0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3Ig ZXh0ZW5kaW5nIHRoZSBzY29wZSBvZiB0aGUgSlNPTiBXZWIgU2lnbmF0dXJlIChKV1MpIHN0YW5k YXJkLCBjYWxsZWQgSldTL0NULiAgQnkgY29tYmluaW5nIHRoZSBkZXRhY2hlZCBtb2RlIG9mIEpX UyB3aXRoIHRoZSBKU09OIENhbm9uaWNhbGl6YXRpb24gU2NoZW1lIChKQ1MpLCBKV1MvQ1QgZW5h YmxlcyBKU09OIG9iamVjdHMgdG8gcmVtYWluIGluIHRoZSBKU09OIGZvcm1hdCBhZnRlciBiZWlu ZyBzaWduZWQgKGFrYSAiQ2xlYXIgVGV4dCIgc2lnbmluZykuICBJbiBhZGRpdGlvbiB0byBzdXBw b3J0aW5nIGEgY29uc2lzdGVudCBkYXRhIGZvcm1hdCwgdGhpcyBhcnJhbmdlbWVudCBhbHNvIHNp bXBsaWZpZXMgZG9jdW1lbnRhdGlvbiwgZGVidWdnaW5nLCBhbmQgbG9nZ2luZy4gIFRoZSBhYmls aXR5IHRvIGVtYmVkIHNpZ25lZCBKU09OIG9iamVjdHMgaW4gb3RoZXIgSlNPTiBvYmplY3RzLCBt YWtlcyB0aGUgdXNlIG9mIGNvdW50ZXItc2lnbmF0dXJlcyBzdHJhaWdodGZvcndhcmQuDQoNClRo ZSBkYXRhIHRyYWNrZXIgcGFnZSBmb3IgdGhpczogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtam9yZGFuLWp3cy1jdC8NCg0KQXMgeW91IGtub3cgdGhlcmUgYXJlIGxhcmdl IGVjb3N5c3RlbXMgdGhhdCBuZWVkcyBkaWdpdGFsIHNpZ25hdHVyZXMgZm9yIHBsYWluIHRleHQg SlNPTiBkYXRhLCBtZWFuaW5nIHdoZXJlIHRoZSBKU09OIGRhdGEgaXMgbm90IGJhc2U2NCBlbmNv ZGVkLiBUaGlzIElEIHByb3ZpZGVzIGEgc29sdXRpb24gdXNpbmcgZXhpc3RpbmcgSUVURiBSRkNz IHRvIG1ha2UgdGhpcyB3b3JrLiBGdXJ0aGVyLCB0aGlzIHdvcmsgbG9va3MgdG8gYmUgYWRvcHRl ZCBieSBtYW55IGdyb3VwcyBhbmQgb3JnYW5pemF0aW9ucyBmcm9tIGZpbmFuY2lhbCBzZXJ2aWNl cywgdGhyZWF0IGludGVsbGlnZW5jZSwgYW5kIGluY2lkZW50IHJlc3BvbnNlLg0KDQpXZSBhcmUg bm90IHN1cmUgd2hhdCBkaXJlY3Rpb24gd291bGQgYmUgYmVzdCBmb3IgdGhpcyB3b3JrIGluIHRo ZSBJRVRGLCBzaG91bGQgd2Ugc2VuZCB0byB0aGUgSVNFIGZvciBwdWJsaWNhdGlvbiBvciBkbyB5 b3Ugd2FudCB0byBjcmVhdGUgYSB3b3JraW5nIGdyb3VwLiBVbHRpbWF0ZWx5IHRoZXJlIGlzIGEg bG90IG9mIHdvcmsgdGhhdCBjb3VsZCBiZSBkb25lIGluIHRoaXMgc3BhY2UgdG8gbWVldCB0aGUg bmVlZHMgb2YgdGhlIG1hcmtldC4gV2Ugd291bGQgYmUgaGFwcHkgd2l0aCByZWxlYXNpbmcgdGhl c2UgSURzIGZvciBJU0UgcHVibGljYXRpb24sIG9yIGZvciBjcmVhdGluZyBhIHdvcmtpbmcgZ3Jv dXAgdG8gbW92ZSB0aGVtIGZvcndhcmQuIEl0IGlzIGp1c3QgaW1wb3J0YW50IHRvIG5vdGUgdGhh dCB0aGUgbWFya2V0IGlzIGluIGRlc3BlcmF0ZSBuZWVkIG9mIHRoZXNlIHNvbHV0aW9ucy4gSWYg eW91IHdhbnQgdG8gdGFrZSBpdCBmb3IgYSBzcGluLCB0aGVyZSBpcyBhIEpXUy9DVCBwbGF5Z3Jv dW5kIGF0OiBodHRwczovL21vYmlsZXBraS5vcmcvandzLWN0DQoNClRoYW5rcw0KQnJldA0KDQot LQ0KDQpTZW50IGZyb20gbXkgVEktOTkvNEENCg0KDQpQR1AgRmluZ2VycHJpbnQ6IDYzQjQgRkM1 MyA2ODBBIDZCN0QgMTQ0NyAgRjJDMCA3NEY4IEFDQUUgNzQxNSAwMDUwDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXJ0IG1haWxpbmcgbGlzdA0KYXJ0 QGlldGYub3JnPG1haWx0bzphcnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FydA0K --_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_ Content-Type: text/html; charset="utf-8" Content-ID: <99AA528C020E434CAA34A6916A6BC2AE@GBRP265.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkV1cGhlbWlh IFVDQVMiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDQgMSAyIDIgMSA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Iklvc2V2a2EgVGVybSI7DQoJcGFub3NlLTE6MiAwIDUgOSAzIDAgMCAwIDAg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5o Mw0KCXttc28tc3R5bGUtbmFtZTpoMzt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHls ZS1uYW1lOnAxOw0KCW1hcmdpbjowY207DQoJYmFja2dyb3VuZDp3aGl0ZTsNCglmb250LXNpemU6 OC41cHQ7DQoJZm9udC1mYW1pbHk6Iklvc2V2a2EgVGVybSI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5zMQ0KCXttc28tc3R5bGUtbmFtZTpzMTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGlzIGRyYWZ0IGlzIHdlbGwgd3JpdHRlbiBhbmQgYW4gYXBwcm9hY2ggd2Ugd291bGQgbGlr ZSB0byB1c2UgaW4gSUVFRSAyNzkxLCBhbmQgZnJvbSB5b3VyIHRleHQgaXQgd2lsbCBmaXQgcmln aHQgaW50byBvdXINCjxhIGhyZWY9Imh0dHBzOi8vb3BlbnNvdXJjZS5pZWVlLm9yZy8yNzkxLW9i amVjdC9pZWVlLTI3OTEtc2NoZW1hLy0vYmxvYi9tYXN0ZXIvMjc5MW9iamVjdC5qc29uI0wxMjki Pg0K4oCcZXRhZ+KAnSBmaWVsZDwvYT4gd2hlcmUgd2UgaG9wZSBmb3IgYSBjb25zaXN0ZW50IGhh c2hpbmcgbWVjaGFuaXNtIHRvIGRldGVjdCBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZHJhZnQgc2VlbXMg dG8gYnVpbGQgb24gSlNPTiBXZWIgU2lnbmF0dXJlICg8YSBocmVmPSJodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9yZmMvcmZjNzUxNy5odG1sIj5SRkM3NTE1PC9hPikgYW5kIEpTT04gV2ViIEtl eSAoPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NTE3 Lmh0bWwiPlJGQzc1MTc8L2E+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4pLA0KIGJ1dCB0aGUgMy4xLjMgaXMgYSBiaXQgdG9vIGJyaWVmIGZvciByZWFkZXJzIG5ldyB0 byB0aGVzZSBzdGFuZGFyZHMsIHBlcmhhcHMgZ2l2ZSBhIGJyaWVmIHN1bW1hcnkgZm9yIHRoaXMg ZXhhbXBsZSwgZXNwZWNpYWxseSBhcyBSRkM3NTE3IGlzIHF1aXRlIGNvbXByZWhlbnNpdmUgd2l0 aCBtYW55IG9wdGlvbnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIHBhcnRpY3VsYXIgaXQgaXMgdW5jbGVhciBpZiB0aGUg SldTIEhlYWRlciBhbHNvIG5lZWRzIHRvIGJlIEpTT04gY2Fub25pY2FsaXplZCDigJMgd2hpY2gg bWF5IGJlIGEgZ29vZCBpZGVhIGZvciBjb25zaXN0ZW50IOKAnGhhc2jigJ0gcHVycG9zZXMgbGlr ZSBpbiBvdXIgdXNlIGNhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhlcmXigJlzIG15IHJvdWdoIHN1Z2dlc3Rpb24g4oCT IHByb2JhYmx5IHdyb25nISBNeSBhZGRpdGlvbnMgdW5pbmRlbnRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+My4xLjMuJm5i c3A7IEdlbmVyYXRlIGEgSldTIFN0cmluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBVc2UgdGhlIHJlc3VsdCBvZiB0aGUg cHJldmlvdXMgc3RlcCBhcyAmcXVvdDtKV1MgUGF5bG9hZCZxdW90OyB0byB0aGUgc2lnbmF0dXJl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHByb2Nlc3MgZGVzY3JpYmVkIGlu IEFwcGVuZGl4IEYgb2YgSldTIFtSRkM3NTE1XS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBzaG9ydCBhIGRldGFjaGVkIEpXUyBpcyByZXBy ZXNlbnRlZCBhcyB0aGUgc3RyaW5nIGNvbmNhdGVuYXRlZCBmcm9tPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEJBU0U2NFVSTChVVEY4KEpXUyBQcm90ZWN0ZWQgSGVhZGVyKSkgfHwgJy4nIHx8 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHx8 ICcuJyB8fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBCQVNFNjRVUkwoSldTIFNpZ25hdHVyZSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Ob3RpY2UsIGZvciBjb21wYXJpc29uIHdpdGggdGhl IDxzcGFuIGNsYXNzPSJoMyI+SldTIENvbXBhY3QgU2VyaWFsaXphdGlvbiwgPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGNsYXNzPSJoMyI+dGhhdCB0aGUgSldTIFBheWxvYWQg aXMgbm90IGluY2x1ZGVkIGluIHRoZSBkZXRhY2hlZCBKV1MgU3RyaW5nLCA8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gY2xhc3M9ImgzIj5idXQgcmVwbGFjZWQgYnkgYW4gZW1w dHkgc3RyaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRm9yIHRoZSBleGFtcGxlLCB0aGUgSldTIGhlYWRl ciBpcyBhc3N1bWVkIHRvIGJlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB7JnF1b3Q7YWxnJnF1b3Q7OiZxdW90O0hTMjU2 JnF1b3Q7fTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPlRoZSBhYm92ZSBleGFtcGxlIGlzIGVxdWFsIHRvIGl0cyBvd24gSkNTIGNhbm9uaWNhbGl6 YXRpb24uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkpTT04gQ2Fub25pY2FsaXphdGlvbiBpcyBu b3QgYSByZXF1aXJlbWVudCBmb3IgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkpXUyBIZWFk ZXIsIGhvd2V2ZXIgdGhpcyBpcyBSRUNPTU1FTkRFRCwgY29tYmluZWQgd2l0aDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmEgZml4ZWQgYWxnb3JpdGhtIGNob2ljZSwgaWYgZ2VuZXJhdGluZyBhIGNv bnNpc3RlbnQgSldTL0NUIHNpZ25hdHVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgaXMg cyBhbHNvIHRvIGJlIHVzZWQgYXMgYXMgYSBjYW5vbmljYWwgdmVyc2lvbiBpZGVudGlmaWVyIDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9mIHRoZSBKU09OIHBheWxvYWQgY29udGVudCwgZS5nLiBh cyBhIHN0cm9uZyBFVGFnIChSRkM3MjMyKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSldTIFNpZ25hdHVyZSBvZiB0aGUgY2Fub25pY2Fs aXplZCBKU09OIHBheWxvYWQsIHVzaW5nIHRoZSBrZXkgPG86cD48L286cD48L3ByZT4NCjxwcmU+ c3BlY2lmaWVkIGluIFNlY3Rpb24gMywgaXMgdGhlIGJ5dGVzPG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+NTQgNzUgNDggYjQgMjAgNDIgNmYgYzQg MzkgeDggOGUgM2QgOGEgNjYgYWIgeGUgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+ZDIgNWUgNGIgMTEgZjYgYjggYjUgMzQgeGUgMWEgOTAg M2YgOTYgNjMgYzM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkVuY29kaW5nIGFzIEJh c2U2NDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PlRoZSByZXN1bHRpbmcgY29uY2F0ZW5hdGVkIEpXUyBzdHJpbmcgc2hvdWxkIHRoZW4gcmVhZCBh cyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBleUpoYkdjaU9pSklVekkxTmlKOS4uVkhWSXRDQkNiOFE1Q0kt NDlpbWFyRHRKZVN4SDJ1TFUwRGhxUVA1Wmp3NDxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5Zb3UgbWF5IHdhbnQgdG8gbW92ZSBteSBFVGFnIHJlY29tbWVuZGF0aW9uIHRvIGFu IGFwcGVuZGl4LCBhcyBJIGRvbuKAmXQgZmVlbCBpdCBmaXRzIHdlbGwgd2hlcmUgSSBwdXQgaXQs IGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIHBvaW50aW5nIG91dC4gQXMgYSB1c2UgY2FzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SSBkb27igJl0IGtub3cgZW5vdWdoIGFib3V0IFJGQzc1MTUsIGlzIGl0IHBvc3NpYmxlIHRv IGRvIHNvbWV0aGluZyBsaWtlIHJlZ3VsYXIgU0hBMyBvciB3b3VsZCBteSBmaW5nZXJwcmludCB1 c2UgY2FzZSBuZWVkIHRvIGp1c3QgcHVibGljbHkgZGVjbGFyZSB0aGUgc2lnbmF0dXJlIGtleSB0 byB1c2U/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TdGlhbiBT b2lsYW5kLVJleWVzLCBUaGUgVW5pdmVyc2l0eSBvZiBNYW5jaGVzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmVzY2ll bmNlbGFiLm9yZy51ay8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL3d3dy5l c2NpZW5jZWxhYi5vcmcudWsvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9vcmNpZC5vcmcvMDAwMC0wMDAxLTk4 NDItOTcxOCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vb3JjaWQub3JnLzAw MDAtMDAwMS05ODQyLTk3MTg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNlIG5vdGUgdGhhdCBJIG1h eSB3b3JrIGZsZXhpYmx5IOKAkyB3aGlsc3QgaXQgc3VpdHMgbWUgdG8gZW1haWwgbm93LA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0kgZG8gbm90IGV4cGVjdCBhIHJlc3BvbnNlIG9yIGFjdGlvbiBvdXRzaWRlIG9m IHlvdXIgb3duIHdvcmtpbmcgaG91cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5hcnQgJmx0O2FydC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg QnJldCBKb3JkYW4gJmx0O2pvcmRhbi5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+V2VkbmVzZGF5LCAyOCBBcHJpbCAyMDIxIGF0IDAzOjI5PGJyPg0KPGI+VG86IDwvYj5EaWNr IEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 O2FydEBpZXRmLm9yZyZxdW90OyAmbHQ7YXJ0QGlldGYub3JnJmd0OywgRElTUEFUQ0ggJmx0O2Rp c3BhdGNoQGlldGYub3JnJmd0OywgJnF1b3Q7cmZjLWlzZUByZmMtZWRpdG9yLm9yZyZxdW90OyAm bHQ7cmZjLWlzZUByZmMtZWRpdG9yLm9yZyZndDssIElFVEYgU2VjRGlzcGF0Y2ggJmx0O1NlY2Rp c3BhdGNoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2FydF0gUGxhaW4g dGV4dCBKU09OIGRpZ2l0YWwgc2lnbmF0dXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkx1 Y2tpbHkgdGhpcyB0aW1lIHdlIGhhdmUgUkZDODc4NSB0aGF0IHNvbHZlcyB0aGUgY2Fub25pY2Fs aXphdGlvbiBwcm9ibGVtIGZvciBKU09OLiZuYnNwOzxicj4NCjxicj4NCkJyZXQmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgQ29t bW9kb3JlIDY0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q R1AgRmluZ2VycHJpbnQ6Jm5ic3A7NjNCNCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICZuYnNwO0YyQzAg NzRGOCBBQ0FFIDc0MTUgMDA1MDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBBcHIgMjcs IDIwMjEsIGF0IDc6MzkgUE0sIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gc3VwcG9ydGl2ZSBvZiB0aGlzIHdvcmss IGFuZCB3b3VsZCBhbHNvIGJlIHdpbGxpbmcgdG8gd29yayB0b3dhcmRzIGEgUFMuIEkgYW0gc2Vl aW5nIHJhcGlkIGdyb3d0aCBpbiB0aGUgZGVtYW5kIHRvIGVtYmVkIEpXUyBpbiBKV1MuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiBteSBleHBlcmll bmNlIHdpdGggWE1MLURTaWcgKHNlZSBiZWxvdykgbWFraW5nIGl0IG1vcmUgWE1MLURTaWcgbGlr ZSBkb2VzIG5vdCBzb3VuZCBsaWtlIGEgZ29vZCB0aGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3IgYW55IGludGVyZXN0ZWQmbmJzcDtpbiBzb21lIEpXVCBoaXN0 b3J5LCB3aGVuIHdlIHdlcmUgYnJld2luZyB1cCB3aGF0IGJlY2FtZSBPQXV0aCAyLjAsIHdlIGRp ZCBub3Qgd2FudCB0byB0aWUgYSB0b2tlbiBmb3JtYXQgdG8gdGhlIGltcGxlbWVudGF0aW9uIGFz IG1hbnkgZGVwbG95bWVudHMgaGFkIHRoZWlyIG93biBwcm9wcmlldGFyeSB0b2tlbiBmb3JtYXRz IC0tIGJ1dCB3ZSBrbmV3IG5ldyBkZXBsb3ltZW50cw0KIHdvdWxkIGJlbmVmaXQmbmJzcDtmcm9t IHN0YW5kYXJkaXppbmcgYSB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3VyIHJlcXVpcmVtZW50cyB3ZXJlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBVUkwgc2FmZSAoYWNjZXNz IHRva2VucyBhdCB0aGUgdGltZSB3ZXJlIG9mdGVuIHBhc3NlZCBhcyBhIHF1ZXJ5IHBhcmFtZXRl ciZuYnNwOy0tIEkga25vdywgbm90IHRoZSBiZXN0IGlkZWEsIGJ1dCB3b3JraW5nJm5ic3A7d2l0 aCB3aGF0IHBlb3BsZSB3YW50ZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIEhUVFAgaGVhZGVyIHNhZmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcmljaGVyIHRoYW4gbmFtZSAvIHZhbHVl IHBhaXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9wdGlvbnMgd2UgY29uc2lkZXJlZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFTTi4xIC0gdGhlIDYwcyBhcmUgY2FsbGluZyBhbmQgd2Fu dCB0aGVpciBkYXRhIGJhY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlhNTC1EU2lnIC0gbm90IFVSTCBzYWZlLCBsYXJnZSBzaXplLCBhbmQgSSBw ZXJzb25hbGx5IGhhZCBtYW55IHNjYXJzIGNhbm9uaWNhbGl6aW5nIFhNTC4gKEFuIGVhcmxpZXIg Y29tcGFueSBvZiBtaW5lIGhhZCBhIGNvbnRyYWN0IHRvIGJ1aWxkIFhNTC1EU2lnIGxpYnJhcmll cyBmb3IgYSBmZXcgbGFuZ3VhZ2VzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KU09OIHdhcyBiZWNvbWluZyB2ZXJ5IGNvb2wgYXQgdGhhdCB0 aW1lLCBhbmQgd2l0aCBiYXNlIDY0IFVSTCBzYWZlIGVuY29kaW5nIHRoZSBzdHJpbmcsIGl0IHdh cyBVUkwgc2FmZSwgYW5kIHRyZWF0aW5nIHRoZSBKU09OIHRleHQgYXMgYmluYXJ5IGRlYWx0IHdp dGggdGhlIGNhbm9uaWNhbGl6YXRpb24gY29uY2VybnMgLS0gYW5kIEpTT04gY2Fub25pY2FsaXph dGlvbiBkaWQgbm90IGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Vc2luZyBhIGRvdCBhcyB0aGUgc2VwYXJhdG9yJm5ic3A7YmV0d2Vl biBoZWFkZXIsIHBheWxvYWQsIGFuZCBzaWduYXR1cmUgbWFkZSBpdCBlYXN5IHRvIHBhcnNlLiBU aGUgZG90IHdhcyBVUkwgc2FmZSwgYnV0IG5vdCBpbiB0aGUgYmFzZSA2NCBzZXQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBTaW1wbGUg V2ViIFRva2VucyB3ZXJlIGJvcm4gLS0gdG8gYmUgcmVuYW1lZCBKU09OIFdlYiBUb2tlbnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNr PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzMiIgaGVp Z2h0PSIzMiIgc3R5bGU9IndpZHRoOi4zMzMzaW47aGVpZ2h0Oi4zMzMzaW4iIGlkPSJfeDAwMDBf aTEwMjUiIHNyYz0iY2lkOn5XUkQwMDAwLmpwZyIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRl ci4iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0V1cGhlbWlhIFVDQVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBcHIg MjcsIDIwMjEgYXQgODoyOCBBTSBCcmV0IEpvcmRhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmRh bi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvcmRhbi5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgRGlzcGF0Y2gsPGJyPg0KPGJyPg0KQW5kZXJzIFJ1 bmRncmVuLCBTYW11ZWwsIEVyZHRtYW4sIGFuZCBJIGhhdmUgYmVlbiB3b3JraW5nIG9uIGFuIElE IGZvciB5b3VyIGNvbnNpZGVyYXRpb24uIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1 c2UgSldTIGFuZCBKQ1MgdG8gY3JlYXRlIHBsYWluLXRleHQgSlNPTiBzaWduYXR1cmVzLiBUaGUg YWJzdHJhY3QgcmVhZHMgYXMgZm9sbG93czo8YnI+DQo8YnI+DQpUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIG1ldGhvZCBmb3IgZXh0ZW5kaW5nIHRoZSBzY29wZSBvZiB0aGUgSlNPTiBXZWIgU2ln bmF0dXJlIChKV1MpIHN0YW5kYXJkLCBjYWxsZWQgSldTL0NULiZuYnNwOyBCeSBjb21iaW5pbmcg dGhlIGRldGFjaGVkIG1vZGUgb2YgSldTIHdpdGggdGhlIEpTT04gQ2Fub25pY2FsaXphdGlvbiBT Y2hlbWUgKEpDUyksIEpXUy9DVCBlbmFibGVzIEpTT04gb2JqZWN0cyB0byByZW1haW4gaW4gdGhl IEpTT04gZm9ybWF0IGFmdGVyDQogYmVpbmcgc2lnbmVkIChha2EgJnF1b3Q7Q2xlYXIgVGV4dCZx dW90OyBzaWduaW5nKS4mbmJzcDsgSW4gYWRkaXRpb24gdG8gc3VwcG9ydGluZyBhIGNvbnNpc3Rl bnQgZGF0YSBmb3JtYXQsIHRoaXMgYXJyYW5nZW1lbnQgYWxzbyBzaW1wbGlmaWVzIGRvY3VtZW50 YXRpb24sIGRlYnVnZ2luZywgYW5kIGxvZ2dpbmcuJm5ic3A7IFRoZSBhYmlsaXR5IHRvIGVtYmVk IHNpZ25lZCBKU09OIG9iamVjdHMgaW4gb3RoZXIgSlNPTiBvYmplY3RzLCBtYWtlcyB0aGUgdXNl IG9mIGNvdW50ZXItc2lnbmF0dXJlcw0KIHN0cmFpZ2h0Zm9yd2FyZC48YnI+DQo8YnI+DQpUaGUg ZGF0YSB0cmFja2VyIHBhZ2UgZm9yIHRoaXM6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWpvcmRhbi1qd3MtY3QvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb3JkYW4tandzLWN0LzwvYT48YnI+ DQo8YnI+DQpBcyB5b3Uga25vdyB0aGVyZSBhcmUgbGFyZ2UgZWNvc3lzdGVtcyB0aGF0IG5lZWRz IGRpZ2l0YWwgc2lnbmF0dXJlcyBmb3IgcGxhaW4gdGV4dCBKU09OIGRhdGEsIG1lYW5pbmcgd2hl cmUgdGhlIEpTT04gZGF0YSBpcyBub3QgYmFzZTY0IGVuY29kZWQuIFRoaXMgSUQgcHJvdmlkZXMg YSBzb2x1dGlvbiB1c2luZyBleGlzdGluZyBJRVRGIFJGQ3MgdG8gbWFrZSB0aGlzIHdvcmsuIEZ1 cnRoZXIsIHRoaXMgd29yayBsb29rcyB0byBiZSBhZG9wdGVkDQogYnkgbWFueSBncm91cHMgYW5k IG9yZ2FuaXphdGlvbnMgZnJvbSBmaW5hbmNpYWwgc2VydmljZXMsIHRocmVhdCBpbnRlbGxpZ2Vu Y2UsIGFuZCBpbmNpZGVudCByZXNwb25zZS4NCjxicj4NCjxicj4NCldlIGFyZSBub3Qgc3VyZSB3 aGF0IGRpcmVjdGlvbiB3b3VsZCBiZSBiZXN0IGZvciB0aGlzIHdvcmsgaW4gdGhlIElFVEYsIHNo b3VsZCB3ZSBzZW5kIHRvIHRoZSBJU0UgZm9yIHB1YmxpY2F0aW9uIG9yIGRvIHlvdSB3YW50IHRv IGNyZWF0ZSBhIHdvcmtpbmcgZ3JvdXAuIFVsdGltYXRlbHkgdGhlcmUgaXMgYSBsb3Qgb2Ygd29y ayB0aGF0IGNvdWxkIGJlIGRvbmUgaW4gdGhpcyBzcGFjZSB0byBtZWV0IHRoZSBuZWVkcyBvZiB0 aGUgbWFya2V0LiBXZQ0KIHdvdWxkIGJlIGhhcHB5IHdpdGggcmVsZWFzaW5nIHRoZXNlIElEcyBm b3IgSVNFIHB1YmxpY2F0aW9uLCBvciBmb3IgY3JlYXRpbmcgYSB3b3JraW5nIGdyb3VwIHRvIG1v dmUgdGhlbSBmb3J3YXJkLiBJdCBpcyBqdXN0IGltcG9ydGFudCB0byBub3RlIHRoYXQgdGhlIG1h cmtldCBpcyBpbiBkZXNwZXJhdGUgbmVlZCBvZiB0aGVzZSBzb2x1dGlvbnMuIElmIHlvdSB3YW50 IHRvIHRha2UgaXQgZm9yIGEgc3BpbiwgdGhlcmUgaXMgYSBKV1MvQ1QgcGxheWdyb3VuZA0KIGF0 OiA8YSBocmVmPSJodHRwczovL21vYmlsZXBraS5vcmcvandzLWN0IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9tb2JpbGVwa2kub3JnL2p3cy1jdDwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJldDxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+U2VudCBm cm9tIG15IFRJLTk5LzRBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlBHUCBGaW5nZXJwcmludDombmJzcDs2M0I0IEZD NTMgNjgwQSA2QjdEIDE0NDcgJm5ic3A7RjJDMCA3NEY4IEFDQUUmbmJzcDs3NDE1IDAwNTA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFydCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86YXJ0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXJ0QGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJ0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcnQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FD23AA4B422441629243FAFD9EAD9656manchesteracuk_-- From nobody Wed Apr 28 02:36: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 20E603A2208 for ; Wed, 28 Apr 2021 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2qSOw7abpcnq for ; Wed, 28 Apr 2021 02:36:50 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC4A3A223A for ; Wed, 28 Apr 2021 02:36:50 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with UTF8SMTP id 40D901A9D270 for ; Wed, 28 Apr 2021 11:29:58 +0200 (CEST) Received: from s934.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with UTF8SMTP id 3065F2E2BE63; Wed, 28 Apr 2021 11:29:58 +0200 (CEST) Received: from s470.loopia.se (unknown [172.22.191.5]) by s934.loopia.se (Postfix) with UTF8SMTP id 2D12E7CEA17; Wed, 28 Apr 2021 11:29:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.5]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id nGYXCeWHaftE; Wed, 28 Apr 2021 11:29:57 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.217] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with UTF8SMTPSA id 3AC841CE628B; Wed, 28 Apr 2021 11:29:57 +0200 (CEST) Message-ID: <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> Date: Wed, 28 Apr 2021 11:29:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Anders Rundgren Cc: DISPATCH , art@ietf.org, IETF SecDispatch , rfc-ise@rfc-editor.org References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> From: Stefan Santesson Organization: 3xA Security AB In-Reply-To: <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Wed, 28 Apr 2021 09:36:55 -0000 RFC 7797 is supported by common open source such as Nimbus and I use it for instances where you obviously do not need a URL safe token. As such it works for JWS but Not for JWT. But It works really well and saves space when URL safeness is not needed. So I guess your answer is that it still encapsulates the signed JSON in the signature, and that the proposal really is about embedding signature in the JSON object being signed (and not about whether the JSON is in plaintext). Could you elaborate why you think it is important to NOT embed signed data in the signature? What is the usecase? /Stefan On 2021-04-28 11:00, Anders Rundgren wrote: > On 2021-04-28 8:52, Stefan Santesson wrote: >> How is this different/better than implementing RFC 7797 and apply the >> header b64=false in order to carry plaintext JSON in the payload? > > Good question! > > Apart from the fact that the data becomes embedded in the JWS > signature container (=changing the structure), you cannot really put > JSON there: > https://tools.ietf.org/html/rfc7797#section-5.2 > > My guess that the only real-world use of this option is to save an > internal-only (but technically redundant) Base64Url-operation for > truly detached data, be it it JSON, PNG, etc. > > JWS/CT was designed for signing JSON Objects ({}), and let them remain > as such. > > Thanx, > Anders > >> >> /Stefan >> >> >> On 2021-04-28 04:29, Bret Jordan wrote: >>> Luckily this time we have RFC8785 that solves the canonicalization >>> problem for JSON. >>> >>> Bret >>> >>> Sent from my Commodore 64 >>> >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >>> >>>> On Apr 27, 2021, at 7:39 PM, Dick Hardt wrote: >>>> >>>>  >>>> I am supportive of this work, and would also be willing to work >>>> towards a PS. I am seeing rapid growth in the demand to embed JWS >>>> in JWS. >>>> >>>> Given my experience with XML-DSig (see below) making it more >>>> XML-DSig like does not sound like a good thing. >>>> >>>> For any interested in some JWT history, when we were brewing up >>>> what became OAuth 2.0, we did not want to tie a token format to the >>>> implementation as many deployments had their own proprietary token >>>> formats -- but we knew new deployments would benefit from >>>> standardizing a token. >>>> >>>> Our requirements were: >>>> - URL safe (access tokens at the time were often passed as a query >>>> parameter -- I know, not the best idea, but working with what >>>> people wanted) >>>> - HTTP header safe >>>> - richer than name / value pairs >>>> >>>> Options we considered: >>>> ASN.1 - the 60s are calling and want their data back >>>> XML-DSig - not URL safe, large size, and I personally had many >>>> scars canonicalizing XML. (An earlier company of mine had a >>>> contract to build XML-DSig libraries for a few languages) >>>> JSON was becoming very cool at that time, and with base 64 URL safe >>>> encoding the string, it was URL safe, and treating the JSON text as >>>> binary dealt with the canonicalization concerns -- and JSON >>>> canonicalization did not exist. >>>> >>>> Using a dot as the separator between header, payload, and >>>> signature made it easy to parse. The dot was URL safe, but not in >>>> the base 64 set. >>>> >>>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >>>> >>>> /Dick >>>> >>>> >>>> >>>> >>>> ᐧ >>>> >>>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan >>>> wrote: >>>> >>>>     Dear Dispatch, >>>> >>>>     Anders Rundgren, Samuel, Erdtman, and I have been working on >>>> an ID for your consideration. This document describes how to use >>>> JWS and JCS to create plain-text JSON signatures. The abstract >>>> reads as follows: >>>> >>>>     This document describes a method for extending the scope of >>>> the JSON Web Signature (JWS) standard, called JWS/CT.  By >>>> combining the detached mode of JWS with the JSON Canonicalization >>>> Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON >>>> format after being signed (aka "Clear Text" signing).  In addition >>>> to supporting a consistent data format, this arrangement also >>>> simplifies documentation, debugging, and logging.  The ability to >>>> embed signed JSON objects in other JSON objects, makes the use of >>>> counter-signatures straightforward. >>>> >>>>     The data tracker page for this: >>>> https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >>>> >>>>     As you know there are large ecosystems that needs digital >>>> signatures for plain text JSON data, meaning where the JSON data is >>>> not base64 encoded. This ID provides a solution using existing IETF >>>> RFCs to make this work. Further, this work looks to be adopted by >>>> many groups and organizations from financial services, threat >>>> intelligence, and incident response. >>>> >>>>     We are not sure what direction would be best for this work >>>> in the IETF, should we send to the ISE for publication or do you >>>> want to create a working group. Ultimately there is a lot of work >>>> that could be done in this space to meet the needs of the market. >>>> We would be happy with releasing these IDs for ISE publication, or >>>> for creating a working group to move them forward. It is just >>>> important to note that the market is in desperate need of these >>>> solutions. If you want to take it for a spin, there is a JWS/CT >>>> playground at: https://mobilepki.org/jws-ct >>>> >>>>     Thanks >>>>     Bret >>>> >>>>     -- >>>>     Sent from my TI-99/4A >>>> >>>>     PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 >>>> ACAE 7415 0050 >>>>     _______________________________________________ >>>>     art mailing list >>>>     art@ietf.org >>>>     https://www.ietf.org/mailman/listinfo/art >>>> >>> >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Wed Apr 28 02:52:22 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 8ACFC3A22C8; Wed, 28 Apr 2021 02:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 c0-C1DGLp_Vd; Wed, 28 Apr 2021 02:52:07 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100085.outbound.protection.outlook.com [40.107.10.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965BA3A22C7; Wed, 28 Apr 2021 02:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UTz4tMHEvYrMl8iP+9pXyogWq9pekSXvz3YHA/m0VdlMEn3aNKQerqq0iiFOIXAdZFXJdlXOsNwEoMH+qgErdLp8dqoynhXt6F/JzxyE7it60XQGQZXTJCQt+VfKR0xmilJ73cHWX9gbE5JKS1g6UDhYE8tz6MMSDeIohxi+iW+1fr+B7Gg8jTdfY9SuWnPkxwCY6g35nDnW4YbU9Ipj1vVZT1/k8LcsqceoTb4r+2AHkFQ2lBMmEEHbINBqsZGvXymCCnRdV3PIF2WykK8DS3ueaBl4C4HslQUETbnxZ3gcbCR7nz0hgCDzUyLdQ7zfiqwrKr77U8fGUwdpfxmxKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dzmsmH8ccztDupvbSZ4ewlgfagGHkEQbIa5m/JVpAw=; b=kLQ+ogbAXcOX31NvGVFlTMsWnwLBoGe+GdCQEtT9apucpbDuKY01HnA0l5wl5/66gAD16HV+CX2jXtvsfPJCJ9r/0Vec2y9dnKh48QOohjKmi8UNFtjyhy8eurHIt/Lwaum+ZEH9STozmZpQh4Xu7eLqDFqsQL2NpwnGJTYPtn5ksbmNmedxkBacFGcVroNWe1D2r8rU7hW74dnhLoNf+k9v1Ev7GxjKrrBWdbZNDMlk8DknjIOQgCKwqUUsBvQ0Gikvbnf4pgJAq+FKhms51UpYymuYkKYluEKgaR6DewwQZQzGpDDDJmgKCvWy690nfrmDT8gbnh+rldIltAiRSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LO2P265MB3134.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:166::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Wed, 28 Apr 2021 09:52:03 +0000 Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4065.027; Wed, 28 Apr 2021 09:52:03 +0000 From: Stian Soiland-Reyes To: Bret Jordan , Dick Hardt CC: "art@ietf.org" , IETF SecDispatch , DISPATCH , "rfc-ise@rfc-editor.org" Thread-Topic: [art] Plain text JSON digital signatures Thread-Index: AQHXO3n9Ux7vg67F8E+dTqNYh8wUoarJJ3GAgAAOHICAAIPpAIAACKAA Date: Wed, 28 Apr 2021 09:52:02 +0000 Message-ID: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=manchester.ac.uk; x-originating-ip: [2001:8b0:a657:68e3:4d0d:8981:d3ab:c2c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f59d230a-262e-4ae0-2520-08d90a2b4660 x-ms-traffictypediagnostic: LO2P265MB3134: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d4B1f1LIGGhcEPO2VHzKAuz18R1oB1egQCoMb4pMcr4hjYOncZRoiNihB3BnNLDQGtijLtECL14RvKSCoygPlzOtrykqNppz+KZ2HQfKbgmm8e4Rbr8vn6PjOIn8KGTsw92YJXdPwHuB+e1N/327/2zPaeHdy3d8fAokXNzxSwF/LL5VQzyg1bo5okjL/MDWlvC0V6q73e+SpNwJEPoYxHCag6wN7DGljlxk0idIoqRxBaGAfmA1/6Y+PuOvIGHzA76/b7iLCHXfHvooPax75CPfAjEcWMclXRTIazKaTfUY/dOG16fqbm3L52m4BnGeZf2ECSGmxVSTYptdCG8P5s3ERI/aTFk3/dwcqcd2K2hk/JeJwn8r50kgseNkyKlpGirT3Knv9OykFp3JHVGOBZjMUqPJQP+YURZwnLFfrHbo7NMKVx+0t03SRLrPoe73WTG7zjkgAM/gnwQGILpnAeohQNWEpYyYnTP8ydZBM9YoTiAgmHZ7PSxyv/xs8IZ3N671O3MIakKZ7iRSLFhxjSM6eGK6zDiTWRYLpnEBHKgp4sVdexAPepIf4og+oHjIFE2xa3DXrm2K251sJK0qwC39a2SWE7L8Bg49YStNNqql1Rip7R7DS2jgNX3nEvxKnf/i65K5kelih7W8H0wR1FhPFuaIWDgiIRqzhacPVPqgLB9T+ewBEerMmtJz5LO9aB1D6CyEtalHy1sVA/1hIPtdH4LhSuiUl7UdWjAhzDk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(478600001)(4326008)(6512007)(166002)(83380400001)(8676002)(86362001)(38100700002)(33656002)(21615005)(36756003)(122000001)(2906002)(186003)(66446008)(2616005)(786003)(316002)(53546011)(71200400001)(6506007)(66946007)(66476007)(64756008)(8936002)(76116006)(54906003)(6486002)(110136005)(5660300002)(966005)(66556008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WHN6NTU4QmswanFUa3RjYUN5Ni92UDdhblJ4dWt4WjZkUCtVcjRFZGNUbXdy?= =?utf-8?B?R09QcTBlZ2ZwU0dRS0FkNU8veWw5VExzaXJXU2pPUXdpQnA3c2RhNHpwYUQy?= =?utf-8?B?bHhHTmoyQ1IvYzE2WjdvQzhpWkN4V0dha25zVlRzQ0hZTWdQNnFaT1FGQUMr?= =?utf-8?B?WUNSUzB3MHZYMW53a2VLUXBwaWFJd3lYdVF4KzIzU2ZWTHBnNWN5cjVvSUZC?= =?utf-8?B?MlEyd2g1VDg1bTkxNkFlZkFrT3R1WEJNQWx5SDA0TWxXYlhwVXVUNVM0dVlT?= =?utf-8?B?anRVcjA5UFBMdklMa21Ec0paU0xrLzllQzZwS25LaGR0M29FQ0liaEFnSitG?= =?utf-8?B?bVB0ZkJzTUZEeFdRRWtJN3ZZTWJaenRJVm9QT1MxSmlJSVowZlY3RHFwRGVv?= =?utf-8?B?Ti96WVphaUV0T3c2K21BWWVwc2xweW9wSGN3MWttQXJyYlhZY1ltdXJIeEUx?= =?utf-8?B?dGY1WFVGVWJSUmRRWndDQUE4WEJ2SGpMSktWRFpDSy9sMmFGRThtczhDWmFI?= =?utf-8?B?dmsxRU5MK3R6MmhnZ2ViaURMOWlDcFJRdlFiVm8wem5JRVJGQlNLRGhpZmNK?= =?utf-8?B?NWkvRm0rWk1oTEZaaGxzcVNNTjhXcTZEMHdoNVNZbURnTWxManNqVURVK2Zn?= =?utf-8?B?QXpSb2pSR2hMbG1MMUFrWHFRU29WM3lETzQ3ZXU3ZU40a0JhMlRaRTNwWTB6?= =?utf-8?B?ZTZwdWtjei9mME1tTDRPQUF4UHQzUHNnSDRBMmpIS2IwWVRCQmNWVFBpQi80?= =?utf-8?B?bkphL1JyVG5iOTAzcHlNbnhiV0FiVk1hdmh1QkRoZWszVG40UWNWSDE3amNB?= =?utf-8?B?VVI0U0xiM05wN1hVWEpoTi9DVis4YTZMMmk2NVN5TGRNOFMySjkrNGY0Vzll?= =?utf-8?B?QjU1VlZBNm5yMUpyUGdUL2k3b0xQMTBCWEdIL3B0c0t0NHpZUW9YU2FNc3k2?= =?utf-8?B?K1crbmtuQ0hYWGpYZ0pKUldPc1JoMU9oSlRRd3RFajVZR0RkTXl6d0ljdHNj?= =?utf-8?B?Q1FUbEJxOC9yMk9HR2xwWVJFM2szZklKYUF0eXZoZGw2THBHSDEzaFpDRzNH?= =?utf-8?B?d1VQNUFjZlQxcm44UDNYNmRSOWVJNVcxaTBoQWdQSm1OQ0VTZE5LcStFY2Vo?= =?utf-8?B?M3FrNzlFYkVsL1lYUDlaWmYzMlp6WEY3b0xEN3psMDF1dVRjTE5VekIzN0Ri?= =?utf-8?B?b3M2T2FQMGt5cVVCWkRQTThtTUVGbGN3SjBZSW9IUm9TNStFODJINFpTdjJu?= =?utf-8?B?QUNjU2JtOWhGQzJKajJ1WXNFVWxuRmVBOXJnd3BVWDMxd0NGYWJHT1R1Smdr?= =?utf-8?B?c3RTY3MxLzcwZHA3cUhwS2gydUgyUkZCczdGcTF5RlIyVm52ZGlBMitqM014?= =?utf-8?B?ZGhpZEFLMGo5dm9BUi9CSXAwWGh0U0owV3FFVmhnbkI3VkhYazFMbW1jWW5T?= =?utf-8?B?cHhkUitTTGJPUGhjcDV5UlJGc3N3YjIvSHpOVHlMV1VmQ3lMTFpLMXhsN2N2?= =?utf-8?B?aUVaa1QybUxuMU9tVnVsSEZhMlJncW9mc0hObVUyd0NpbkhaVi9keEh2b2VC?= =?utf-8?B?WktuNERnTWxiUEVwcStNYnV2OE4ySXpxd0VQb0k2Z1padGtQZnJ0TncwRytX?= =?utf-8?B?U0gwYXpUNWgrb0FLWUM1ZUhPWVlERXJhZnZVTFgxMStZQzcxYUJSU29BQVhW?= =?utf-8?B?K05pRDIrMGVtWktDZUNzdHMrelpxY0VTR2lLMy9YZTQ1aUVuTVJPc3pzR3Bl?= =?utf-8?B?WVVUckNJRzJXbnMzdFM0aldNN0sreXJmNmN4OWhNbmVyVWpkSkE3V3VGOGpu?= =?utf-8?B?QUo0WlFrZ0M4UHFacnNFWjhuMHA4bHFCUUhKOHZ2dXlQWG5NaTJyajNiQjVm?= =?utf-8?B?aDJ0Q1VnWWlvNXVjRUVNbkkvdUFubVBObkV1WlRnU2FHZFE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_" MIME-Version: 1.0 X-OriginatorOrg: manchester.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f59d230a-262e-4ae0-2520-08d90a2b4660 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 09:52:02.9416 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qXcBMOpPYOXCnjC7s6kVJCTHMipiXS5v0E6GiBLKP4VmhHxtTj6f3wJeweucqOrcHVBLFgd9yU0DUdQpMBFrLaVmRL3lcK2yRVSAKREMZiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3134 Archived-At: Subject: Re: [Secdispatch] [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: Wed, 28 Apr 2021 09:52:13 -0000 --_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCmIEkgdGhpbmsgSSBnb3QgaXQgd3JvbmcgYmVsb3csIGFzIHRoZSBKV1MgU2lnbmF0dXJlIGlm IEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0IGFsc28gbmVlZHMgdG8gaW5jbHVkZSB0aGUgSldTIGhl YWRlcj8NCg0KUGVyaGFwcyB0aGlzIGlzIHdoeSBpdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQgaGVy ZSEg8J+Yig0KDQotLQ0KU3RpYW4gU29pbGFuZC1SZXllcywgVGhlIFVuaXZlcnNpdHkgb2YgTWFu Y2hlc3Rlcg0KaHR0cHM6Ly93d3cuZXNjaWVuY2VsYWIub3JnLnVrLw0KaHR0cHM6Ly9vcmNpZC5v cmcvMDAwMC0wMDAxLTk4NDItOTcxOA0KICAgIFBsZWFzZSBub3RlIHRoYXQgSSBtYXkgd29yayBm bGV4aWJseSDigJMgd2hpbHN0IGl0IHN1aXRzIG1lIHRvIGVtYWlsIG5vdywNCiAgICBJIGRvIG5v dCBleHBlY3QgYSByZXNwb25zZSBvciBhY3Rpb24gb3V0c2lkZSBvZiB5b3VyIG93biB3b3JraW5n IGhvdXJzLg0KDQoNCkZyb206IGFydCA8YXJ0LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBTdGlhbiBTb2lsYW5kLVJleWVzIDxzb2lsYW5kLXJleWVzQG1hbmNoZXN0ZXIuYWMudWs+DQpE YXRlOiBXZWRuZXNkYXksIDI4IEFwcmlsIDIwMjEgYXQgMTA6MjINClRvOiBCcmV0IEpvcmRhbiA8 am9yZGFuLmlldGZAZ21haWwuY29tPiwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+ DQpDYzogImFydEBpZXRmLm9yZyIgPGFydEBpZXRmLm9yZz4sIElFVEYgU2VjRGlzcGF0Y2ggPFNl Y2Rpc3BhdGNoQGlldGYub3JnPiwgRElTUEFUQ0ggPGRpc3BhdGNoQGlldGYub3JnPiwgInJmYy1p c2VAcmZjLWVkaXRvci5vcmciIDxyZmMtaXNlQHJmYy1lZGl0b3Iub3JnPg0KU3ViamVjdDogUmU6 IFthcnRdIFBsYWluIHRleHQgSlNPTiBkaWdpdGFsIHNpZ25hdHVyZXMNCg0KVGhpcyBkcmFmdCBp cyB3ZWxsIHdyaXR0ZW4gYW5kIGFuIGFwcHJvYWNoIHdlIHdvdWxkIGxpa2UgdG8gdXNlIGluIElF RUUgMjc5MSwgYW5kIGZyb20geW91ciB0ZXh0IGl0IHdpbGwgZml0IHJpZ2h0IGludG8gb3VyIOKA nGV0YWfigJ0gZmllbGQ8aHR0cHM6Ly9vcGVuc291cmNlLmllZWUub3JnLzI3OTEtb2JqZWN0L2ll ZWUtMjc5MS1zY2hlbWEvLS9ibG9iL21hc3Rlci8yNzkxb2JqZWN0Lmpzb24jTDEyOT4gd2hlcmUg d2UgaG9wZSBmb3IgYSBjb25zaXN0ZW50IGhhc2hpbmcgbWVjaGFuaXNtIHRvIGRldGVjdCBjaGFu Z2VzLg0KDQpUaGUgZHJhZnQgc2VlbXMgdG8gYnVpbGQgb24gSlNPTiBXZWIgU2lnbmF0dXJlIChS RkM3NTE1PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3NTE3Lmh0bWw+KSBhbmQg SlNPTiBXZWIgS2V5IChSRkM3NTE3PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM3 NTE3Lmh0bWw+KSwgYnV0IHRoZSAzLjEuMyBpcyBhIGJpdCB0b28gYnJpZWYgZm9yIHJlYWRlcnMg bmV3IHRvIHRoZXNlIHN0YW5kYXJkcywgcGVyaGFwcyBnaXZlIGEgYnJpZWYgc3VtbWFyeSBmb3Ig dGhpcyBleGFtcGxlLCBlc3BlY2lhbGx5IGFzIFJGQzc1MTcgaXMgcXVpdGUgY29tcHJlaGVuc2l2 ZSB3aXRoIG1hbnkgb3B0aW9ucz8NCg0KSW4gcGFydGljdWxhciBpdCBpcyB1bmNsZWFyIGlmIHRo ZSBKV1MgSGVhZGVyIGFsc28gbmVlZHMgdG8gYmUgSlNPTiBjYW5vbmljYWxpemVkIOKAkyB3aGlj aCBtYXkgYmUgYSBnb29kIGlkZWEgZm9yIGNvbnNpc3RlbnQg4oCcaGFzaOKAnSBwdXJwb3NlcyBs aWtlIGluIG91ciB1c2UgY2FzZT8NCg0KSGVyZeKAmXMgbXkgcm91Z2ggc3VnZ2VzdGlvbiDigJMg cHJvYmFibHkgd3JvbmchIE15IGFkZGl0aW9ucyB1bmluZGVudGVkLg0KDQoNCjMuMS4zLiAgR2Vu ZXJhdGUgYSBKV1MgU3RyaW5nDQoNCg0KDQogICBVc2UgdGhlIHJlc3VsdCBvZiB0aGUgcHJldmlv dXMgc3RlcCBhcyAiSldTIFBheWxvYWQiIHRvIHRoZSBzaWduYXR1cmUNCg0KICAgcHJvY2VzcyBk ZXNjcmliZWQgaW4gQXBwZW5kaXggRiBvZiBKV1MgW1JGQzc1MTVdLg0KDQoNCg0KSW4gc2hvcnQg YSBkZXRhY2hlZCBKV1MgaXMgcmVwcmVzZW50ZWQgYXMgdGhlIHN0cmluZyBjb25jYXRlbmF0ZWQg ZnJvbQ0KDQoNCg0KICAgICAgQkFTRTY0VVJMKFVURjgoSldTIFByb3RlY3RlZCBIZWFkZXIpKSB8 fCAnLicgfHwNCg0KICAgICAgfHwgJy4nIHx8DQoNCiAgICAgIEJBU0U2NFVSTChKV1MgU2lnbmF0 dXJlKQ0KDQoNCg0KTm90aWNlLCBmb3IgY29tcGFyaXNvbiB3aXRoIHRoZSBKV1MgQ29tcGFjdCBT ZXJpYWxpemF0aW9uLA0KDQp0aGF0IHRoZSBKV1MgUGF5bG9hZCBpcyBub3QgaW5jbHVkZWQgaW4g dGhlIGRldGFjaGVkIEpXUyBTdHJpbmcsDQoNCmJ1dCByZXBsYWNlZCBieSBhbiBlbXB0eSBzdHJp bmcuDQoNCg0KDQogICBGb3IgdGhlIGV4YW1wbGUsIHRoZSBKV1MgaGVhZGVyIGlzIGFzc3VtZWQg dG8gYmU6DQoNCg0KDQogICB7ImFsZyI6IkhTMjU2In0NCg0KDQoNClRoZSBhYm92ZSBleGFtcGxl IGlzIGVxdWFsIHRvIGl0cyBvd24gSkNTIGNhbm9uaWNhbGl6YXRpb24uDQoNCkpTT04gQ2Fub25p Y2FsaXphdGlvbiBpcyBub3QgYSByZXF1aXJlbWVudCBmb3IgdGhlDQoNCkpXUyBIZWFkZXIsIGhv d2V2ZXIgdGhpcyBpcyBSRUNPTU1FTkRFRCwgY29tYmluZWQgd2l0aA0KDQphIGZpeGVkIGFsZ29y aXRobSBjaG9pY2UsIGlmIGdlbmVyYXRpbmcgYSBjb25zaXN0ZW50IEpXUy9DVCBzaWduYXR1cmUN Cg0KdGhhdCBpcyBzIGFsc28gdG8gYmUgdXNlZCBhcyBhcyBhIGNhbm9uaWNhbCB2ZXJzaW9uIGlk ZW50aWZpZXINCg0Kb2YgdGhlIEpTT04gcGF5bG9hZCBjb250ZW50LCBlLmcuIGFzIGEgc3Ryb25n IEVUYWcgKFJGQzcyMzIpLg0KDQoNCg0KVGhlIEpXUyBTaWduYXR1cmUgb2YgdGhlIGNhbm9uaWNh bGl6ZWQgSlNPTiBwYXlsb2FkLCB1c2luZyB0aGUga2V5DQoNCnNwZWNpZmllZCBpbiBTZWN0aW9u IDMsIGlzIHRoZSBieXRlcw0KDQoNCg0KNTQgNzUgNDggYjQgMjAgNDIgNmYgYzQgMzkgeDggOGUg M2QgOGEgNjYgYWIgeGUNCg0KZDIgNWUgNGIgMTEgZjYgYjggYjUgMzQgeGUgMWEgOTAgM2YgOTYg NjMgYzMNCg0KDQoNCg0KDQpFbmNvZGluZyBhcyBCYXNlNjQNCg0KDQoNClRoZSByZXN1bHRpbmcg Y29uY2F0ZW5hdGVkIEpXUyBzdHJpbmcgc2hvdWxkIHRoZW4gcmVhZCBhcyBmb2xsb3dzOg0KDQoN Cg0KICAgZXlKaGJHY2lPaUpJVXpJMU5pSjkuLlZIVkl0Q0JDYjhRNUNJLTQ5aW1hckR0SmVTeEgy dUxVMERocVFQNVpqdzQNCg0KDQpZb3UgbWF5IHdhbnQgdG8gbW92ZSBteSBFVGFnIHJlY29tbWVu ZGF0aW9uIHRvIGFuIGFwcGVuZGl4LCBhcyBJIGRvbuKAmXQgZmVlbCBpdCBmaXRzIHdlbGwgd2hl cmUgSSBwdXQgaXQsIGJ1dCBJIHRoaW5rIGl0IGlzIHdvcnRoIHBvaW50aW5nIG91dC4gQXMgYSB1 c2UgY2FzZS4NCg0KSSBkb27igJl0IGtub3cgZW5vdWdoIGFib3V0IFJGQzc1MTUsIGlzIGl0IHBv c3NpYmxlIHRvIGRvIHNvbWV0aGluZyBsaWtlIHJlZ3VsYXIgU0hBMyBvciB3b3VsZCBteSBmaW5n ZXJwcmludCB1c2UgY2FzZSBuZWVkIHRvIGp1c3QgcHVibGljbHkgZGVjbGFyZSB0aGUgc2lnbmF0 dXJlIGtleSB0byB1c2U/DQoNCg0KLS0NClN0aWFuIFNvaWxhbmQtUmV5ZXMsIFRoZSBVbml2ZXJz aXR5IG9mIE1hbmNoZXN0ZXINCmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9yZy51ay8NCmh0dHBz Oi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgNCiAgICBQbGVhc2Ugbm90ZSB0aGF0IEkg bWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxzdCBpdCBzdWl0cyBtZSB0byBlbWFpbCBub3csDQog ICAgSSBkbyBub3QgZXhwZWN0IGEgcmVzcG9uc2Ugb3IgYWN0aW9uIG91dHNpZGUgb2YgeW91ciBv d24gd29ya2luZyBob3Vycy4NCg0KDQpGcm9tOiBhcnQgPGFydC1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFdl ZG5lc2RheSwgMjggQXByaWwgMjAyMSBhdCAwMzoyOQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPg0KQ2M6ICJhcnRAaWV0Zi5vcmciIDxhcnRAaWV0Zi5vcmc+LCBESVNQQVRD SCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAicmZjLWlzZUByZmMtZWRpdG9yLm9yZyIgPHJmYy1pc2VA cmZjLWVkaXRvci5vcmc+LCBJRVRGIFNlY0Rpc3BhdGNoIDxTZWNkaXNwYXRjaEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbYXJ0XSBQbGFpbiB0ZXh0IEpTT04gZGlnaXRhbCBzaWduYXR1cmVzDQoN Ckx1Y2tpbHkgdGhpcyB0aW1lIHdlIGhhdmUgUkZDODc4NSB0aGF0IHNvbHZlcyB0aGUgY2Fub25p Y2FsaXphdGlvbiBwcm9ibGVtIGZvciBKU09OLg0KDQpCcmV0DQpTZW50IGZyb20gbXkgQ29tbW9k b3JlIDY0DQoNClBHUCBGaW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICBGMkMw IDc0RjggQUNBRSA3NDE1IDAwNTANCg0KDQoNCk9uIEFwciAyNywgMjAyMSwgYXQgNzozOSBQTSwg RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+IHdyb3RlOg0KSSBhbSBzdXBwb3J0aXZl IG9mIHRoaXMgd29yaywgYW5kIHdvdWxkIGFsc28gYmUgd2lsbGluZyB0byB3b3JrIHRvd2FyZHMg YSBQUy4gSSBhbSBzZWVpbmcgcmFwaWQgZ3Jvd3RoIGluIHRoZSBkZW1hbmQgdG8gZW1iZWQgSldT IGluIEpXUy4NCg0KR2l2ZW4gbXkgZXhwZXJpZW5jZSB3aXRoIFhNTC1EU2lnIChzZWUgYmVsb3cp IG1ha2luZyBpdCBtb3JlIFhNTC1EU2lnIGxpa2UgZG9lcyBub3Qgc291bmQgbGlrZSBhIGdvb2Qg dGhpbmcuDQoNCkZvciBhbnkgaW50ZXJlc3RlZCBpbiBzb21lIEpXVCBoaXN0b3J5LCB3aGVuIHdl IHdlcmUgYnJld2luZyB1cCB3aGF0IGJlY2FtZSBPQXV0aCAyLjAsIHdlIGRpZCBub3Qgd2FudCB0 byB0aWUgYSB0b2tlbiBmb3JtYXQgdG8gdGhlIGltcGxlbWVudGF0aW9uIGFzIG1hbnkgZGVwbG95 bWVudHMgaGFkIHRoZWlyIG93biBwcm9wcmlldGFyeSB0b2tlbiBmb3JtYXRzIC0tIGJ1dCB3ZSBr bmV3IG5ldyBkZXBsb3ltZW50cyB3b3VsZCBiZW5lZml0IGZyb20gc3RhbmRhcmRpemluZyBhIHRv a2VuLg0KDQpPdXIgcmVxdWlyZW1lbnRzIHdlcmU6DQotIFVSTCBzYWZlIChhY2Nlc3MgdG9rZW5z IGF0IHRoZSB0aW1lIHdlcmUgb2Z0ZW4gcGFzc2VkIGFzIGEgcXVlcnkgcGFyYW1ldGVyIC0tIEkg a25vdywgbm90IHRoZSBiZXN0IGlkZWEsIGJ1dCB3b3JraW5nIHdpdGggd2hhdCBwZW9wbGUgd2Fu dGVkKQ0KLSBIVFRQIGhlYWRlciBzYWZlDQotIHJpY2hlciB0aGFuIG5hbWUgLyB2YWx1ZSBwYWly cw0KDQpPcHRpb25zIHdlIGNvbnNpZGVyZWQ6DQpBU04uMSAtIHRoZSA2MHMgYXJlIGNhbGxpbmcg YW5kIHdhbnQgdGhlaXIgZGF0YSBiYWNrDQpYTUwtRFNpZyAtIG5vdCBVUkwgc2FmZSwgbGFyZ2Ug c2l6ZSwgYW5kIEkgcGVyc29uYWxseSBoYWQgbWFueSBzY2FycyBjYW5vbmljYWxpemluZyBYTUwu IChBbiBlYXJsaWVyIGNvbXBhbnkgb2YgbWluZSBoYWQgYSBjb250cmFjdCB0byBidWlsZCBYTUwt RFNpZyBsaWJyYXJpZXMgZm9yIGEgZmV3IGxhbmd1YWdlcykNCg0KSlNPTiB3YXMgYmVjb21pbmcg dmVyeSBjb29sIGF0IHRoYXQgdGltZSwgYW5kIHdpdGggYmFzZSA2NCBVUkwgc2FmZSBlbmNvZGlu ZyB0aGUgc3RyaW5nLCBpdCB3YXMgVVJMIHNhZmUsIGFuZCB0cmVhdGluZyB0aGUgSlNPTiB0ZXh0 IGFzIGJpbmFyeSBkZWFsdCB3aXRoIHRoZSBjYW5vbmljYWxpemF0aW9uIGNvbmNlcm5zIC0tIGFu ZCBKU09OIGNhbm9uaWNhbGl6YXRpb24gZGlkIG5vdCBleGlzdC4NCg0KVXNpbmcgYSBkb3QgYXMg dGhlIHNlcGFyYXRvciBiZXR3ZWVuIGhlYWRlciwgcGF5bG9hZCwgYW5kIHNpZ25hdHVyZSBtYWRl IGl0IGVhc3kgdG8gcGFyc2UuIFRoZSBkb3Qgd2FzIFVSTCBzYWZlLCBidXQgbm90IGluIHRoZSBi YXNlIDY0IHNldC4NCg0KQW5kIFNpbXBsZSBXZWIgVG9rZW5zIHdlcmUgYm9ybiAtLSB0byBiZSBy ZW5hbWVkIEpTT04gV2ViIFRva2Vucy4NCg0KL0RpY2sNCg0KDQoNCg0KW0ltYWdlIHJlbW92ZWQg Ynkgc2VuZGVyLl3hkKcNCg0KT24gVHVlLCBBcHIgMjcsIDIwMjEgYXQgODoyOCBBTSBCcmV0IEpv cmRhbiA8am9yZGFuLmlldGZAZ21haWwuY29tPG1haWx0bzpqb3JkYW4uaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNCkRlYXIgRGlzcGF0Y2gsDQoNCkFuZGVycyBSdW5kZ3JlbiwgU2FtdWVsLCBFcmR0 bWFuLCBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiBhbiBJRCBmb3IgeW91ciBjb25zaWRlcmF0 aW9uLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdG8gdXNlIEpXUyBhbmQgSkNTIHRvIGNy ZWF0ZSBwbGFpbi10ZXh0IEpTT04gc2lnbmF0dXJlcy4gVGhlIGFic3RyYWN0IHJlYWRzIGFzIGZv bGxvd3M6DQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciBleHRlbmRpbmcg dGhlIHNjb3BlIG9mIHRoZSBKU09OIFdlYiBTaWduYXR1cmUgKEpXUykgc3RhbmRhcmQsIGNhbGxl ZCBKV1MvQ1QuICBCeSBjb21iaW5pbmcgdGhlIGRldGFjaGVkIG1vZGUgb2YgSldTIHdpdGggdGhl IEpTT04gQ2Fub25pY2FsaXphdGlvbiBTY2hlbWUgKEpDUyksIEpXUy9DVCBlbmFibGVzIEpTT04g b2JqZWN0cyB0byByZW1haW4gaW4gdGhlIEpTT04gZm9ybWF0IGFmdGVyIGJlaW5nIHNpZ25lZCAo YWthICJDbGVhciBUZXh0IiBzaWduaW5nKS4gIEluIGFkZGl0aW9uIHRvIHN1cHBvcnRpbmcgYSBj b25zaXN0ZW50IGRhdGEgZm9ybWF0LCB0aGlzIGFycmFuZ2VtZW50IGFsc28gc2ltcGxpZmllcyBk b2N1bWVudGF0aW9uLCBkZWJ1Z2dpbmcsIGFuZCBsb2dnaW5nLiAgVGhlIGFiaWxpdHkgdG8gZW1i ZWQgc2lnbmVkIEpTT04gb2JqZWN0cyBpbiBvdGhlciBKU09OIG9iamVjdHMsIG1ha2VzIHRoZSB1 c2Ugb2YgY291bnRlci1zaWduYXR1cmVzIHN0cmFpZ2h0Zm9yd2FyZC4NCg0KVGhlIGRhdGEgdHJh Y2tlciBwYWdlIGZvciB0aGlzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1qb3JkYW4tandzLWN0Lw0KDQpBcyB5b3Uga25vdyB0aGVyZSBhcmUgbGFyZ2UgZWNvc3lzdGVt cyB0aGF0IG5lZWRzIGRpZ2l0YWwgc2lnbmF0dXJlcyBmb3IgcGxhaW4gdGV4dCBKU09OIGRhdGEs IG1lYW5pbmcgd2hlcmUgdGhlIEpTT04gZGF0YSBpcyBub3QgYmFzZTY0IGVuY29kZWQuIFRoaXMg SUQgcHJvdmlkZXMgYSBzb2x1dGlvbiB1c2luZyBleGlzdGluZyBJRVRGIFJGQ3MgdG8gbWFrZSB0 aGlzIHdvcmsuIEZ1cnRoZXIsIHRoaXMgd29yayBsb29rcyB0byBiZSBhZG9wdGVkIGJ5IG1hbnkg Z3JvdXBzIGFuZCBvcmdhbml6YXRpb25zIGZyb20gZmluYW5jaWFsIHNlcnZpY2VzLCB0aHJlYXQg aW50ZWxsaWdlbmNlLCBhbmQgaW5jaWRlbnQgcmVzcG9uc2UuDQoNCldlIGFyZSBub3Qgc3VyZSB3 aGF0IGRpcmVjdGlvbiB3b3VsZCBiZSBiZXN0IGZvciB0aGlzIHdvcmsgaW4gdGhlIElFVEYsIHNo b3VsZCB3ZSBzZW5kIHRvIHRoZSBJU0UgZm9yIHB1YmxpY2F0aW9uIG9yIGRvIHlvdSB3YW50IHRv IGNyZWF0ZSBhIHdvcmtpbmcgZ3JvdXAuIFVsdGltYXRlbHkgdGhlcmUgaXMgYSBsb3Qgb2Ygd29y ayB0aGF0IGNvdWxkIGJlIGRvbmUgaW4gdGhpcyBzcGFjZSB0byBtZWV0IHRoZSBuZWVkcyBvZiB0 aGUgbWFya2V0LiBXZSB3b3VsZCBiZSBoYXBweSB3aXRoIHJlbGVhc2luZyB0aGVzZSBJRHMgZm9y IElTRSBwdWJsaWNhdGlvbiwgb3IgZm9yIGNyZWF0aW5nIGEgd29ya2luZyBncm91cCB0byBtb3Zl IHRoZW0gZm9yd2FyZC4gSXQgaXMganVzdCBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBtYXJr ZXQgaXMgaW4gZGVzcGVyYXRlIG5lZWQgb2YgdGhlc2Ugc29sdXRpb25zLiBJZiB5b3Ugd2FudCB0 byB0YWtlIGl0IGZvciBhIHNwaW4sIHRoZXJlIGlzIGEgSldTL0NUIHBsYXlncm91bmQgYXQ6IGh0 dHBzOi8vbW9iaWxlcGtpLm9yZy9qd3MtY3QNCg0KVGhhbmtzDQpCcmV0DQoNCi0tDQoNClNlbnQg ZnJvbSBteSBUSS05OS80QQ0KDQoNCg0KUEdQIEZpbmdlcnByaW50OiA2M0I0IEZDNTMgNjgwQSA2 QjdEIDE0NDcgIEYyQzAgNzRGOCBBQ0FFIDc0MTUgMDA1MA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmFydCBtYWlsaW5nIGxpc3QNCmFydEBpZXRmLm9y ZzxtYWlsdG86YXJ0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcnQNCg== --_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkV1cGhlbWlh IFVDQVMiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDQgMSAyIDIgMSA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Iklvc2V2a2EgVGVybSI7DQoJcGFub3NlLTE6MiAwIDUgOSAzIDAgMCAwIDAg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu cDEsIGxpLnAxLCBkaXYucDENCgl7bXNvLXN0eWxlLW5hbWU6cDE7DQoJbWFyZ2luOjBjbTsNCgli YWNrZ3JvdW5kOndoaXRlOw0KCWZvbnQtc2l6ZTo4LjVwdDsNCglmb250LWZhbWlseToiSW9zZXZr YSBUZXJtIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmgzDQoJe21zby1zdHlsZS1uYW1lOmgzO30N CnNwYW4uczENCgl7bXNvLXN0eWxlLW5hbWU6czE7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij7igKYgSSB0aGluayBJIGdvdCBpdCB3cm9uZyBiZWxvdywgYXMgdGhlIEpXUyBTaWduYXR1cmUg aWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3QgYWxzbyBuZWVkcyB0byBpbmNsdWRlIHRoZSBKV1Mg aGVhZGVyPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlBlcmhhcHMgdGhpcyBpcyB3aHkgaXQgbmVlZHMgdG8gYmUgY2xhcmlm aWVkIGhlcmUhDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENv bG9yIEVtb2ppJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mIzEyODUyMjs8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlN0aWFuIFNvaWxhbmQtUmV5ZXMsIFRoZSBVbml2ZXJz aXR5IG9mIE1hbmNoZXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZXNjaWVuY2VsYWIub3JnLnVrLyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9yZy51ay88L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVm PSJodHRwczovL29yY2lkLm9yZy8wMDAwLTAwMDEtOTg0Mi05NzE4Ij48c3BhbiBzdHlsZT0iY29s b3I6IzA1NjNDMSI+aHR0cHM6Ly9vcmNpZC5vcmcvMDAwMC0wMDAxLTk4NDItOTcxODwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyBQbGVhc2Ugbm90ZSB0aGF0IEkgbWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxz dCBpdCBzdWl0cyBtZSB0byBlbWFpbCBub3csDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBkbyBub3QgZXhwZWN0 IGEgcmVzcG9uc2Ugb3IgYWN0aW9uIG91dHNpZGUgb2YgeW91ciBvd24gd29ya2luZyBob3Vycy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmFydCAmbHQ7YXJ0LWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBTdGlhbiBTb2lsYW5kLVJleWVzICZsdDtz b2lsYW5kLXJleWVzQG1hbmNoZXN0ZXIuYWMudWsmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5l c2RheSwgMjggQXByaWwgMjAyMSBhdCAxMDoyMjxicj4NCjxiPlRvOiA8L2I+QnJldCBKb3JkYW4g Jmx0O2pvcmRhbi5pZXRmQGdtYWlsLmNvbSZndDssIERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRA Z21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7YXJ0QGlldGYub3JnJnF1b3Q7ICZs dDthcnRAaWV0Zi5vcmcmZ3Q7LCBJRVRGIFNlY0Rpc3BhdGNoICZsdDtTZWNkaXNwYXRjaEBpZXRm Lm9yZyZndDssIERJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDssICZxdW90O3JmYy1p c2VAcmZjLWVkaXRvci5vcmcmcXVvdDsgJmx0O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbYXJ0XSBQbGFpbiB0ZXh0IEpTT04gZGlnaXRhbCBzaWdu YXR1cmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBkcmFmdCBp cyB3ZWxsIHdyaXR0ZW4gYW5kIGFuIGFwcHJvYWNoIHdlIHdvdWxkIGxpa2UgdG8gdXNlIGluIElF RUUgMjc5MSwgYW5kIGZyb20geW91ciB0ZXh0IGl0IHdpbGwgZml0IHJpZ2h0IGludG8gb3VyDQo8 YSBocmVmPSJodHRwczovL29wZW5zb3VyY2UuaWVlZS5vcmcvMjc5MS1vYmplY3QvaWVlZS0yNzkx LXNjaGVtYS8tL2Jsb2IvbWFzdGVyLzI3OTFvYmplY3QuanNvbiNMMTI5Ij4NCuKAnGV0YWfigJ0g ZmllbGQ8L2E+IHdoZXJlIHdlIGhvcGUgZm9yIGEgY29uc2lzdGVudCBoYXNoaW5nIG1lY2hhbmlz bSB0byBkZXRlY3QgY2hhbmdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGRyYWZ0IHNlZW1zIHRvIGJ1aWxkIG9uIEpT T04gV2ViIFNpZ25hdHVyZSAoPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZj L3JmYzc1MTcuaHRtbCI+UkZDNzUxNTwvYT4pIGFuZCBKU09OIFdlYiBLZXkgKDwvc3Bhbj48YSBo cmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNzUxNy5odG1sIj5SRkM3NTE3 PC9hPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KSwNCiBidXQgdGhl IDMuMS4zIGlzIGEgYml0IHRvbyBicmllZiBmb3IgcmVhZGVycyBuZXcgdG8gdGhlc2Ugc3RhbmRh cmRzLCBwZXJoYXBzIGdpdmUgYSBicmllZiBzdW1tYXJ5IGZvciB0aGlzIGV4YW1wbGUsIGVzcGVj aWFsbHkgYXMgUkZDNzUxNyBpcyBxdWl0ZSBjb21wcmVoZW5zaXZlIHdpdGggbWFueSBvcHRpb25z Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5JbiBwYXJ0aWN1bGFyIGl0IGlzIHVuY2xlYXIgaWYgdGhlIEpXUyBIZWFkZXIgYWxz byBuZWVkcyB0byBiZSBKU09OIGNhbm9uaWNhbGl6ZWQg4oCTIHdoaWNoIG1heSBiZSBhIGdvb2Qg aWRlYSBmb3IgY29uc2lzdGVudCDigJxoYXNo4oCdIHB1cnBvc2VzIGxpa2UgaW4gb3VyIHVzZSBj YXNlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5IZXJl4oCZcyBteSByb3VnaCBzdWdnZXN0aW9uIOKAkyBwcm9iYWJseSB3cm9u ZyEgTXkgYWRkaXRpb25zIHVuaW5kZW50ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjMuMS4zLiZuYnNwOyBHZW5lcmF0ZSBh IEpXUyBTdHJpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgVXNlIHRoZSByZXN1bHQgb2YgdGhlIHByZXZpb3VzIHN0ZXAg YXMgJnF1b3Q7SldTIFBheWxvYWQmcXVvdDsgdG8gdGhlIHNpZ25hdHVyZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm9jZXNzIGRlc2NyaWJlZCBpbiBBcHBlbmRpeCBGIG9m IEpXUyBbUkZDNzUxNV0uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+SW4gc2hvcnQgYSBkZXRhY2hlZCBKV1MgaXMgcmVwcmVzZW50ZWQgYXMgdGhl IHN0cmluZyBjb25jYXRlbmF0ZWQgZnJvbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCQVNF NjRVUkwoVVRGOChKV1MgUHJvdGVjdGVkIEhlYWRlcikpIHx8ICcuJyB8fDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8fCAnLicgfHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQkFTRTY0VVJM KEpXUyBTaWduYXR1cmUpPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Tm90aWNlLCBmb3IgY29tcGFyaXNvbiB3aXRoIHRoZSA8c3BhbiBjbGFzcz0i aDMiPkpXUyBDb21wYWN0IFNlcmlhbGl6YXRpb24sIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBjbGFzcz0iaDMiPnRoYXQgdGhlIEpXUyBQYXlsb2FkIGlzIG5vdCBpbmNsdWRl ZCBpbiB0aGUgZGV0YWNoZWQgSldTIFN0cmluZywgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIGNsYXNzPSJoMyI+YnV0IHJlcGxhY2VkIGJ5IGFuIGVtcHR5IHN0cmluZy48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IEZvciB0aGUgZXhhbXBsZSwgdGhlIEpXUyBoZWFkZXIgaXMgYXNzdW1lZCB0 byBiZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgeyZxdW90O2FsZyZxdW90OzomcXVvdDtIUzI1NiZxdW90O308bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgYWJvdmUg ZXhhbXBsZSBpcyBlcXVhbCB0byBpdHMgb3duIEpDUyBjYW5vbmljYWxpemF0aW9uLiA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5KU09OIENhbm9uaWNhbGl6YXRpb24gaXMgbm90IGEgcmVxdWlyZW1l bnQgZm9yIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5KV1MgSGVhZGVyLCBob3dldmVyIHRo aXMgaXMgUkVDT01NRU5ERUQsIGNvbWJpbmVkIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h IGZpeGVkIGFsZ29yaXRobSBjaG9pY2UsIGlmIGdlbmVyYXRpbmcgYSBjb25zaXN0ZW50IEpXUy9D VCBzaWduYXR1cmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGF0IGlzIHMgYWxzbyB0byBiZSB1 c2VkIGFzIGFzIGEgY2Fub25pY2FsIHZlcnNpb24gaWRlbnRpZmllciA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5vZiB0aGUgSlNPTiBwYXlsb2FkIGNvbnRlbnQsIGUuZy4gYXMgYSBzdHJvbmcgRVRh ZyAoUkZDNzIzMikuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+VGhlIEpXUyBTaWduYXR1cmUgb2YgdGhlIGNhbm9uaWNhbGl6ZWQgSlNPTiBwYXls b2FkLCB1c2luZyB0aGUga2V5IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNwZWNpZmllZCBpbiBT ZWN0aW9uIDMsIGlzIHRoZSBieXRlczxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0icDEiPjxz cGFuIGNsYXNzPSJzMSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAx Ij48c3BhbiBjbGFzcz0iczEiPjU0IDc1IDQ4IGI0IDIwIDQyIDZmIGM0IDM5IHg4IDhlIDNkIDhh IDY2IGFiIHhlIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBj bGFzcz0iczEiPmQyIDVlIDRiIDExIGY2IGI4IGI1IDM0IHhlIDFhIDkwIDNmIDk2IDYzIGMzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5FbmNvZGluZyBhcyBCYXNlNjQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgcmVzdWx0aW5n IGNvbmNhdGVuYXRlZCBKV1Mgc3RyaW5nIHNob3VsZCB0aGVuIHJlYWQgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgZXlKaGJHY2lPaUpJVXpJMU5pSjkuLlZIVkl0Q0JDYjhRNUNJLTQ5aW1hckR0SmVTeEgy dUxVMERocVFQNVpqdzQ8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WW91IG1h eSB3YW50IHRvIG1vdmUgbXkgRVRhZyByZWNvbW1lbmRhdGlvbiB0byBhbiBhcHBlbmRpeCwgYXMg SSBkb27igJl0IGZlZWwgaXQgZml0cyB3ZWxsIHdoZXJlIEkgcHV0IGl0LCBidXQgSSB0aGluayBp dCBpcyB3b3J0aCBwb2ludGluZyBvdXQuIEFzIGEgdXNlIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZG9u4oCZdCBr bm93IGVub3VnaCBhYm91dCBSRkM3NTE1LCBpcyBpdCBwb3NzaWJsZSB0byBkbyBzb21ldGhpbmcg bGlrZSByZWd1bGFyIFNIQTMgb3Igd291bGQgbXkgZmluZ2VycHJpbnQgdXNlIGNhc2UgbmVlZCB0 byBqdXN0IHB1YmxpY2x5IGRlY2xhcmUgdGhlIHNpZ25hdHVyZSBrZXkgdG8gdXNlPw0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3RpYW4gU29pbGFuZC1SZXllcywg VGhlIFVuaXZlcnNpdHkgb2YgTWFuY2hlc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5lc2NpZW5jZWxhYi5vcmcudWsv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly93d3cuZXNjaWVuY2VsYWIub3Jn LnVrLzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxhIGhyZWY9Imh0dHBzOi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL29yY2lkLm9yZy8wMDAwLTAwMDEtOTg0Mi05 NzE4PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBsZWFzZSBub3RlIHRoYXQgSSBtYXkgd29yayBmbGV4aWJs eSDigJMgd2hpbHN0IGl0IHN1aXRzIG1lIHRvIGVtYWlsIG5vdywNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJIGRv IG5vdCBleHBlY3QgYSByZXNwb25zZSBvciBhY3Rpb24gb3V0c2lkZSBvZiB5b3VyIG93biB3b3Jr aW5nIGhvdXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+YXJ0 ICZsdDthcnQtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJyZXQgSm9yZGFuICZs dDtqb3JkYW4uaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwg MjggQXByaWwgMjAyMSBhdCAwMzoyOTxicj4NCjxiPlRvOiA8L2I+RGljayBIYXJkdCAmbHQ7ZGlj ay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDthcnRAaWV0Zi5vcmcm cXVvdDsgJmx0O2FydEBpZXRmLm9yZyZndDssIERJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRmLm9y ZyZndDssICZxdW90O3JmYy1pc2VAcmZjLWVkaXRvci5vcmcmcXVvdDsgJmx0O3JmYy1pc2VAcmZj LWVkaXRvci5vcmcmZ3Q7LCBJRVRGIFNlY0Rpc3BhdGNoICZsdDtTZWNkaXNwYXRjaEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFthcnRdIFBsYWluIHRleHQgSlNPTiBkaWdp dGFsIHNpZ25hdHVyZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5MdWNraWx5IHRoaXMgdGlt ZSB3ZSBoYXZlIFJGQzg3ODUgdGhhdCBzb2x2ZXMgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJvYmxl bSBmb3IgSlNPTi4mbmJzcDs8YnI+DQo8YnI+DQpCcmV0Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IENvbW1vZG9yZSA2NDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEdQIEZpbmdlcnByaW50 OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJzcDtGMkMwIDc0RjggQUNBRSA3NDE1 IDAwNTA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gQXByIDI3LCAyMDIxLCBh dCA3OjM5IFBNLCBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHN1cHBvcnRpdmUgb2YgdGhpcyB3b3JrLCBhbmQgd291 bGQgYWxzbyBiZSB3aWxsaW5nIHRvIHdvcmsgdG93YXJkcyBhIFBTLiBJIGFtIHNlZWluZyByYXBp ZCBncm93dGggaW4gdGhlIGRlbWFuZCB0byBlbWJlZCBKV1MgaW4gSldTLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gbXkgZXhwZXJpZW5jZSB3aXRo IFhNTC1EU2lnIChzZWUgYmVsb3cpIG1ha2luZyBpdCBtb3JlIFhNTC1EU2lnIGxpa2UgZG9lcyBu b3Qgc291bmQgbGlrZSBhIGdvb2QgdGhpbmcuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIGFueSBpbnRlcmVzdGVkJm5ic3A7aW4gc29tZSBKV1QgaGlzdG9yeSwgd2hl biB3ZSB3ZXJlIGJyZXdpbmcgdXAgd2hhdCBiZWNhbWUgT0F1dGggMi4wLCB3ZSBkaWQgbm90IHdh bnQgdG8gdGllIGEgdG9rZW4gZm9ybWF0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhcyBtYW55IGRl cGxveW1lbnRzIGhhZCB0aGVpciBvd24gcHJvcHJpZXRhcnkgdG9rZW4gZm9ybWF0cyAtLSBidXQg d2Uga25ldyBuZXcgZGVwbG95bWVudHMNCiB3b3VsZCBiZW5lZml0Jm5ic3A7ZnJvbSBzdGFuZGFy ZGl6aW5nIGEgdG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk91ciByZXF1aXJlbWVudHMgd2VyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVVJMIHNhZmUgKGFjY2VzcyB0b2tlbnMg YXQgdGhlIHRpbWUgd2VyZSBvZnRlbiBwYXNzZWQgYXMgYSBxdWVyeSBwYXJhbWV0ZXImbmJzcDst LSBJIGtub3csIG5vdCB0aGUgYmVzdCBpZGVhLCBidXQgd29ya2luZyZuYnNwO3dpdGggd2hhdCBw ZW9wbGUgd2FudGVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSBIVFRQIGhlYWRlciBzYWZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHJpY2hlciB0aGFuIG5hbWUgLyB2YWx1ZSBwYWlyczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PcHRp b25zIHdlIGNvbnNpZGVyZWQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BU04uMSAtIHRoZSA2MHMgYXJlIGNhbGxpbmcgYW5kIHdhbnQgdGhlaXIg ZGF0YSBiYWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5YTUwtRFNpZyAtIG5vdCBVUkwgc2FmZSwgbGFyZ2Ugc2l6ZSwgYW5kIEkgcGVyc29uYWxs eSBoYWQgbWFueSBzY2FycyBjYW5vbmljYWxpemluZyBYTUwuIChBbiBlYXJsaWVyIGNvbXBhbnkg b2YgbWluZSBoYWQgYSBjb250cmFjdCB0byBidWlsZCBYTUwtRFNpZyBsaWJyYXJpZXMgZm9yIGEg ZmV3IGxhbmd1YWdlcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SlNPTiB3YXMgYmVjb21pbmcgdmVyeSBjb29sIGF0IHRoYXQgdGltZSwgYW5k IHdpdGggYmFzZSA2NCBVUkwgc2FmZSBlbmNvZGluZyB0aGUgc3RyaW5nLCBpdCB3YXMgVVJMIHNh ZmUsIGFuZCB0cmVhdGluZyB0aGUgSlNPTiB0ZXh0IGFzIGJpbmFyeSBkZWFsdCB3aXRoIHRoZSBj YW5vbmljYWxpemF0aW9uIGNvbmNlcm5zIC0tIGFuZCBKU09OIGNhbm9uaWNhbGl6YXRpb24gZGlk IG5vdCBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VXNpbmcgYSBkb3QgYXMgdGhlIHNlcGFyYXRvciZuYnNwO2JldHdlZW4gaGVhZGVy LCBwYXlsb2FkLCBhbmQgc2lnbmF0dXJlIG1hZGUgaXQgZWFzeSB0byBwYXJzZS4gVGhlIGRvdCB3 YXMgVVJMIHNhZmUsIGJ1dCBub3QgaW4gdGhlIGJhc2UgNjQgc2V0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgU2ltcGxlIFdlYiBUb2tl bnMgd2VyZSBib3JuIC0tIHRvIGJlIHJlbmFtZWQgSlNPTiBXZWIgVG9rZW5zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIi IHN0eWxlPSJ3aWR0aDouMzMzM2luO2hlaWdodDouMzMzM2luIiBpZD0iX3gwMDAwX2kxMDI1IiBz cmM9ImNpZDp+V1JEMDAwMC5qcGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtFdXBoZW1p YSBVQ0FTJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDI3LCAyMDIx IGF0IDg6MjggQU0gQnJldCBKb3JkYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqb3JkYW4uaWV0ZkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qb3JkYW4uaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBE aXNwYXRjaCw8YnI+DQo8YnI+DQpBbmRlcnMgUnVuZGdyZW4sIFNhbXVlbCwgRXJkdG1hbiwgYW5k IEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYW4gSUQgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4gVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHVzZSBKV1MgYW5kIEpDUyB0byBjcmVhdGUgcGxh aW4tdGV4dCBKU09OIHNpZ25hdHVyZXMuIFRoZSBhYnN0cmFjdCByZWFkcyBhcyBmb2xsb3dzOjxi cj4NCjxicj4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGZvciBleHRlbmRpbmcg dGhlIHNjb3BlIG9mIHRoZSBKU09OIFdlYiBTaWduYXR1cmUgKEpXUykgc3RhbmRhcmQsIGNhbGxl ZCBKV1MvQ1QuJm5ic3A7IEJ5IGNvbWJpbmluZyB0aGUgZGV0YWNoZWQgbW9kZSBvZiBKV1Mgd2l0 aCB0aGUgSlNPTiBDYW5vbmljYWxpemF0aW9uIFNjaGVtZSAoSkNTKSwgSldTL0NUIGVuYWJsZXMg SlNPTiBvYmplY3RzIHRvIHJlbWFpbiBpbiB0aGUgSlNPTiBmb3JtYXQgYWZ0ZXINCiBiZWluZyBz aWduZWQgKGFrYSAmcXVvdDtDbGVhciBUZXh0JnF1b3Q7IHNpZ25pbmcpLiZuYnNwOyBJbiBhZGRp dGlvbiB0byBzdXBwb3J0aW5nIGEgY29uc2lzdGVudCBkYXRhIGZvcm1hdCwgdGhpcyBhcnJhbmdl bWVudCBhbHNvIHNpbXBsaWZpZXMgZG9jdW1lbnRhdGlvbiwgZGVidWdnaW5nLCBhbmQgbG9nZ2lu Zy4mbmJzcDsgVGhlIGFiaWxpdHkgdG8gZW1iZWQgc2lnbmVkIEpTT04gb2JqZWN0cyBpbiBvdGhl ciBKU09OIG9iamVjdHMsIG1ha2VzIHRoZSB1c2Ugb2YgY291bnRlci1zaWduYXR1cmVzDQogc3Ry YWlnaHRmb3J3YXJkLjxicj4NCjxicj4NClRoZSBkYXRhIHRyYWNrZXIgcGFnZSBmb3IgdGhpczog PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9yZGFuLWp3 cy1jdC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWpvcmRhbi1qd3MtY3QvPC9hPjxicj4NCjxicj4NCkFzIHlvdSBrbm93IHRoZXJlIGFy ZSBsYXJnZSBlY29zeXN0ZW1zIHRoYXQgbmVlZHMgZGlnaXRhbCBzaWduYXR1cmVzIGZvciBwbGFp biB0ZXh0IEpTT04gZGF0YSwgbWVhbmluZyB3aGVyZSB0aGUgSlNPTiBkYXRhIGlzIG5vdCBiYXNl NjQgZW5jb2RlZC4gVGhpcyBJRCBwcm92aWRlcyBhIHNvbHV0aW9uIHVzaW5nIGV4aXN0aW5nIElF VEYgUkZDcyB0byBtYWtlIHRoaXMgd29yay4gRnVydGhlciwgdGhpcyB3b3JrIGxvb2tzIHRvIGJl IGFkb3B0ZWQNCiBieSBtYW55IGdyb3VwcyBhbmQgb3JnYW5pemF0aW9ucyBmcm9tIGZpbmFuY2lh bCBzZXJ2aWNlcywgdGhyZWF0IGludGVsbGlnZW5jZSwgYW5kIGluY2lkZW50IHJlc3BvbnNlLg0K PGJyPg0KPGJyPg0KV2UgYXJlIG5vdCBzdXJlIHdoYXQgZGlyZWN0aW9uIHdvdWxkIGJlIGJlc3Qg Zm9yIHRoaXMgd29yayBpbiB0aGUgSUVURiwgc2hvdWxkIHdlIHNlbmQgdG8gdGhlIElTRSBmb3Ig cHVibGljYXRpb24gb3IgZG8geW91IHdhbnQgdG8gY3JlYXRlIGEgd29ya2luZyBncm91cC4gVWx0 aW1hdGVseSB0aGVyZSBpcyBhIGxvdCBvZiB3b3JrIHRoYXQgY291bGQgYmUgZG9uZSBpbiB0aGlz IHNwYWNlIHRvIG1lZXQgdGhlIG5lZWRzIG9mIHRoZSBtYXJrZXQuIFdlDQogd291bGQgYmUgaGFw cHkgd2l0aCByZWxlYXNpbmcgdGhlc2UgSURzIGZvciBJU0UgcHVibGljYXRpb24sIG9yIGZvciBj cmVhdGluZyBhIHdvcmtpbmcgZ3JvdXAgdG8gbW92ZSB0aGVtIGZvcndhcmQuIEl0IGlzIGp1c3Qg aW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGUgbWFya2V0IGlzIGluIGRlc3BlcmF0ZSBuZWVkIG9m IHRoZXNlIHNvbHV0aW9ucy4gSWYgeW91IHdhbnQgdG8gdGFrZSBpdCBmb3IgYSBzcGluLCB0aGVy ZSBpcyBhIEpXUy9DVCBwbGF5Z3JvdW5kDQogYXQ6IDxhIGhyZWY9Imh0dHBzOi8vbW9iaWxlcGtp Lm9yZy9qd3MtY3QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21vYmlsZXBraS5vcmcvandzLWN0 PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmV0 PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij5TZW50IGZyb20gbXkgVEktOTkvNEE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+UEdQIEZpbmdlcnByaW50OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJz cDtGMkMwIDc0RjggQUNBRSZuYnNwOzc0MTUgMDA1MDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KYXJ0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzphcnRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5hcnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FydDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_-- From nobody Wed Apr 28 08:26:00 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 6AC6A3A1039; Wed, 28 Apr 2021 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 YOUogliFKVKy; Wed, 28 Apr 2021 08:25:54 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D749B3A1038; Wed, 28 Apr 2021 08:25:53 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id a11so2141209plh.3; Wed, 28 Apr 2021 08:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AVHEfjnyShwhifQC19SJL37TN7cqfpKhSN8OC+9S0c0=; b=g3smjzvzpFt4TeZx6km/AaWTl9r4XP7+54x7aAO2n6yuXRrsiX5OuQctji87JXWbx2 r3lrd5ghAUMmV89Rfyk3bEiKo/hyoB+rLF2FtZV2UepmFL556DRD1Ra+7s3W0a+Iu6Wi qtylrI6MLju4xdUuWesGERGj4zlmClxZc+cfWH8Xqe2pn/5IxyBpeXDLm7lpuRL2AgU+ 0Qhj8aUnptRyRjW6JC/JtG0W6HTwMqna7LpY/WpOK/Lhj9qNlcfzm9TbIrTNbhgluofs d7RBWfGGtRkR4s0/VknA7Tw4j4rFqfVNmZIB/RvwtwulwcT09cwjaQsZ8RtFL80HahcS CiZw== 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 :content-transfer-encoding:message-id:references:to; bh=AVHEfjnyShwhifQC19SJL37TN7cqfpKhSN8OC+9S0c0=; b=j7lI8RumG6mMREC3zergZxjBIVjdLlktzqAHeYx4zhXO7GeKaGbiKtG6lSByxN1dNa qhg9gUaeVv5C5ixCwEdaxq0tJd7M5/ZMXA5KHcrR/1FmzzKtQSEP6vcV9I0z73Q7r8HS HnPDWWukBZ05+rTDymNoMWzdbCHjgfJwpCOn/M2EYsU6a+yRKCUuPW3u//W2UQsOCnH7 xIo/kkI/IJk60fHA2GbNG30OzEiP/uWTsssINYgtaaSGyRniwWyIdx99VLKkxLLTot9N ulLg5gk9ryARkCnq0ZvlA6SpJOgGJszzitu7tS0RXS6NtmF23N6FxA8aWDZqY9xfKgDW QCYg== X-Gm-Message-State: AOAM532OqtQoVbyl5NvAtcET6Jp0fa4NEzi5TqOq+xlUmMFZbFbTJJvy EAQvVOy893Juj1o3tYns7W8= X-Google-Smtp-Source: ABdhPJxceEm7FwyHlLcx1sQh8EMqmy2ZXfExzWRmSxyuo2MBYIdSH56HrQYLJwR0B3gkn/lC+QoABg== X-Received: by 2002:a17:90a:b78d:: with SMTP id m13mr4756774pjr.47.1619623550750; Wed, 28 Apr 2021 08:25:50 -0700 (PDT) Received: from smtpclient.apple ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id s21sm5220071pjr.52.2021.04.28.08.25.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Apr 2021 08:25:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Bret Jordan In-Reply-To: <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> Date: Wed, 28 Apr 2021 09:25:46 -0600 Cc: Anders Rundgren , art@ietf.org, DISPATCH , rfc-ise@rfc-editor.org, IETF SecDispatch 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> To: Stefan Santesson X-Mailer: Apple Mail (2.3654.80.0.2.43) 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: Wed, 28 Apr 2021 15:25:58 -0000 Hi Stefan, Here is one of many use cases. Imagine a connected graph of threat = intelligence data that is all represented in JSON. This data is = processed, searched, analyzed, and forwarded between N number of = entities. Some of the nodes in this connected graph are very large, 100 = of MB to GB. Now entities 1=E2=80=A6N desire to sign both the nodes and = the edge of this graph and issue them out to the ecosystem to increase = trust and verification of the data in the graph. Entities need to be = able create and issue detached signatures for data in the graph that = they do not own but that they know is correct and valid. Further, a = consumer of the data may need to process the signatures independently of = the data in the graph.=20 This is but one of many use cases where traditional JWS
.. does not work.=20 Bret =20 > On Apr 28, 2021, at 3:29 AM, Stefan Santesson = wrote: >=20 > RFC 7797 is supported by common open source such as Nimbus and I use = it > for instances where you obviously do not need a URL safe token. >=20 > As such it works for JWS but Not for JWT. But It works really well and > saves space when URL safeness is not needed. >=20 > So I guess your answer is that it still encapsulates the signed JSON = in > the signature, and that the proposal really is about embedding = signature > in the JSON object being signed (and not about whether the JSON is in > plaintext). >=20 > Could you elaborate why you think it is important to NOT embed signed > data in the signature? >=20 > What is the usecase? >=20 > /Stefan >=20 >=20 > On 2021-04-28 11:00, Anders Rundgren wrote: >> On 2021-04-28 8:52, Stefan Santesson wrote: >>> How is this different/better than implementing RFC 7797 and apply = the >>> header b64=3Dfalse in order to carry plaintext JSON in the payload? >>=20 >> Good question! >>=20 >> Apart from the fact that the data becomes embedded in the JWS >> signature container (=3Dchanging the structure), you cannot really = put >> JSON there: >> https://tools.ietf.org/html/rfc7797#section-5.2 >>=20 >> My guess that the only real-world use of this option is to save an >> internal-only (but technically redundant) Base64Url-operation for >> truly detached data, be it it JSON, PNG, etc. >>=20 >> JWS/CT was designed for signing JSON Objects ({}), and let them = remain >> as such. >>=20 >> Thanx, >> Anders >>=20 >>>=20 >>> /Stefan >>>=20 >>>=20 >>> On 2021-04-28 04:29, Bret Jordan wrote: >>>> Luckily this time we have RFC8785 that solves the canonicalization >>>> problem for JSON. >>>>=20 >>>> Bret >>>>=20 >>>> Sent from my Commodore 64 >>>>=20 >>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>>>=20 >>>>> On Apr 27, 2021, at 7:39 PM, Dick Hardt = wrote: >>>>>=20 >>>>> =EF=BB=BF >>>>> I am supportive of this work, and would also be willing to work >>>>> towards a PS. I am seeing rapid growth in the demand to embed JWS >>>>> in JWS. >>>>>=20 >>>>> Given my experience with XML-DSig (see below) making it more >>>>> XML-DSig like does not sound like a good thing. >>>>>=20 >>>>> For any interested in some JWT history, when we were brewing up >>>>> what became OAuth 2.0, we did not want to tie a token format to = the >>>>> implementation as many deployments had their own proprietary token >>>>> formats -- but we knew new deployments would benefit from >>>>> standardizing a token. >>>>>=20 >>>>> Our requirements were: >>>>> - URL safe (access tokens at the time were often passed as a query >>>>> parameter -- I know, not the best idea, but working with what >>>>> people wanted) >>>>> - HTTP header safe >>>>> - richer than name / value pairs >>>>>=20 >>>>> Options we considered: >>>>> ASN.1 - the 60s are calling and want their data back >>>>> XML-DSig - not URL safe, large size, and I personally had many >>>>> scars canonicalizing XML. (An earlier company of mine had a >>>>> contract to build XML-DSig libraries for a few languages) >>>>> JSON was becoming very cool at that time, and with base 64 URL = safe >>>>> encoding the string, it was URL safe, and treating the JSON text = as >>>>> binary dealt with the canonicalization concerns -- and JSON >>>>> canonicalization did not exist. >>>>>=20 >>>>> Using a dot as the separator between header, payload, and >>>>> signature made it easy to parse. The dot was URL safe, but not in >>>>> the base 64 set. >>>>>=20 >>>>> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >>>>>=20 >>>>> /Dick >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =E1=90=A7 >>>>>=20 >>>>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan = >>>>> wrote: >>>>>=20 >>>>> Dear Dispatch, >>>>>=20 >>>>> Anders Rundgren, Samuel, Erdtman, and I have been working on >>>>> an ID for your consideration. This document describes how to use >>>>> JWS and JCS to create plain-text JSON signatures. The abstract >>>>> reads as follows: >>>>>=20 >>>>> This document describes a method for extending the scope of >>>>> the JSON Web Signature (JWS) standard, called JWS/CT. By >>>>> combining the detached mode of JWS with the JSON Canonicalization >>>>> Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON >>>>> format after being signed (aka "Clear Text" signing). In addition >>>>> to supporting a consistent data format, this arrangement also >>>>> simplifies documentation, debugging, and logging. The ability to >>>>> embed signed JSON objects in other JSON objects, makes the use of >>>>> counter-signatures straightforward. >>>>>=20 >>>>> The data tracker page for this: >>>>> https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ >>>>>=20 >>>>> As you know there are large ecosystems that needs digital >>>>> signatures for plain text JSON data, meaning where the JSON data = is >>>>> not base64 encoded. This ID provides a solution using existing = IETF >>>>> RFCs to make this work. Further, this work looks to be adopted by >>>>> many groups and organizations from financial services, threat >>>>> intelligence, and incident response. >>>>>=20 >>>>> We are not sure what direction would be best for this work >>>>> in the IETF, should we send to the ISE for publication or do you >>>>> want to create a working group. Ultimately there is a lot of work >>>>> that could be done in this space to meet the needs of the market. >>>>> We would be happy with releasing these IDs for ISE publication, or >>>>> for creating a working group to move them forward. It is just >>>>> important to note that the market is in desperate need of these >>>>> solutions. If you want to take it for a spin, there is a JWS/CT >>>>> playground at: https://mobilepki.org/jws-ct >>>>>=20 >>>>> Thanks >>>>> Bret >>>>>=20 >>>>> -- >>>>> Sent from my TI-99/4A >>>>>=20 >>>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 >>>>> ACAE 7415 0050 >>>>> _______________________________________________ >>>>> art mailing list >>>>> art@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/art >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Secdispatch mailing list >>>> Secdispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 28 08:55: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 96BF13A11CD; Wed, 28 Apr 2021 08:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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] 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 cY3R4VIJPLw2; Wed, 28 Apr 2021 08:55:09 -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 01E563A1248; Wed, 28 Apr 2021 08:55:03 -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 4FVjrN6Q8Bzyft; Wed, 28 Apr 2021 17:55:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Wed, 28 Apr 2021 17:55:00 +0200 X-Mao-Original-Outgoing-Id: 641318100.441141-a8485cd991b2d7abdf0fa7b7c59963eb 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> To: art@ietf.org, IETF SecDispatch , DISPATCH , rfc-ise@rfc-editor.org X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Wed, 28 Apr 2021 15:55:12 -0000 Signing data at rest certainly is a use case that is worth addressing. =E2=80=9CRepresented in JSON=E2=80=9D is a weird way to say that the = data model that describes those data at rest is somehow compatible with = the JSON data model (which isn=E2=80=99t really fully defined, but that = is a problem that may not hurt you). So if you have a deterministic way = to transform your data at rest into the JSON-like data model subset = supported by RFC8785 (which is in turn based on the RFC7493 I-JSON = subset), you then can use RFC8785 to generate a text string that (using = UTF-8=E2=80=99s deterministic encoding) can in turn be used as a signing = input for well-known signature schemes such as JOSE or COSE. This is pretty much what XMLDSig set out to do, except that the XML data = model is even less well-defined and generating a deterministic signing = input from that is even more interesting. Small matters of = interoperability :-) None of this has anything to do with =E2=80=9Cclear text=E2=80=9D or = =E2=80=9Cplain text", which is an exceedingly bad label to apply to = signing data at rest that are believed to be convertable to an = RFC8785-subset JSON text. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 28 10:06:47 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 E4F333A170C; Wed, 28 Apr 2021 10:06:46 -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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 3_FI4Fxw18TU; Wed, 28 Apr 2021 10:06:41 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 717AE3A1708; Wed, 28 Apr 2021 10:06:41 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id k3-20020a17090ad083b0290155b934a295so3012922pju.2; Wed, 28 Apr 2021 10:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+xc7t7DZbJLX7ukgaJA/u4nxDO32xC1A8B/8LuZWzZw=; b=sPBoFDGCh7/rMuguZhe6u87kG7MKpOR7jAdfIo/tCmIuRH0z1CFSmJGapxe+S+D6oz fUg4IvM3TNGQo3WqVJFmxpPM3r3/r8K5tC7x3rLIYiHnyhKcnaWyyArTrTlHJFuWrmat W4K1y7FCe199fMLZ4zqxnSU8aCz3jTP+YZVQku/82zWb7ygpuiok2okLaGFbbPTykNep bAmk3NQV35SC4si/ds6LBfj0Ek//CUvroLeg7Qg8CxPuv9irccPJy3io3IFV0baENHaz mCwbz0jrlquHMYDbNhy1ET+FWW7IEs0GVJgI30uvfpFfm1mqSarKdnuHFcbzN+F6qgyS OVXg== 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=+xc7t7DZbJLX7ukgaJA/u4nxDO32xC1A8B/8LuZWzZw=; b=Rq+IoLVdm/TVHAbHU0a4Ofo0Nr1m+iuPnlG7APMNrbqL8dGv+n3KYuyghYo/jgsYTv AUWF6GeL3P6/sCEm58oU41xxc0VX0hzo2bdygZv96nvYgjKidst+O0wzBPw9a8vL/ROe h5MOh7LvKYDgtfyPbykThwi6dMt3RpzOcnNPKx3C4lsJNIQ5TBcAKYDtYf0IoMTiDG9m BUou0Rg8Ff7BI9+sBXo2lnZ56P2Qjq5Wut7CWH0+VwqbpWB42OWoBy2qOaP0Y3il5dm+ fBnsBv/C+gnYjyTjiD8s2teqHOpSqMYKbVHJc5PFieN4GvGO+zbgWmVluuEDiT0q1VGO Xx0A== X-Gm-Message-State: AOAM532cYW7E3hPd3tb4R/9fSwAjw9lappqI3ONtkvJPx+LbSi3aeELq 1ubmIGacm8DDsT4+4cM80XA= X-Google-Smtp-Source: ABdhPJzRs2S+frw3ms28zSoGO0Sb8mrBYIX92LpFfW0E0Sfx0L4OUIyxuEc9lzZAB54GtaxNX2RqLQ== X-Received: by 2002:a17:902:9685:b029:e9:abc1:7226 with SMTP id n5-20020a1709029685b02900e9abc17226mr31483518plp.64.1619629599782; Wed, 28 Apr 2021 10:06:39 -0700 (PDT) Received: from smtpclient.apple ([136.36.112.224]) by smtp.gmail.com with ESMTPSA id i126sm260693pfc.20.2021.04.28.10.06.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Apr 2021 10:06:39 -0700 (PDT) From: Bret Jordan Message-Id: <19A94F0B-19B6-4E19-B913-F27C5CB6AD32@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 28 Apr 2021 11:06:37 -0600 In-Reply-To: Cc: Dick Hardt , "art@ietf.org" , DISPATCH , "rfc-ise@rfc-editor.org" , IETF SecDispatch To: Stian Soiland-Reyes References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [Secdispatch] [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: Wed, 28 Apr 2021 17:06:47 -0000 --Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Stian. It would be great to use this in IEEE 2791. Let's see what = we need to do to make it more clear.=20 Bret > On Apr 28, 2021, at 3:21 AM, Stian Soiland-Reyes = wrote: >=20 > This draft is well written and an approach we would like to use in = IEEE 2791, and from your text it will fit right into our =E2=80=9Cetag=E2=80= =9D field = where we hope for a consistent hashing mechanism to = detect changes. > =20 > The draft seems to build on JSON Web Signature (RFC7515 = ) and JSON Web Key (RFC7517 = ), but the 3.1.3 is a bit = too brief for readers new to these standards, perhaps give a brief = summary for this example, especially as RFC7517 is quite comprehensive = with many options? > =20 > In particular it is unclear if the JWS Header also needs to be JSON = canonicalized =E2=80=93 which may be a good idea for consistent = =E2=80=9Chash=E2=80=9D purposes like in our use case? > =20 > Here=E2=80=99s my rough suggestion =E2=80=93 probably wrong! My = additions unindented. > =20 > 3.1.3. Generate a JWS String > =20 > Use the result of the previous step as "JWS Payload" to the = signature > process described in Appendix F of JWS [RFC7515]. > =20 > In short a detached JWS is represented as the string concatenated from > =20 > BASE64URL(UTF8(JWS Protected Header)) || '.' || > || '.' || > BASE64URL(JWS Signature) > =20 > Notice, for comparison with the JWS Compact Serialization,=20 > that the JWS Payload is not included in the detached JWS String,=20 > but replaced by an empty string. > =20 > For the example, the JWS header is assumed to be: > =20 > {"alg":"HS256"} > =20 > The above example is equal to its own JCS canonicalization.=20 > JSON Canonicalization is not a requirement for the=20 > JWS Header, however this is RECOMMENDED, combined with > a fixed algorithm choice, if generating a consistent JWS/CT signature > that is s also to be used as as a canonical version identifier=20 > of the JSON payload content, e.g. as a strong ETag (RFC7232). > =20 > The JWS Signature of the canonicalized JSON payload, using the key=20 > specified in Section 3, is the bytes > =20 > 54 75 48 b4 20 42 6f c4 39 x8 8e 3d 8a 66 ab xe=20 > d2 5e 4b 11 f6 b8 b5 34 xe 1a 90 3f 96 63 c3 > =20 > =20 > Encoding as Base64 > =20 > The resulting concatenated JWS string should then read as follows: > =20 > eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4 > =20 > =20 > You may want to move my ETag recommendation to an appendix, as I = don=E2=80=99t feel it fits well where I put it, but I think it is worth = pointing out. As a use case. > =20 > I don=E2=80=99t know enough about RFC7515, is it possible to do = something like regular SHA3 or would my fingerprint use case need to = just publicly declare the signature key to use? > =20 > =20 > -- > Stian Soiland-Reyes, The University of Manchester > https://www.esciencelab.org.uk/ > https://orcid.org/0000-0001-9842-9718 = > Please note that I may work flexibly =E2=80=93 whilst it suits me = to email now, > I do not expect a response or action outside of your own working = hours. > =20 > =20 > From: art > on = behalf of Bret Jordan > > Date: Wednesday, 28 April 2021 at 03:29 > To: Dick Hardt > > Cc: "art@ietf.org " >, DISPATCH >, "rfc-ise@rfc-editor.org = " >, IETF SecDispatch > > Subject: Re: [art] Plain text JSON digital signatures > =20 > Luckily this time we have RFC8785 that solves the canonicalization = problem for JSON.=20 >=20 > Bret=20 >=20 > Sent from my Commodore 64 > =20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >=20 >=20 >> On Apr 27, 2021, at 7:39 PM, Dick Hardt > wrote: >>=20 >> I am supportive of this work, and would also be willing to work = towards a PS. I am seeing rapid growth in the demand to embed JWS in = JWS. >> =20 >> Given my experience with XML-DSig (see below) making it more XML-DSig = like does not sound like a good thing. >> =20 >> For any interested in some JWT history, when we were brewing up what = became OAuth 2.0, we did not want to tie a token format to the = implementation as many deployments had their own proprietary token = formats -- but we knew new deployments would benefit from standardizing = a token. >> =20 >> Our requirements were: >> - URL safe (access tokens at the time were often passed as a query = parameter -- I know, not the best idea, but working with what people = wanted) >> - HTTP header safe >> - richer than name / value pairs >> =20 >> Options we considered: >> ASN.1 - the 60s are calling and want their data back >> XML-DSig - not URL safe, large size, and I personally had many scars = canonicalizing XML. (An earlier company of mine had a contract to build = XML-DSig libraries for a few languages) >> =20 >> JSON was becoming very cool at that time, and with base 64 URL safe = encoding the string, it was URL safe, and treating the JSON text as = binary dealt with the canonicalization concerns -- and JSON = canonicalization did not exist. >> =20 >> Using a dot as the separator between header, payload, and signature = made it easy to parse. The dot was URL safe, but not in the base 64 set. >> =20 >> And Simple Web Tokens were born -- to be renamed JSON Web Tokens. >> =20 >> /Dick >> =20 >> =20 >> =20 >> =20 >> =E1=90=A7 >> =20 >> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan > wrote: >>> Dear Dispatch, >>>=20 >>> Anders Rundgren, Samuel, Erdtman, and I have been working on an ID = for your consideration. This document describes how to use JWS and JCS = to create plain-text JSON signatures. The abstract reads as follows: >>>=20 >>> This document describes a method for extending the scope of the JSON = Web Signature (JWS) standard, called JWS/CT. By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing). In addition to supporting a consistent data format, = this arrangement also simplifies documentation, debugging, and logging. = The ability to embed signed JSON objects in other JSON objects, makes = the use of counter-signatures straightforward. >>>=20 >>> The data tracker page for this: = https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ = >>>=20 >>> As you know there are large ecosystems that needs digital signatures = for plain text JSON data, meaning where the JSON data is not base64 = encoded. This ID provides a solution using existing IETF RFCs to make = this work. Further, this work looks to be adopted by many groups and = organizations from financial services, threat intelligence, and incident = response.=20 >>>=20 >>> We are not sure what direction would be best for this work in the = IETF, should we send to the ISE for publication or do you want to create = a working group. Ultimately there is a lot of work that could be done in = this space to meet the needs of the market. We would be happy with = releasing these IDs for ISE publication, or for creating a working group = to move them forward. It is just important to note that the market is in = desperate need of these solutions. If you want to take it for a spin, = there is a JWS/CT playground at: https://mobilepki.org/jws-ct = >>> =20 >>> Thanks >>> Bret >>> =20 >>> --=20 >>> =20 >>> Sent from my TI-99/4A >>>=20 >>>=20 >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>> _______________________________________________ >>> art mailing list >>> art@ietf.org >>> https://www.ietf.org/mailman/listinfo/art = --Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Stian. It would be great to use this in IEEE 2791. = Let's see what we need to do to make it more clear. 

Bret


On Apr 28, 2021, at 3:21 AM, Stian = Soiland-Reyes <soiland-reyes@manchester.ac.uk> wrote:

This draft is well written and = an approach we would like to use in IEEE 2791, and from your text it = will fit right into our =E2=80=9Cetag=E2=80=9D field where we hope for a = consistent hashing mechanism to detect changes.
 
The draft seems to build on JSON Web Signature (RFC7515) and JSON Web = Key (RFC7517), but the 3.1.3 is a bit too = brief for readers new to these standards, perhaps give a brief summary = for this example, especially as RFC7517 is quite comprehensive with many = options?
 
In particular it is unclear if the JWS Header also needs to = be JSON canonicalized =E2=80=93 which may be a good idea for consistent = =E2=80=9Chash=E2=80=9D purposes like in our use case?
 
Here=E2=80=99s my rough suggestion =E2=80=93 probably wrong! = My additions unindented.
 
3.1.3.  Generate a JWS String
 
   Use the result of the previous step as "JWS =
Payload" to the signature
   process described in Appendix F of =
JWS [RFC7515].
 
In short a detached JWS is represented as the string =
concatenated from
 
      BASE64URL(UTF8(JWS Protected =
Header)) || '.' ||
      || '.' ||
      BASE64URL(JWS Signature)
 
Notice,=
 for comparison with the JWS Compact Serialization, =

that the JWS Payload is not included in =
the detached JWS String, 
but replaced by =
an empty string.
 
   For the example, the =
JWS header is assumed to be:
 
   {"alg":"HS256"}
 
The =
above example is equal to its own JCS canonicalization. 
JSON =
Canonicalization is not a requirement for the 
JWS =
Header, however this is RECOMMENDED, combined with
a =
fixed algorithm choice, if generating a consistent JWS/CT signature
that =
is s also to be used as as a canonical version identifier 
of =
the JSON payload content, e.g. as a strong ETag (RFC7232).
 
The =
JWS Signature of the canonicalized JSON payload, using the key 
specified in Section 3, is the bytes
 
54 75 48 b4 20 42 6f c4 39 x8 = 8e 3d 8a 66 ab xe 
d2 5e 4b 11 f6 b8 b5 34 xe 1a = 90 3f 96 63 c3
 
 
Encoding as Base64
 
The =
resulting concatenated JWS string should then read as follows:
 
   =
eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4
 
 
You may want to move my ETag recommendation to an appendix, = as I don=E2=80=99t feel it fits well where I put it, but I think it is = worth pointing out. As a use case.
 
I don=E2=80=99t know enough about RFC7515, is it possible to = do something like regular SHA3 or would my fingerprint use case need to = just publicly declare the signature key to use?
 
 
--
Stian = Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note = that I may work flexibly =E2=80=93 whilst it suits me to email now,
    I do not = expect a response or action outside of your own working hours.
 
 
From: art <art-bounces@ietf.org> on = behalf of Bret Jordan <jordan.ietf@gmail.com>
Date: Wednesday, 28 April = 2021 at 03:29
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "art@ietf.org" <art@ietf.org>, DISPATCH <dispatch@ietf.org>, "rfc-ise@rfc-editor.org" = <rfc-ise@rfc-editor.org>, = IETF SecDispatch <Secdispatch@ietf.org>
Subject: Re: [art] Plain text = JSON digital signatures
 

Luckily this time we have RFC8785 that solves the = canonicalization problem for JSON. 

Bret 

Sent from my Commodore 64
 
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050


On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

I am = supportive of this work, and would also be willing to work towards a PS. = I am seeing rapid growth in the demand to embed JWS in JWS.
 
Given = my experience with XML-DSig (see below) making it more XML-DSig like = does not sound like a good thing.
 
For any interested in some JWT = history, when we were brewing up what became OAuth 2.0, we did not want = to tie a token format to the implementation as many deployments had = their own proprietary token formats -- but we knew new deployments would = benefit from standardizing a token.
 
Our = requirements were:
- URL safe (access tokens at the time were often = passed as a query parameter -- I know, not the best idea, but = working with what people wanted)
- HTTP = header safe
- richer than name / value pairs
 
Options we considered:
ASN.1 - the 60s are calling and want = their data back
XML-DSig - not URL safe, large size, and I = personally had many scars canonicalizing XML. (An earlier company of = mine had a contract to build XML-DSig libraries for a few languages)
 
JSON was = becoming very cool at that time, and with base 64 URL safe encoding the = string, it was URL safe, and treating the JSON text as binary dealt with = the canonicalization concerns -- and JSON canonicalization did not = exist.
 
Using a dot as the = separator between header, payload, and signature made it easy to = parse. The dot was URL safe, but not in the base 64 set.
 
And = Simple Web Tokens were born -- to be renamed JSON Web Tokens.
 
/Dick
 
 
 
 
3D"Image=E1=90=A7
 
On Tue, Apr 27, 2021 at = 8:28 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dear = Dispatch,

Anders Rundgren, Samuel, Erdtman, = and I have been working on an ID for your consideration. This document = describes how to use JWS and JCS to create plain-text JSON signatures. = The abstract reads as follows:

This = document describes a method for extending the scope of the JSON Web = Signature (JWS) standard, called JWS/CT.  By combining the detached = mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables = JSON objects to remain in the JSON format after being signed (aka "Clear = Text" signing).  In addition to supporting a consistent data = format, this arrangement also simplifies documentation, debugging, and = logging.  The ability to embed signed JSON objects in other JSON = objects, makes the use of counter-signatures straightforward.

The data tracker page for this: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are large ecosystems that = needs digital signatures for plain text JSON data, meaning where the = JSON data is not base64 encoded. This ID provides a solution using = existing IETF RFCs to make this work. Further, this work looks to be = adopted by many groups and organizations from financial services, threat = intelligence, and incident response. 

We are not sure what direction would be best for this work in = the IETF, should we send to the ISE for publication or do you want to = create a working group. Ultimately there is a lot of work that could be = done in this space to meet the needs of the market. We would be happy = with releasing these IDs for ISE publication, or for creating a working = group to move them forward. It is just important to note that the market = is in desperate need of these solutions. If you want to take it for a = spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct
 
Thanks
Bret
 
-- 
 
Sent from my TI-99/4A


PGP Fingerprint: 63B4 FC53 = 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
_______________________________________________art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

= --Apple-Mail=_C2F3C8C4-DEFB-4D6B-A423-EA8BE3563CA4-- From nobody Wed Apr 28 19:06:32 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 E715D3A2A28; Wed, 28 Apr 2021 19:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 rh24c09-M3sV; Wed, 28 Apr 2021 19:06:18 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 2C8EA3A2A29; Wed, 28 Apr 2021 19:06:18 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 82-20020a1c01550000b0290142562ff7c9so5743699wmb.3; Wed, 28 Apr 2021 19:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zB0ww5WbhBaakRYwIOhQfl7GxxPU0HnZpVLdUTe2bpw=; b=KlUbK4R0H8N5BQB60zRLptIaYssejJdVeehs2P0uxyItN7izQCYJ0uGKfUVTG6xNsg V6Z2qyuKi0ACF2KdP2yVmbx7uAwCsnNlvbB9VMKkDjfeNiqD+PjmDlIr2P0oiydRA8ij BmYYR9l9d2/xnteAM6x4wQXma/eOICjRgIL5wrlPUEBe6RwfbAs3UZiVFwgpaVYodg+k XU3reMtet753lsblTev+ECtf6JD+Jm9aTj7NTldtvVA0tpmLb7anBx9Wn1lPykAutk97 zoKSveBw5H3gbnIE0cg7tLB9p2oaz0zNKACxNVuh2isd0zL5322w8WPltOSiksxw7pFZ LhWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zB0ww5WbhBaakRYwIOhQfl7GxxPU0HnZpVLdUTe2bpw=; b=pRpg8AHfHIOS2rdcZM+Li8hDKBqdZG/gZtWLoMzbljDuFhfekko56/epeHnHFN3eEv sP4X4rTQszZeF4K7e2rdeaD0zZ0/RKb026UAwgJOSsYf0pPZh/6dJ/iMmW/Zz4w7+cAj wS+ZT0MqkDjoPJ3RPjlZPCjKxipUqh/TBhgsQaD85FStIDmefv9sor16nt99atF6tqDX xTAmDHoMtudG4ND3Blimxpga0rRg9Mm8F9BZD/15IwvPk5DfCSvLlS+lt9L0SPYle87Z 1wq4sh5DMmUagx368K4Hdq3u9HnA/PDKKaEyfQYNxaCqBFbmATiqdnVW7bQ+/piCmVf+ RwZw== X-Gm-Message-State: AOAM53293mLrtgrmiv67Yxce18iBB53qbvSYUSdhlJoTOf7H6f3gn9TH vxK5TqkNS1jV1S1/aHCLqwg= X-Google-Smtp-Source: ABdhPJwZwkI1+ZXOe+86em7xU7ja7BM81TY4BFYLU79ru4pJat53wUwZDasxenyVSiqd2/ULYSdFxw== X-Received: by 2002:a05:600c:4f14:: with SMTP id l20mr4535486wmq.150.1619661974798; Wed, 28 Apr 2021 19:06:14 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id q20sm13657783wmq.2.2021.04.28.19.06.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 19:06:14 -0700 (PDT) To: Stefan Santesson Cc: DISPATCH , art@ietf.org, IETF SecDispatch , rfc-ise@rfc-editor.org 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> From: Anders Rundgren Message-ID: Date: Thu, 29 Apr 2021 04:06:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 29 Apr 2021 02:06:23 -0000 On 2021-04-28 11:29, Stefan Santesson wrote: > RFC 7797 is supported by common open source such as Nimbus and I use it > for instances where you obviously do not need a URL safe token. I see. > As such it works for JWS but Not for JWT. But It works really well and > saves space when URL safeness is not needed. That's great. Note though that this scheme require that '.' are escaped into \u002e as can be seen in the example below. Data to sign: { "payee": "Space Shop", "amount": { "currency": "EUR", "value": "100.00" } } Using RFC 7797 (with "b64":false,"crit":["b64"]): eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19.{"amount":{"currency":"EUR","value":"100\u002e00"},"payee":"Space Shop"}.KFOhCfpyZnW7RUpwOvZAJPKDfpF1R2uENirUW6Ew4v1HwQI5iFJaXKW0PsvTuVNpb-T_UjpOcv868qihMjeMwA Using JWS/CT (here pretty-printed using standard JSON tools): { "payee": "Space Shop", "amount": { "currency": "EUR", "value": "100.00" }, "signature": "eyJhbGciOiJFUzI1NiJ9..aY27xoS5B3J-uZtUdJzXevqBbnNf4vNT1YN1_eHPOcILMXlVu3VjdExW17f66EGdt4mxQSnpAVLsUa4k2zSLQw" } > So I guess your answer is that it still encapsulates the signed JSON in > the signature, and that the proposal really is about embedding signature > in the JSON object being signed (and not about whether the JSON is in > plaintext). JWS/CT addresses several issues: - Maintaining a consistent message structure - Maintaining JSON notation - Full compliance with JavaScript and browser APIs (including the "JSON" object). However, from an IETF adoption point of view it is rather the validity and reliance on RFC 8785 that is the core issue. > Could you elaborate why you think it is important to NOT embed signed > data in the signature? The example above may serve this purpose. > What is the usecase? See this response to Carsten: https://mailarchive.ietf.org/arch/msg/dispatch/3EX1uM9K_oCft7BoQfW3EQj_En4/ thanx, Anders > > /Stefan > > > On 2021-04-28 11:00, Anders Rundgren wrote: >> On 2021-04-28 8:52, Stefan Santesson wrote: >>> How is this different/better than implementing RFC 7797 and apply the >>> header b64=false in order to carry plaintext JSON in the payload? >> >> Good question! >> >> Apart from the fact that the data becomes embedded in the JWS >> signature container (=changing the structure), you cannot really put >> JSON there: >> https://tools.ietf.org/html/rfc7797#section-5.2 >> >> My guess that the only real-world use of this option is to save an >> internal-only (but technically redundant) Base64Url-operation for >> truly detached data, be it it JSON, PNG, etc. >> >> JWS/CT was designed for signing JSON Objects ({}), and let them remain >> as such. >> >> Thanx, >> Anders >> From nobody Fri Apr 30 14:37:53 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 003B03A27C6 for ; Fri, 30 Apr 2021 14:37:51 -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=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 a7obG3u1fGc3 for ; Fri, 30 Apr 2021 14:37:46 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 41AC33A27C3 for ; Fri, 30 Apr 2021 14:37:45 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id e25so41428125oii.2 for ; Fri, 30 Apr 2021 14:37:45 -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=w1Q1xCyUlS5YecimIPNpEdvwo4WoaGXjHkYy0ET4Gq8=; b=G+5BD/4+MSxUlOssMP9ekqqDkHdKas3UOPNUHa9qTsD1njDIGILR2CXOKcZRM055pA OLrbqTVKHeKNhfK4UsqC3/PevtsnBCwPCr8fGtmR5rzEINGvPO5Q+wdxV2cC3Q/GxGy3 t7AOwr/zui2SpmsFO/Y9vpqw9XAkygpPVbX6SArALx1pCRHs1W/9sLh90JWaq4SRtNJs m8IqKfHNznC+OJ0vMDnsVD1Og3WuMmio9QgEy99Cy1sMu9XlBRK2M5f5w0KQHdMlAV/b ORzQ4KW8tGDRXoNySTFW4BDxH+4cOEni7UwkzVkPOt5HaUfglfGcK0HNDzQ332UYxbe2 gLLw== 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=w1Q1xCyUlS5YecimIPNpEdvwo4WoaGXjHkYy0ET4Gq8=; b=kHXCfonpuJAr59Y8qEqysJLmJfCVg/XyWfLqlj5P3kMAHLHLvP6RFLB2lms0IgXbaF D26UwMNFkQhNvjUrBz0hhZYQftk0KOed5NoIKy1hvQ+GkiLZwV7hp/aN/h4KdBxW03zd znDSDX9nHrWhBVxVkgtZmZGZHOvZhOokZB2AuVBGgnzGEerkbDximL4b3MA/t6pjI+SH vV5LZthk8dEJG7kV8YEqKsqB2DeWhjjx3z3gcmCE9RGqOXAisw5ysiGS2gK1Lv0BVstT ihoGxK+9J2pamkqt7eSF+sucbFZpB5wUm3v8EZC/HWl0+vguhjv5iyu3ZP1lTbExzeMj E3fw== X-Gm-Message-State: AOAM530a/lmbQ0MjvK0XnzfF2M3SZ3v/m8Aq5NB/TWnCezOGjbUHSCIk TVV/h458ez0drRBvhaMfmQU6ZHhlaFqxxIHPj4895w== X-Google-Smtp-Source: ABdhPJzbixKWZxm7UKJpZ9r8taFjtGVuQHCHeq99EycD1ixd5lv2sZMGeIN4XADlSjaajU5RSPpCWY5CVSPWGbNPsiE= X-Received: by 2002:aca:b9c1:: with SMTP id j184mr5470835oif.134.1619818664336; Fri, 30 Apr 2021 14:37:44 -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> In-Reply-To: From: Samuel Erdtman Date: Fri, 30 Apr 2021 23:37:32 +0200 Message-ID: To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="00000000000016ddaf05c1376c64" 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: Fri, 30 Apr 2021 21:37:51 -0000 --00000000000016ddaf05c1376c64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, Thank you for sharing your thoughts. I=C2=B4m not sure I understand your point, maybe you could elaborate a bit = (I have some questions). 1. What do you mean with data at rest, data store in database or file? Or is it data that does not change? Sorry I do not get it. 2. What is weird with saying "Represented in JSON"? 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) 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 that this effort will be as tricky as XMLDigSig. do you think so? 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain tex= t" being bad descriptions. Yes what is signed is the RFC8785 transformation 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=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. Best regards //Samuel On Wed, Apr 28, 2021 at 5:56 PM Carsten Bormann wrote: > Signing data at rest certainly is a use case that is worth addressing. > > =E2=80=9CRepresented in JSON=E2=80=9D is a weird way to say that the data= model that > describes those data at rest is somehow compatible with the JSON data mod= el > (which isn=E2=80=99t really fully defined, but that is a problem that may= not hurt > you). So if you have a deterministic way to transform your data at rest > into the JSON-like data model subset supported by RFC8785 (which is in tu= rn > based on the RFC7493 I-JSON subset), you then can use RFC8785 to generate= a > text string that (using UTF-8=E2=80=99s deterministic encoding) can in tu= rn be used > as a signing input for well-known signature schemes such as JOSE or COSE. > > This is pretty much what XMLDSig set out to do, except that the XML data > model is even less well-defined and generating a deterministic signing > input from that is even more interesting. Small matters of > interoperability :-) > > None of this has anything to do with =E2=80=9Cclear text=E2=80=9D or =E2= =80=9Cplain text", which > is an exceedingly bad label to apply to signing data at rest that are > believed to be convertable to an RFC8785-subset JSON text. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000016ddaf05c1376c64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten,

Thank you for sh= aring your thoughts.

I=C2=B4m not sure I under= stand your point, maybe you could elaborate a bit (I have some questions).<= /div>
1. What do you mean with data at rest, data store in database or = file? Or is it data that does not change? Sorry I do not get it.
=
2. What is weird with saying "Represented in JSON"= ? is it that the RFC7493 I-JSON subset is not all that JSON could be? (to m= e this is a reasonable limitation that I in practice never have had to go o= utside)

3. So I totally get that one does not = like XMLDigSig, in my opinion not because of the signing procedures but bec= ause of the canonicalization process. When I looked at it I gave up and cre= ated a hardcoded template. The difference in canonicalization of JSON (RFC7= 493 I-JSON subset) according to RFC8785 is like night and day compared to X= ML 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?
=
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 RF= C8785 transformation 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=9Cplain text" as opposed to base64-url encoded. I guess envelo= ped JWS is a more accurate name but =E2=80=9Cclear text=E2=80=9D or =E2=80= =9Cplain text" is easy to understand.

Best re= gards
//Samuel








<= div class=3D"gmail_quote">
On Wed, Apr= 28, 2021 at 5:56 PM Carsten Bormann <ca= bo@tzi.org> wrote:
Signing data at rest certainly is a use case that is worth addre= ssing.

=E2=80=9CRepresented in JSON=E2=80=9D is a weird way to say that the data m= odel that describes those data at rest is somehow compatible with the JSON = data model (which isn=E2=80=99t really fully defined, but that is a problem= that may not hurt you).=C2=A0 So if you have a deterministic way to transf= orm your data at rest into the JSON-like data model subset supported by RFC= 8785 (which is in turn based on the RFC7493 I-JSON subset), you then can us= e RFC8785 to generate a text string that (using UTF-8=E2=80=99s determinist= ic encoding) can in turn be used as a signing input for well-known signatur= e schemes such as JOSE or COSE.

This is pretty much what XMLDSig set out to do, except that the XML data mo= del is even less well-defined and generating a deterministic signing input = from that is even more interesting.=C2=A0 Small matters of interoperability= :-)

None of this has anything to do with =E2=80=9Cclear text=E2=80=9D or =E2=80= =9Cplain text", which is an exceedingly bad label to apply to signing = data at rest that are believed to be convertable to an RFC8785-subset JSON = text.

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

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000016ddaf05c1376c64-- From nobody Fri Apr 30 16:05:00 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 5017D3A2A46; Fri, 30 Apr 2021 16:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9xBYZT2i63BK; Fri, 30 Apr 2021 16:04:47 -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 86C7D3A2A5A; Fri, 30 Apr 2021 16:04:46 -0700 (PDT) Received: from smtpclient.apple (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 4FX7HH5SCczyTV; Sat, 1 May 2021 01:04:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Carsten Bormann In-Reply-To: Date: Sat, 1 May 2021 01:04:43 +0200 Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Transfer-Encoding: quoted-printable Message-Id: <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> 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> To: Samuel Erdtman X-Mailer: Apple Mail (2.3654.80.0.2.43) 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: Fri, 30 Apr 2021 23:04:52 -0000 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 = produce 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? > 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? 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. > 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 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.) > 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 that 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 = canonicalization, 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 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 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=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. 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 = both. Archived-At: = = and the thread behind that. From nobody Fri Apr 30 22:10:23 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 60CAC3A34FE; Fri, 30 Apr 2021 22:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 VWlxTTEL-Erj; Fri, 30 Apr 2021 22:09:55 -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 ACE723A34F6; Fri, 30 Apr 2021 22:09:54 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a4so86153wrr.2; Fri, 30 Apr 2021 22:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=u8qIHe5b4hf0eWlCnhn0XaplDlT7QB4WqvllYh2vxb8=; b=Fp8hljepo4sks3fFVW0zZOC3wnSIXMo3BkxPnwl7nMLkFVwTAIw53SooS7D2ddeVoI JaKMZezUcu28YhvHMPOG0CIn5L52tjGon5V6TZPcdnz75hY9wo4ec4NhvLCONnq10/0f N+LDdK1pGZuiQinpt0GQMkChuZvh6GoO3HVDJFo8XFBJAhOqlAK6LuPX23DIdBnfi+1Q DxDjdyLUHuvZxK+4dFP/CgWNKn0bRzg0DMVfCo3pSutJDmHKAMdweWLicqmw6lF2tbhm V29EevScth3e451Lff9PIC7Lj9Q2wHZjyiTEegjQdLQER8rNt8z24pHeigGU4wXLMJae vkpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=u8qIHe5b4hf0eWlCnhn0XaplDlT7QB4WqvllYh2vxb8=; b=XRLMIsAncl2n6X0A5XNKMhEhWCQiBiogZK/YLm7EYDlO3ry0gnmU0KkgEYPQKgh6S6 v/cha7TZzVnmFuLfvrjjtLwy7W0ErWwb/eKCBtRSpML+jVJuyyh7G9y+GYR1etd6seHc GpRhxljBpzwxXPkdt4cwCBq1te+Kvj8IDS1bNqqCY1Npannfvuj7UdZaGL0MwMq+4sNe +A4FDhrzZY+QKRUuveG/Iv4kkjujW++YVSSBjU0uHkzd2fbo5E1/2QdLJJXmStgyHhEu NhOqy97Y45crcO2F/SeiQT1cbxl0wmkptIYvvrSlBA4plmpTJ4T3ukJxrpZcwJJx59cX h5zA== X-Gm-Message-State: AOAM531MR/ORc9lpkbSCJDwXLPV0Vz7qgMbBZOf3hHxY6bCbO7Yks0YL XTRXdr7SWmppBW1ecIwje70= X-Google-Smtp-Source: ABdhPJzG2Vd42Waskgx8kWUJYOI4N8KXoR7jnjvsu4mE1+ikwFDArIryXdIfrxdWSDnuL4Jz3J1LFg== X-Received: by 2002:adf:facf:: with SMTP id a15mr12132964wrs.53.1619845791872; Fri, 30 Apr 2021 22:09:51 -0700 (PDT) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id y125sm4560376wmy.34.2021.04.30.22.09.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Apr 2021 22:09:50 -0700 (PDT) To: Carsten Bormann , Samuel Erdtman Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" 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> From: Anders Rundgren Message-ID: <94ced44c-7a45-0870-e2bd-fb4909324a61@gmail.com> Date: Sat, 1 May 2021 07:09:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 05:10:00 -0000 On 2021-05-01 1:04, Carsten Bormann wrote: > Your scheme does NOT require (or benefit in any way from) representing the data in JSON. I don't have an answer or solution for people who firmly believe that JSON is (more or less) useless. Stepping-up the game a bit :) We have had 25y+ (!) of non-standard, security-broken, and user-hostile on-line payment-systems. AFAIK, the following document is currently the ONLY specification that addresses this obvious deficiency: https://fido-web-pay.github.io/specification/#operation Browsers, FIDO, JavaScript, JSON, JWS, JWE, RFC 8785, and JWS/CT are the corner stones of this proposal. Yes, there is even a spoon with CBOR/COSE there. Regarding RFC 8785, it works as claimed for applications adhering to two fairly reasonable requirements: - Sticking to I-JSON where the SHOULDs are interpreted as MUSTs. - Using parser schemes that do not mess up data embedded in JSON strings (like converting "2021-05-01T10:00:00Z" to "2021-05-01T09:00:00+01:00"). In all "modesty", Anders > 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 produce 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? > >> Or is it data that does not change? Sorry I do not get it. >> >> 2. What is weird with saying "Represented in JSON”? > > 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. > >> 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 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.) > >> 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 that 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’t in the canonicalization, 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 input. > >> 4. Not sure I agree with “clear text” or “plain text" being bad descriptions. Yes what is signed is the RFC8785 transformation of the input data, but the signature are then put into your data keeping the data in its original “clear text” or “plain text" as opposed to base64-url encoded. I guess enveloped JWS is a more accurate name but “clear text” or “plain 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. > > Grüße, 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’s (deliberate!) lack of extensibility, or both. Archived-At: and the thread behind that. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >