From nobody Wed Oct 10 12:04:26 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5C712426A for ; Wed, 10 Oct 2018 12:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 S-Z1shfqYx3f for ; Wed, 10 Oct 2018 12:04:21 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 7257F124BE5 for ; Wed, 10 Oct 2018 12:04:21 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id o8-v6so2636694ybk.13 for ; Wed, 10 Oct 2018 12:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=shn+XeK1Dd6WN8bY4YV7ghtxi7a5BA7h/dZKmgZUaXc=; b=QAqB2ZAlkaSgxvs6R4A8G8zvaAVXjFoQTWCuPqcZgfUQ9vJC3F2OV99Hflki37fByt T7uQTnLVgqwIuNzi+NhIFjsAlvjQfHDuhdpGmz6urXQrpaBhZev7/+xGcC3UJGgPt7p3 vWfm3MesgCkoGQxchxgRmQA5BRid9LujFPqrQqCQsqZbD39AwvVm4+zOu+ncnZN6mqSa 68a5c8xIqN3GuJexXQV1/0vS1rp0c8jfzB1f45EuaODYQ0dNFPK+lVaRmk9Z3RT1dJ9w vhwTziUB7AyJ30FDsHoIgilPXZ6ZC/daQ4Z213LKl2PVuSqU9IW4tPVCv0avZlnVj7AN JGxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=shn+XeK1Dd6WN8bY4YV7ghtxi7a5BA7h/dZKmgZUaXc=; b=c8OpCTqMK6rJLz/pp3NvakrD/t/UUJ9txi26z8+qpcs9pB+nEIL8u+eRUJCBgTmXJ3 dgI0rtFnhqKUk16HOLoSJ85C8SAvIw2WUgSWjplVeYR+0RY2kkUJEcWG8PwzuvjMFxLV 2wRWoAi0mN1zSB/O4cIlA/CfoHdayYai4awYb3Jxk6WRPebsN36uVxLO5BIL4eJrHHDv DpjWH8tluk/WxUJEXd3s698aY0OhvHiIPBuJzScB8NbL/+7XSXFgXLmOuVogP6TZwx36 oGsk5nD/kZ+BaOjp02jxRjWAzosg7AmJV13wsgkxULO7GseAyB2bK573nN+QvFsF50BN o5Dg== X-Gm-Message-State: ABuFfoiZ1ZNmN8BBW7xC+6q9qc3Ya/s5fgdqve4S71/mCY1hoJryjrkD MQiwKh9Pmi/oqtznCTYby6KlZaFd X-Google-Smtp-Source: ACcGV62mtmnCAq76HuPvC1qGd2ZJpoGD/SaKZ0GodNVI6vSxY2XvtwtCR4O3okaCPIdgrlwHJq7jvQ== X-Received: by 2002:a25:b28b:: with SMTP id k11-v6mr19485283ybj.118.1539198260277; Wed, 10 Oct 2018 12:04:20 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:11d5:fada:d8f3:ba5c? ([2605:a601:3260:266:11d5:fada:d8f3:ba5c]) by smtp.gmail.com with ESMTPSA id m82-v6sm4729238ywc.67.2018.10.10.12.04.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 12:04:19 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_2B4A6474-6D1F-48BF-86AC-F5942F80AA87" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> Date: Wed, 10 Oct 2018 13:03:41 -0600 To: jose@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 19:04:24 -0000 --Apple-Mail=_2B4A6474-6D1F-48BF-86AC-F5942F80AA87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear WG, I was reading through RFC 7515 to see if it would work for a project I = am working on. Basically the need to sign and resign a JSON object. = However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures. Super simple example { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80=9D= : =E2=80=9C1000 sq feet=E2=80=9D } Or=20 { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D,=20 =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D } Or {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:=E2= =80=9C1000 sq feet=E2=80=9D} Or (tabs not spaces) { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D,=20 =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D } All four of these JSON structures would produce a different signature as = defined by RFC 7515. What am I missing? Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." --Apple-Mail=_2B4A6474-6D1F-48BF-86AC-F5942F80AA87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear WG,

I was reading through RFC 7515 to see if it would work for a = project I am working on.  Basically the need to sign and resign a = JSON object.  However, in RFC 7515 there does not seem to be any = definition for serializing a canonical form of JSON. This means that two = organizations that serialize it differently would produce two different = signatures.

Super simple example

{ =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse= =E2=80=9D, =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D = }



Or 

{
  =E2=80=9Ctype=E2=80= =9D : =E2=80=9Chouse=E2=80=9D, 
  = =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D
}



Or

{=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D= ,=E2=80=9Csize=E2=80=9D:=E2=80=9C1000 sq feet=E2=80=9D}



Or (tabs not = spaces)

{
=E2=80=9Ctype=E2=80= =9D : =E2=80=9Chouse=E2=80=9D, 
= =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D
}


All four of these JSON = structures would produce a different signature as defined by RFC 7515. = What am I missing?


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

= --Apple-Mail=_2B4A6474-6D1F-48BF-86AC-F5942F80AA87-- From nobody Wed Oct 10 12:15:16 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB010126BED for ; Wed, 10 Oct 2018 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 1C-sSt3D7ZF6 for ; Wed, 10 Oct 2018 12:15:13 -0700 (PDT) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (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 C92A1120072 for ; Wed, 10 Oct 2018 12:15:12 -0700 (PDT) Received: by mail-qt1-f171.google.com with SMTP id o17-v6so7042012qtr.1 for ; Wed, 10 Oct 2018 12:15:12 -0700 (PDT) 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:content-transfer-encoding; bh=NvPRouvusMIXXJhMwYjFVT8qxWeCj3VstYyTQPB1yuc=; b=Ecuehi0JtK8B4EYo7CPfVWS5mfvHD+AOOgw+HUTq15MMakMWw6ywMMMrBOS1vJrXWE le6/UxI3j/8/gm7K0kWz+LnsITlvQSisbLlIdkwUeHOoG70Wcijv0PAhaJTvfyNGeLrH 2nRbPEtPSNFWc74GtAUoEGGnuvB8eNqBP7HTPPjVCalfpbpuG96i590m3DpwRMkccssA uwzIzvbM3+AbGXuaCT8BXdiuYEvhttcQUKiKdiXahnVkLIczXO7BebcX26J9vqEXemCg vdUuZh5iz6J8zS3BqHvZN7XETsIiR9hEfaPzmYyS/W446ositxHbC9aavJ8DMbNsmsNt kpcQ== X-Gm-Message-State: ABuFfoigsjNXGSR6pXZHzesE3Hu1en2veI/7zj0oaGg1fVbFGMtmu4fh EC6DqM5RXfjbiRi/WQj+bgDGlxQZlZyBpjnHGw1RyQLg X-Google-Smtp-Source: ACcGV619cFZzDiYV2uAsyELx996dq+0f5+Kyk4gGHrs/RTJ+Na0OtM5A3zZIQ+yrfqJhO/ILkrq38MbD9uiJGuSOU9A= X-Received: by 2002:a0c:988a:: with SMTP id f10-v6mr28039389qvd.178.1539198911645; Wed, 10 Oct 2018 12:15:11 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> In-Reply-To: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> From: Nathaniel McCallum Date: Wed, 10 Oct 2018 15:15:00 -0400 Message-ID: To: jordan.ietf@gmail.com Cc: jose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 19:15:15 -0000 JWS signs a byte stream, not JSON. If you want to use a JWS to sign JSON data it is your responsibility to ensure that both sides produce an equivalent byte stream. On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan wrote: > > Dear WG, > > I was reading through RFC 7515 to see if it would work for a project I am= working on. Basically the need to sign and resign a JSON object. However= , in RFC 7515 there does not seem to be any definition for serializing a ca= nonical form of JSON. This means that two organizations that serialize it d= ifferently would produce two different signatures. > > Super simple example > > { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80= =9D : =E2=80=9C1000 sq feet=E2=80=9D } > > > > Or > > { > =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, > =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D > } > > > > Or > > {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:= =E2=80=9C1000 sq feet=E2=80=9D} > > > > Or (tabs not spaces) > > { > =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, > =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D > } > > > All four of these JSON structures would produce a different signature as = defined by RFC 7515. What am I missing? > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that c= an not be unscrambled is an egg." > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Wed Oct 10 13:49:36 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D073D128CB7 for ; Wed, 10 Oct 2018 13:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 gp_8vu-hmrMa for ; Wed, 10 Oct 2018 13:49:32 -0700 (PDT) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 86376128A6E for ; Wed, 10 Oct 2018 13:49:32 -0700 (PDT) Received: by mail-yw1-xc33.google.com with SMTP id v198-v6so2727615ywg.12 for ; Wed, 10 Oct 2018 13:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=R3L8+GUjQgiulE/MnLD77KLnVMjw1+jUeRxWSaFtQ8o=; b=RbX+5+k5aRlhe3jG6makCJ5LOnvsL1vegijlpm60Myl+XvP/Pqfk02I1+3EA7olCiN kFxgySZBpBYGVK3UWY44+XXhd/OKhUlLBpKw7o6sx2eSsD/FTI67FN1YVKG3RA6moRtD dBiXmpohJO58rV19Kt9T/jjXKS7Jul977xOeyOJE7waZc1881hCpNfS9o7a50+aU1cYK 6F2WUWArui3tZ5uG5EmBuFEvU95FKOAmNoG/hEgIeHHg0Wn1pe0B9/exHLayth3D2d+/ p1A9KY5YPNUKgC6NBSFNTl0xBDLLRHGpb4+tdWnzpMI67Z/sq/Nja+JV8PMNq8jQ5iWN VqTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=R3L8+GUjQgiulE/MnLD77KLnVMjw1+jUeRxWSaFtQ8o=; b=gsQ01d4mFBbv6Jq+uiBVMHOphgYCm4QijrrLb/yLQ9+lEQDrUjE7TtzEvZ0VthjS2V VFEgGLSKp45nB9Efc2gQKktJ6LxTb3ar6uLt828URY4Nn4sHOKgFhj8yJTUFKtGq8gEM R5f+oMOeVbRjR8nS3AEcEkGCsyRN3vxSP8x9AwLlpyB/2kkjglixaIpSIDrYSyNQTNkM IIJQxsP+DK32KFTtLDFU8syvmv2+aovIQzZHhL9ab+vB+T2RW/kAt/R+C1QD72G5f76B yi8ZUnVBRJIsxGoLdx/pQLhFtd/yiLAM87DAt9vO9OV4mMj+emclNUosj3E2pqXS87yi b6Lg== X-Gm-Message-State: ABuFfojv5BqVGx8EiR1TNzDodB5b04C+RNKnJzrxqPjjY0DsvL4zsLyD o6E2WpcZVwNe9/qJVvlV8q8= X-Google-Smtp-Source: ACcGV63KD7YonWjyhgHy96ZnR/41M6MBMWH+OfcaTgMw987kaxwRTNRIwrruM2GPMuvZ0x51+H7z7g== X-Received: by 2002:a81:6702:: with SMTP id b2-v6mr19822870ywc.94.1539204571676; Wed, 10 Oct 2018 13:49:31 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:11d5:fada:d8f3:ba5c? ([2605:a601:3260:266:11d5:fada:d8f3:ba5c]) by smtp.gmail.com with ESMTPSA id l30-v6sm34154099ywa.104.2018.10.10.13.49.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 13:49:30 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_0E521857-575A-4954-8D73-3FB98CD91970" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 10 Oct 2018 14:48:52 -0600 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> To: Nathaniel McCallum , jose@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 20:49:35 -0000 --Apple-Mail=_0E521857-575A-4954-8D73-3FB98CD91970 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Would this WG be open to working on a solution to sign JSON (not a byte = stream) and define a canonical representation for said JSON? Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum = wrote: >=20 > JWS signs a byte stream, not JSON. If you want to use a JWS to sign > JSON data it is your responsibility to ensure that both sides produce > an equivalent byte stream. > On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan = wrote: >>=20 >> Dear WG, >>=20 >> I was reading through RFC 7515 to see if it would work for a project = I am working on. Basically the need to sign and resign a JSON object. = However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures. >>=20 >> Super simple example >>=20 >> { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80= =9D : =E2=80=9C1000 sq feet=E2=80=9D } >>=20 >>=20 >>=20 >> Or >>=20 >> { >> =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, >> =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D >> } >>=20 >>=20 >>=20 >> Or >>=20 >> {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:= =E2=80=9C1000 sq feet=E2=80=9D} >>=20 >>=20 >>=20 >> Or (tabs not spaces) >>=20 >> { >> =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, >> =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D >> } >>=20 >>=20 >> All four of these JSON structures would produce a different signature = as defined by RFC 7515. What am I missing? >>=20 >>=20 >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0E521857-575A-4954-8D73-3FB98CD91970 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Would= this WG be open to working on a solution to sign JSON (not a byte = stream) and define a canonical representation for said JSON?


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

JWS = signs a byte stream, not JSON. If you want to use a JWS to sign
JSON data it is your responsibility to ensure that both sides = produce
an equivalent byte stream.
On Wed, = Oct 10, 2018 at 3:04 PM Bret Jordan <jordan.ietf@gmail.com> wrote:

Dear WG,

I was reading through RFC 7515 to see if it would work for a = project I am working on.  Basically the need to sign and resign a = JSON object.  However, in RFC 7515 there does not seem to be any = definition for serializing a canonical form of JSON. This means that two = organizations that serialize it differently would produce two different = signatures.

Super simple example

{ =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D= , =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D }



Or

{
 =E2=80=9Ctype=E2=80=9D = : =E2=80=9Chouse=E2=80=9D,
 =E2=80=9Csize=E2=80=9D : = =E2=80=9C1000 sq feet=E2=80=9D
}



Or

{=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2= =80=9D:=E2=80=9C1000 sq feet=E2=80=9D}



Or (tabs not spaces)

{
=E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D= ,
=E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D}


All four of = these JSON structures would produce a different signature as defined by = RFC 7515. What am I missing?


Thanks,
Bret
PGP Fingerprint: = 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_0E521857-575A-4954-8D73-3FB98CD91970-- From nobody Wed Oct 10 14:03:07 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8E128CB7 for ; Wed, 10 Oct 2018 14:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 B_XYij4bXOJ4 for ; Wed, 10 Oct 2018 14:03:03 -0700 (PDT) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (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 B506E128A6E for ; Wed, 10 Oct 2018 14:03:03 -0700 (PDT) Received: by mail-qt1-f175.google.com with SMTP id l9-v6so7431122qtf.5 for ; Wed, 10 Oct 2018 14:03:03 -0700 (PDT) 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:content-transfer-encoding; bh=r/s/FxAsBn0lslghM63Ys2Q8fdvHaqVBLgQdm2W/gtc=; b=nVvzPbY/kdpu0rM6P5Xa4zY4O9DY8bYIXGmMnm74DWzBbTWs2aijwN0kRGiEzqPCe3 c1x3KMt14uGx4v9Z7hnhq2jP/bXCw8Vog/dhkbZlOGSAtkjrCC/RMMdZeTNnwXURMmTP RyQsosJ5pA7dv18HY2dsvZDMGdugm6jtSkPZT4CdoL7p06cQl/B4+XN920C+uWmS3vMh B1nY6cjilPTgLWbPnZAIwO4iOhnCjIKDWq8duCbHLQzL+HWv0LtpJCejefxjRaj3gOFU h15bdwThIWqninWAPBPUIjBQVm5xdg9FooFbLB+T78bSqL71gLmSYFYKKG1u1tOVU7ML RkTg== X-Gm-Message-State: ABuFfoiXZ3o/eX5MfFbEZCqXELCEDgPzkfpwMzO8gEti0Kiou9VGd1Gl 7gxYJzvZ4agLM0D+2Lk3bnOm8l1NT4LlnzuNy6ZUkmDn X-Google-Smtp-Source: ACcGV61f8CWT1V8Sf2oABpZkOKVI/PGwbjd3h/tBgG+YyK+TduxHU/6T+L3Qp5/QkMJdN95DIO5L9OtDZEhvOlvX+2o= X-Received: by 2002:ac8:67d7:: with SMTP id r23-v6mr5879753qtp.355.1539205382708; Wed, 10 Oct 2018 14:03:02 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> In-Reply-To: From: Nathaniel McCallum Date: Wed, 10 Oct 2018 17:02:51 -0400 Message-ID: To: jordan.ietf@gmail.com Cc: jose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 21:03:07 -0000 I can't speak for the WG. However, I think such is unnecessary. It is long standing custom, when working with JSON (with or without JOSE), to serialize without whitespace and with sorted keys. Every single JSON implementation I've ever come across gives you the ability to do this. On Wed, Oct 10, 2018 at 4:49 PM Bret Jordan wrote: > > Would this WG be open to working on a solution to sign JSON (not a byte s= tream) and define a canonical representation for said JSON? > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that c= an not be unscrambled is an egg." > > On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum w= rote: > > JWS signs a byte stream, not JSON. If you want to use a JWS to sign > JSON data it is your responsibility to ensure that both sides produce > an equivalent byte stream. > On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan wrote= : > > > Dear WG, > > I was reading through RFC 7515 to see if it would work for a project I am= working on. Basically the need to sign and resign a JSON object. However= , in RFC 7515 there does not seem to be any definition for serializing a ca= nonical form of JSON. This means that two organizations that serialize it d= ifferently would produce two different signatures. > > Super simple example > > { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80= =9D : =E2=80=9C1000 sq feet=E2=80=9D } > > > > Or > > { > =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, > =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D > } > > > > Or > > {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:= =E2=80=9C1000 sq feet=E2=80=9D} > > > > Or (tabs not spaces) > > { > =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, > =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D > } > > > All four of these JSON structures would produce a different signature as = defined by RFC 7515. What am I missing? > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that c= an not be unscrambled is an egg." > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > From nobody Wed Oct 10 14:19:15 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A03128CE4 for ; Wed, 10 Oct 2018 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mk52viRuLOH4 for ; Wed, 10 Oct 2018 14:19:12 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 20432128CB7 for ; Wed, 10 Oct 2018 14:19:12 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id m127-v6so2775426ywb.0 for ; Wed, 10 Oct 2018 14:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=bn45yjcbexCkd0EemANFspJTYxbL5ir4YCEcpXiGGVc=; b=h/GYOn9HK3Cq5CCGtEpsnlDkUYt4zf+a4tPcLyKSt2mLkCNa/Lnn3/oFqbnLUhaJJj MB5kzPNcsu8cxRhiTNgKjyvixNexcWy9AHoP0e95oIRKTg8guY+Zd1LACx/CrkEoBX0z yvwtC7hBDM994UKmOZj1G/XeVKGUYIuOz2ukvhma09R+0lqDyFHH8qTPH1PrRts1KB/P EreKETM3irDlaSV9Lle0lskrtHDGtDWaT7Kt1LzGDje+iKxGDjU+3IO/eZj6ZK/LE9f1 DQiPW8dAMWXIV9MYgviS20Ro8tLnuZBnboQKmiOlYrlVEsAOCZl7bRt8NstJiYjvlEr7 oZwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=bn45yjcbexCkd0EemANFspJTYxbL5ir4YCEcpXiGGVc=; b=q3jon6iskdTI6X54Ubx1JfCCoX5WUILn/wasiTSgEZj6qOV9MC9EF3X/jLfAtGUhVF x4F5Skd/8Y3MJCJSVkfnswV/P/50s0gD9eXMFfpjA6tipt36BuoRu4HHL02nMlHclbCn CWTrz413H5UaW2Z6tk51ffRIHRmnvSEFyssWNdWzAFE1BlfSnIct5NZlLqjshPRB+nWJ X5Ku+BPOSi7s50TcRfCrHTWUh70NgzepO9O3t9bpm3hDKG2kLO6iWxuWOcAwB4DseYe2 qibcBeY13P5Pu2bj7ZoksxSHZ4+D0Ay7aJ8/ZKKME+VlQA7bY6GOelmUx95IGYuzo9Xn cc8A== X-Gm-Message-State: ABuFfojAJL8KVNvxLGyMnpUUyxIt0ShHBLozowimFBXdW7oPFSdqlnNh FB+cbQAL/hPF0uNay0VK87Q= X-Google-Smtp-Source: ACcGV62lP03aQy4ZiXeSYBLhsyB367VsivXZsglLslVhnKPvrk77L0kJ+7nFU0gM98fkjasKOnuBlQ== X-Received: by 2002:a81:34d1:: with SMTP id b200-v6mr19706450ywa.291.1539206351381; Wed, 10 Oct 2018 14:19:11 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:11d5:fada:d8f3:ba5c? ([2605:a601:3260:266:11d5:fada:d8f3:ba5c]) by smtp.gmail.com with ESMTPSA id x130-v6sm606534ywb.27.2018.10.10.14.19.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 14:19:10 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_76D9CCB0-7F7E-4BDB-99C0-746E68C135D5" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 10 Oct 2018 15:18:32 -0600 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> To: Nathaniel McCallum , jose@ietf.org In-Reply-To: Message-Id: <0AE27224-DA55-49C7-ACE1-C11951A22836@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 21:19:14 -0000 --Apple-Mail=_76D9CCB0-7F7E-4BDB-99C0-746E68C135D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am also needing the ability to have signatures embedded in the JSON = and have multiple groups sign various individual or holistic parts of = the JSON structure. I found this page, and from a first read it looks like it gets me some = of the way to what I am needing.=20 https://cyberphone.github.io/doc/security/jcs.html = Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 10, 2018, at 3:02 PM, Nathaniel McCallum = wrote: >=20 > I can't speak for the WG. However, I think such is unnecessary. It is > long standing custom, when working with JSON (with or without JOSE), > to serialize without whitespace and with sorted keys. Every single > JSON implementation I've ever come across gives you the ability to do > this. > On Wed, Oct 10, 2018 at 4:49 PM Bret Jordan = wrote: >>=20 >> Would this WG be open to working on a solution to sign JSON (not a = byte stream) and define a canonical representation for said JSON? >>=20 >>=20 >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>=20 >> On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum = wrote: >>=20 >> JWS signs a byte stream, not JSON. If you want to use a JWS to sign >> JSON data it is your responsibility to ensure that both sides produce >> an equivalent byte stream. >> On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan = wrote: >>=20 >>=20 >> Dear WG, >>=20 >> I was reading through RFC 7515 to see if it would work for a project = I am working on. Basically the need to sign and resign a JSON object. = However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures. >>=20 >> Super simple example >>=20 >> { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80= =9D : =E2=80=9C1000 sq feet=E2=80=9D } >>=20 >>=20 >>=20 >> Or >>=20 >> { >> =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, >> =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D >> } >>=20 >>=20 >>=20 >> Or >>=20 >> {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:= =E2=80=9C1000 sq feet=E2=80=9D} >>=20 >>=20 >>=20 >> Or (tabs not spaces) >>=20 >> { >> =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, >> =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D >> } >>=20 >>=20 >> All four of these JSON structures would produce a different signature = as defined by RFC 7515. What am I missing? >>=20 >>=20 >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 --Apple-Mail=_76D9CCB0-7F7E-4BDB-99C0-746E68C135D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I am also needing the ability to have signatures embedded in = the JSON and have multiple groups sign various individual or holistic = parts of the JSON structure.

I found this page, and from a first = read it looks like it gets me some of the way to what I am = needing. 


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 3:02 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

I = can't speak for the WG. However, I think such is unnecessary. It is
long standing custom, when working with JSON (with or without = JOSE),
to serialize without whitespace and with sorted = keys. Every single
JSON implementation I've ever come = across gives you the ability to do
this.
On = Wed, Oct 10, 2018 at 4:49 PM Bret Jordan <jordan.ietf@gmail.com> wrote:

Would this WG be open to working = on a solution to sign JSON (not a byte stream) and define a canonical = representation for said JSON?


Thanks,
Bret
PGP Fingerprint: = 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."

On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

JWS signs a byte stream, not JSON. If you want to use a JWS = to sign
JSON data it is your responsibility to ensure that = both sides produce
an equivalent byte stream.
On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan <jordan.ietf@gmail.com> wrote:


Dear WG,

I was = reading through RFC 7515 to see if it would work for a project I am = working on.  Basically the need to sign and resign a JSON object. =  However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures.

Super simple example

{ =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, = =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D }



Or

{
=E2=80=9Ctype=E2=80=9D : = =E2=80=9Chouse=E2=80=9D,
=E2=80=9Csize=E2=80=9D : =E2=80=9C= 1000 sq feet=E2=80=9D
}



Or

{=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2= =80=9D:=E2=80=9C1000 sq feet=E2=80=9D}



Or (tabs not spaces)

{
=E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D= ,
=E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D}


All four of = these JSON structures would produce a different signature as defined by = RFC 7515. What am I missing?


Thanks,
Bret
PGP Fingerprint: = 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



= --Apple-Mail=_76D9CCB0-7F7E-4BDB-99C0-746E68C135D5-- From nobody Wed Oct 10 16:52:32 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3E7129C6B for ; Wed, 10 Oct 2018 16:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gpHVf7uEufKd for ; Wed, 10 Oct 2018 16:52:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886E21271FF for ; Wed, 10 Oct 2018 16:52:27 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 10 Oct 2018 16:47:42 -0700 From: Jim Schaad To: 'Bret Jordan' , 'Nathaniel McCallum' , References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> In-Reply-To: Date: Wed, 10 Oct 2018 16:52:18 -0700 Message-ID: <00a801d460f4$494c7060$dbe55120$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01D460B9.9CEED0E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNnP1/vuW81sZle9dbx86Tf75xU2AFuBXA/AqJ1qI6h0uV+AA== Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 23:52:32 -0000 ------=_NextPart_000_00A9_01D460B9.9CEED0E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The working group has closed and is not entertaining any new work. You = would need to create a proposal for a new working group (could have the = same name) to do this. However, trying to canonicalize JSON is = generally not considered to be doable without having some external = constraints added. Consider the problem with serializing = {=E2=80=9Cint=E2=80=9D: 3} which has a large number of possible ways to = encode the number 3. =20 From: jose On Behalf Of Bret Jordan Sent: Wednesday, October 10, 2018 1:49 PM To: Nathaniel McCallum ; jose@ietf.org Subject: Re: [jose] Canonical JSON form =20 Would this WG be open to working on a solution to sign JSON (not a byte = stream) and define a canonical representation for said JSON? =20 =20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum > wrote: =20 JWS signs a byte stream, not JSON. If you want to use a JWS to sign JSON data it is your responsibility to ensure that both sides produce an equivalent byte stream. On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan > wrote: Dear WG, I was reading through RFC 7515 to see if it would work for a project I = am working on. Basically the need to sign and resign a JSON object. = However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures. Super simple example { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, = =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D } Or { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D } Or {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:=E2= =80=9C1000 sq feet=E2=80=9D} Or (tabs not spaces) { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D } All four of these JSON structures would produce a different signature as = defined by RFC 7515. What am I missing? Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." _______________________________________________ jose mailing list jose@ietf.org =20 https://www.ietf.org/mailman/listinfo/jose =20 ------=_NextPart_000_00A9_01D460B9.9CEED0E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The = working group has closed and is not entertaining any new work.=C2=A0 You = would need to create a proposal for a new working group (could have the = same name) to do this.=C2=A0 However, trying to canonicalize JSON is = generally not considered to be doable without having some external = constraints added.=C2=A0 Consider the problem with serializing = {=E2=80=9Cint=E2=80=9D: 3} which has a large number of possible ways to = encode the number 3.

 

From: jose = <jose-bounces@ietf.org> On Behalf Of Bret = Jordan
Sent: Wednesday, October 10, 2018 1:49 PM
To: = Nathaniel McCallum <npmccallum@redhat.com>; = jose@ietf.org
Subject: Re: [jose] Canonical JSON = form

 

Would this = WG be open to working on a solution to sign JSON (not a byte stream) and = define a canonical representation for said = JSON?

 

 

Thanks,

Bret

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

= "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg."



On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum <npmccallum@redhat.com> = wrote:

 

JWS signs a byte stream, not JSON. If you want to use = a JWS to sign
JSON data it is your responsibility to ensure that both = sides produce
an equivalent byte stream.
On Wed, Oct 10, 2018 at = 3:04 PM Bret Jordan <jordan.ietf@gmail.com> = wrote:


Dear WG,

I was reading through RFC 7515 to = see if it would work for a project I am working on.  Basically the = need to sign and resign a JSON object.  However, in RFC 7515 there = does not seem to be any definition for serializing a canonical form of = JSON. This means that two organizations that serialize it differently = would produce two different signatures.

Super simple = example

{ =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, = =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D = }



Or

{
 =E2=80=9Ctype=E2=80=9D : = =E2=80=9Chouse=E2=80=9D,
 =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 = sq = feet=E2=80=9D
}



Or

{=E2=80=9Ctype=E2=80=9D:=E2=80= =9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:=E2=80=9C1000 sq = feet=E2=80=9D}



Or (tabs not = spaces)

{
=E2=80=9Ctype=E2=80=9D : = =E2=80=9Chouse=E2=80=9D,
=E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq = feet=E2=80=9D
}


All four of these JSON structures would = produce a different signature as defined by RFC 7515. What am I = missing?


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A = 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography = vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled = is an = egg."

_______________________________________________
jose= mailing list
jose@ietf.org
https://www.ietf.org/= mailman/listinfo/jose

 

------=_NextPart_000_00A9_01D460B9.9CEED0E0-- From nobody Wed Oct 10 16:53:25 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E1130DBE for ; Wed, 10 Oct 2018 16:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 pIZWZMrtxLDA for ; Wed, 10 Oct 2018 16:53:21 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835FD1271FF for ; Wed, 10 Oct 2018 16:53:20 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 10 Oct 2018 16:48:37 -0700 From: Jim Schaad To: 'Nathaniel McCallum' , CC: References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> In-Reply-To: Date: Wed, 10 Oct 2018 16:53:13 -0700 Message-ID: <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNnP1/vuW81sZle9dbx86Tf75xU2AFuBXA/AqJ1qI4BeDi93KHHJDlw Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 23:53:23 -0000 > -----Original Message----- > From: jose On Behalf Of Nathaniel McCallum > Sent: Wednesday, October 10, 2018 2:03 PM > To: jordan.ietf@gmail.com > Cc: jose@ietf.org > Subject: Re: [jose] Canonical JSON form >=20 > I can't speak for the WG. However, I think such is unnecessary. It is = long > standing custom, when working with JSON (with or without JOSE), to = serialize > without whitespace and with sorted keys. Every single JSON = implementation > I've ever come across gives you the ability to do this. Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere. Jim > On Wed, Oct 10, 2018 at 4:49 PM Bret Jordan = wrote: > > > > Would this WG be open to working on a solution to sign JSON (not a = byte > stream) and define a canonical representation for said JSON? > > > > > > Thanks, > > Bret > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can > not be unscrambled is an egg." > > > > On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum > wrote: > > > > JWS signs a byte stream, not JSON. If you want to use a JWS to sign > > JSON data it is your responsibility to ensure that both sides = produce > > an equivalent byte stream. > > On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan > wrote: > > > > > > Dear WG, > > > > I was reading through RFC 7515 to see if it would work for a project = I am > working on. Basically the need to sign and resign a JSON object. = However, in > RFC 7515 there does not seem to be any definition for serializing a = canonical > form of JSON. This means that two organizations that serialize it = differently > would produce two different signatures. > > > > Super simple example > > > > { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, = =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D } > > > > > > > > Or > > > > { > > =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, > > =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D > > } > > > > > > > > Or > > > > = {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D:=E2= =80=9C1000 sq feet=E2=80=9D} > > > > > > > > Or (tabs not spaces) > > > > { > > =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, > > =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D > > } > > > > > > All four of these JSON structures would produce a different = signature as > defined by RFC 7515. What am I missing? > > > > > > Thanks, > > Bret > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can > not be unscrambled is an egg." > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Wed Oct 10 16:59:53 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C4C129C6B for ; Wed, 10 Oct 2018 16:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 lBvl0o6PHvPX for ; Wed, 10 Oct 2018 16:59:49 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 1AD791271FF for ; Wed, 10 Oct 2018 16:59:49 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id w80-v6so2925121ybe.10 for ; Wed, 10 Oct 2018 16:59:49 -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=0O2OMPsvnl5kzuMxtX936cchMVH/ahFz3JZwxVggdRI=; b=ixMTT83lfKwIAcLm5MdxUW6XqJ82vxq7+cEiZErGvAfaqRqobHrJQzHvb1GC2NQtQM ItSihhSDbNTwlM5FMj7vwmd2APAEtVfs6nD+gMkiiykDkSSyV9s6a1noi+boKEBCzSjd HWLmDrjatKkyhVT6+s00wZW7uiPKVT9yuI57tHpP4EBCgWLt0ITi1degHGN57x751hY0 Jlfdf6jNLJc5OcXVOjCpIUJgtzXZI5JE+IGqbZh0eQZmU4jpS6dLNeLR6H3seun32j7W 1ByCU2d4TNtfHbbRWRSCCs92+Si1LxKo9BewRjDRvE9xKREJ+NQt8d0O3frAR+77ovqM nlTw== 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=0O2OMPsvnl5kzuMxtX936cchMVH/ahFz3JZwxVggdRI=; b=QZLtJqjlxZCcRz3IAmR7QR5LD84dIOQNP5WB4/ZL+lL29P0JjosLK8/z9LMJOuKe9b ht8klucmSt81CaU7K0UZPbrUfcwuZU+9AyTsRJatvd6dEOFlstroWZbKZk6lTI2zvlbL MQVoRFYI1gwEt6es/VqHDpxT1zZyu3wCsr0bG0n1UNzkR+jpOWA9m8BSo1V/OhtlT4dN 4Jrm68esrDImgrH+VDAfqFpTIHvgKBHQtTwza/bgRCqHuM86VElXIZjQ9Pem/+156mg3 kqPC2ZSJeBPmg9q0lgCZMhAymPlZJ5jZSB6DBUs7bGV511FquAxFNhypvWYbmxpw+EK6 5h0w== X-Gm-Message-State: ABuFfohlkfEnAGhPEKUuLWSucdIy9+de8INaHivzzzxfvCotsDMhVdbX EO+Emv/OI5q57tEjd9+unzA= X-Google-Smtp-Source: ACcGV60/OSzlYObIVzw4pct2YJbYIRkDueWCnxwhdFc8s34spOQYAxuvHAqutas60bD3SCAdlTkjxA== X-Received: by 2002:a5b:48e:: with SMTP id n14-v6mr19351007ybp.376.1539215988356; Wed, 10 Oct 2018 16:59:48 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:7534:8ac9:bb4c:ce9d? ([2605:a601:3260:266:7534:8ac9:bb4c:ce9d]) by smtp.gmail.com with ESMTPSA id b71-v6sm22014674ywa.48.2018.10.10.16.59.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 16:59:47 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_321073A2-D65A-417E-8C56-DD21CCDCE7E9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 10 Oct 2018 17:59:09 -0600 In-Reply-To: <00a801d460f4$494c7060$dbe55120$@augustcellars.com> Cc: Nathaniel McCallum To: Jim Schaad , jose@ietf.org References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00a801d460f4$494c7060$dbe55120$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 23:59:52 -0000 --Apple-Mail=_321073A2-D65A-417E-8C56-DD21CCDCE7E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How many of you would be interested in helping open a new working group = to work on this sort of thing? Maybe I am missing something, but there has to be a way of dealing with = this. Maybe just treat the entire JSON object has a string to be passed = in to a signing function ?=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 10, 2018, at 5:52 PM, Jim Schaad = wrote: >=20 > The working group has closed and is not entertaining any new work. = You would need to create a proposal for a new working group (could have = the same name) to do this. However, trying to canonicalize JSON is = generally not considered to be doable without having some external = constraints added. Consider the problem with serializing {=E2=80=9Cint=E2= =80=9D: 3} which has a large number of possible ways to encode the = number 3. > =20 > From: jose On Behalf Of Bret Jordan > Sent: Wednesday, October 10, 2018 1:49 PM > To: Nathaniel McCallum ; jose@ietf.org > Subject: Re: [jose] Canonical JSON form > =20 > Would this WG be open to working on a solution to sign JSON (not a = byte stream) and define a canonical representation for said JSON? > =20 > =20 > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 >=20 >> On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum = > wrote: >> =20 >> JWS signs a byte stream, not JSON. If you want to use a JWS to sign >> JSON data it is your responsibility to ensure that both sides produce >> an equivalent byte stream. >> On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan > wrote: >>=20 >>>=20 >>> Dear WG, >>>=20 >>> I was reading through RFC 7515 to see if it would work for a project = I am working on. Basically the need to sign and resign a JSON object. = However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures. >>>=20 >>> Super simple example >>>=20 >>> { =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, =E2=80=9Csize=E2=80= =9D : =E2=80=9C1000 sq feet=E2=80=9D } >>>=20 >>>=20 >>>=20 >>> Or >>>=20 >>> { >>> =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, >>> =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D >>> } >>>=20 >>>=20 >>>=20 >>> Or >>>=20 >>> {=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2=80=9D= :=E2=80=9C1000 sq feet=E2=80=9D} >>>=20 >>>=20 >>>=20 >>> Or (tabs not spaces) >>>=20 >>> { >>> =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, >>> =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D >>> } >>>=20 >>>=20 >>> All four of these JSON structures would produce a different = signature as defined by RFC 7515. What am I missing? >>>=20 >>>=20 >>> Thanks, >>> Bret >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose = --Apple-Mail=_321073A2-D65A-417E-8C56-DD21CCDCE7E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
How many of you would be interested in helping open a new = working group to work on this sort of thing?

Maybe I am missing something, but there = has to be a way of dealing with this.  Maybe just treat the entire = JSON object has a string to be passed in to a signing function = ? 

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 5:52 PM, Jim Schaad <ietf@augustcellars.com> wrote:

The = working group has closed and is not entertaining any new work.  You = would need to create a proposal for a new working group (could have the = same name) to do this.  However, trying to canonicalize JSON is = generally not considered to be doable without having some external = constraints added.  Consider the problem with serializing = {=E2=80=9Cint=E2=80=9D: 3} which has a large number of possible ways to = encode the number 3.
 
From: jose <jose-bounces@ietf.org> On Behalf = Of Bret Jordan
Sent: Wednesday, October 10, 2018 = 1:49 PM
To: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org
Subject: Re: [jose] Canonical JSON = form
 
Would this WG be open to working on a solution to sign JSON = (not a byte stream) and define a canonical representation for said = JSON?
 
 
Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."


On Oct 10, 2018, at 1:15 PM, Nathaniel = McCallum <npmccallum@redhat.com> wrote:
 
JWS signs a byte stream, not JSON. If = you want to use a JWS to sign
JSON data it is your = responsibility to ensure that both sides produce
an = equivalent byte stream.
On Wed, Oct 10, 2018 at 3:04 PM = Bret Jordan <jordan.ietf@gmail.com> wrote:


Dear WG,

I was = reading through RFC 7515 to see if it would work for a project I am = working on.  Basically the need to sign and resign a JSON object. =  However, in RFC 7515 there does not seem to be any definition for = serializing a canonical form of JSON. This means that two organizations = that serialize it differently would produce two different signatures.

Super simple example

{ =E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D, = =E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D }



Or

{
 =E2=80=9Ctype=E2=80=9D : = =E2=80=9Chouse=E2=80=9D,
 =E2=80=9Csize=E2=80=9D : = =E2=80=9C1000 sq feet=E2=80=9D
}



Or

{=E2=80=9Ctype=E2=80=9D:=E2=80=9Chouse=E2=80=9D,=E2=80=9Csize=E2= =80=9D:=E2=80=9C1000 sq feet=E2=80=9D}



Or (tabs not spaces)

{
=E2=80=9Ctype=E2=80=9D : =E2=80=9Chouse=E2=80=9D= ,
=E2=80=9Csize=E2=80=9D : =E2=80=9C1000 sq feet=E2=80=9D}


All four of = these JSON structures would produce a different signature as defined by = RFC 7515. What am I missing?


Thanks,
Bret
PGP Fingerprint: = 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_321073A2-D65A-417E-8C56-DD21CCDCE7E9-- From nobody Wed Oct 10 17:02:49 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1494F12D7F8 for ; Wed, 10 Oct 2018 17:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vwCbf4HHFrgc for ; Wed, 10 Oct 2018 17:02:45 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 181C1129C6B for ; Wed, 10 Oct 2018 17:02:45 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id y14-v6so2906390ywa.4 for ; Wed, 10 Oct 2018 17:02:45 -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=rNmwiqzH+YC+hYLbZATj1RAn/EHmaKpwnLMv1G3gUWU=; b=nn3rKCGUHOX0WZxZisDyj1tWe8bJui2qp+ly1m5yzeryAbsl9mStc5760e9KgoFMMf ty5aIxF+JK3y/98fS5DpaiIyfM2qFzh31uD2HCdvkXIPYYXwDYAmau4bm6vWTuxV67h6 XVs4Rq2hR8/QM/Aesioco0vrDfYERnzFWa8TlbCWx/jgTe4gcOWOewJd4vcpx+m7eUhO JDCfOS1xdMwYtqWvRaxPi5VkHAFD6ee85sTREioPDJ0G8gFMq9/8AtVPuCLDknxEu6lt OV0WJHoza8d76d5rw3UKGnozdwewCoBtVdeVgDkXVznCrlPlIwLuRYYlfLAThZd7cYfe MPuQ== 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=rNmwiqzH+YC+hYLbZATj1RAn/EHmaKpwnLMv1G3gUWU=; b=JJH9Qw5hc5tNnZQrOd1LuQyw9mw+ZGUVJKrhBhQQ+he/+xJddNNZseqNizsXEZu6q1 kYyMItyN5d8pIf4NfUifqTKStozbguO3ooRTasWYuqPcOKxJ8/OYJSdm6adAca1Ml5ew Tp7i9rJ8xTAH8HCiBUlqjUFRQqeG5YOoKvGYHpB0wazT96UwLLaVnkQVfgMYr2QHsoVV nbrH8KXWd/+LogbxRwb5ZTUIm/1TcB0nrLk1ZFgZnm6X/VVAfVlcetW4UR5WIyerZOqD LFDdGZ2IqP4XJa0jr/tTEPBgXJ/rFopI7iYubUpqan6gqPnP2+JG9dKjoWkPUGOKKeeF FMMQ== X-Gm-Message-State: ABuFfognHu4I6nw+4bj1gRSoQWYZ/RhoNXE0pdzONlZh/Cuacq1+0r+8 eYENMascjcqx3Th0vUb1q/w= X-Google-Smtp-Source: ACcGV62jbZKQ0cuJIFqlWeZHsnAE8Rh77J4xFEZm5PerTLLMlVQUhyeARbjOeK8hrnjMa0yvom4Wgg== X-Received: by 2002:a81:2156:: with SMTP id h83-v6mr19432579ywh.435.1539216164445; Wed, 10 Oct 2018 17:02:44 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:7534:8ac9:bb4c:ce9d? ([2605:a601:3260:266:7534:8ac9:bb4c:ce9d]) by smtp.gmail.com with ESMTPSA id u143-v6sm14919422ywc.28.2018.10.10.17.02.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 17:02:43 -0700 (PDT) From: Bret Jordan Message-Id: <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_50151581-DD98-4CF1-BEAA-62B5096FCFBE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 10 Oct 2018 18:02:05 -0600 In-Reply-To: <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> Cc: Nathaniel McCallum , jose@ietf.org To: Jim Schaad References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 00:02:47 -0000 --Apple-Mail=_50151581-DD98-4CF1-BEAA-62B5096FCFBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere. Preserving order is hard. Depending on your programming language you = might be deserializing the content in to a struct or you may be using a = map.=20 What I need is a way for individuals and organizations to be able to = pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." --Apple-Mail=_50151581-DD98-4CF1-BEAA-62B5096FCFBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Other = implementations say that you should preserver the order of the fields = you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere.

Preserving order is = hard.  Depending on your programming language you might be = deserializing the content in to a struct or you may be using a = map. 

What I need is a way for = individuals and organizations to be able to pass around and share JSON = data and collaboratively work on that JSON data and sign the parts that = they have done. 



Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."


= --Apple-Mail=_50151581-DD98-4CF1-BEAA-62B5096FCFBE-- From nobody Wed Oct 10 17:29:36 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D26130DD7 for ; Wed, 10 Oct 2018 17:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.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 K58AQ9_-HekV for ; Wed, 10 Oct 2018 17:29:32 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) (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 6C490130DD3 for ; Wed, 10 Oct 2018 17:29:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.54,366,1534773600"; d="scan'208,217";a="150092556" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 11 Oct 2018 11:29:28 +1100 Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcavi.tcif.telstra.com.au with ESMTP; 11 Oct 2018 11:29:27 +1100 Received: from wsapp5870.srv.dir.telstra.com (10.75.139.12) by WSMSG3753.srv.dir.telstra.com (172.49.40.174) with Microsoft SMTP Server (TLS) id 8.3.485.1; Thu, 11 Oct 2018 11:29:26 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5870.srv.dir.telstra.com (10.75.139.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 11:29:25 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Oct 2018 11:29:25 +1100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pCnWdgNFGrbf2SSxeu9/jcHJUZ1zXnsatQXu/qtR9pc=; b=L3SBi0lLRE26j4xZtHls3VUgPgrL0k1mLv1z/mbuK0zDthgsvqJnk9XeNyGxMCcBGAYwMI7yn0/x7JwQ1Cc+UdZuKpBzr0PMnENSX2GFmULe4oomY3wq5nEqugrfQuwly5aLwJwtYc1D9ubpiQkWPnwaoN44k3IfJqUIeett1x4= Received: from MEAPR01MB3542.ausprd01.prod.outlook.com (52.134.216.9) by MEAPR01MB3783.ausprd01.prod.outlook.com (52.134.217.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.25; Thu, 11 Oct 2018 00:29:21 +0000 Received: from MEAPR01MB3542.ausprd01.prod.outlook.com ([fe80::4031:99ca:970e:721e]) by MEAPR01MB3542.ausprd01.prod.outlook.com ([fe80::4031:99ca:970e:721e%2]) with mapi id 15.20.1207.029; Thu, 11 Oct 2018 00:29:21 +0000 From: "Manger, James" To: Bret Jordan , "jose@ietf.org" Thread-Topic: [jose] Canonical JSON form Thread-Index: AQHUYMwqAYQkrLnvnkK7c9D6N5x9MKUY2XsAgAAaOgCAAAPogIAAL5qAgAACeoCAAALkcA== Date: Thu, 11 Oct 2018 00:29:21 +0000 Message-ID: References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> In-Reply-To: <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.500.19 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.185.253] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MEAPR01MB3783; 6:wqtdR58jnplPCvEtDfY5w/1Y4ywYs+KRsZlaxDX5MQ/Hajy1esxO1xhcfK5bqIn7nmZVFcgAnxQTJ4fW8xcAGcoJcSjN4edEhW8xy3P3rS/sYsw+Q9LsbT3rpNcRba20O1gD3JBLOwoePPnY7VXhBwqiAlKvZTE6HAZYRGXPABmrgKcmDSVNDfavSLohl5XESjWjk2rowU3LGtfQbj2m1OmykqdpLchmHUVupv3Gb04l+H2kOYSjpGjGfbiTms13/0HQ22LYE/lsBcmn5b7zuqIED876Q1KO0l4W7YK9dnuYuu6nhKKuEVsVvF0nV9Jt9IfClkzLhyBgvFqEKIJZqedzbpyz0pbf9md7xMXGodH1xSY3ponKkoYcDjp11mzYcYjxkExY+B4rBJlZiJnI27vDq0S3VOsPbCqdD99O4G7fsV00XyayLePoib80g5k2IcwsSPzcn1JSMZCcZWT8HA==; 5:1oOcxmyT0DUTVoABbRkIXaC5/Nj3/kzpz66BbGW5UHhbqj9Q9A5ZK9wucIeBAb75rs2gYPAWv8IxGVIrrw6XObdBz2kb/fkO++WlOQ4nRPFHPEhW0MOBFiQb2Q8uw/Mgh+CXm1UZ0BHnSkzIYskSLg/vGLwA3tR1oeniO9kvcrA=; 7:UQhtVIBP3tslxFKD+dDfJom5jh0vtMQHufdIfGE5Oc2N9zM/wv8iZHDD0RTqEttZItyjoCn/KLZAGB4r8UpNX4C0nFnIhqtoEMCRKtYe3nz5oprxUhjM+5hd2OTAH5QEM8RnOZFbQyboOVcZITsmQneoLkDbw7RmO4smx+wZu0LR4EWZC/QVnclcru0H+VR8VqlGijPF66oKxsCBVK9RzVk/72J0ZJgk67AInaA+s/FGfG5UqBz0EgV1j/I+gFxD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7e40b1b6-e8f3-4c64-9f2d-08d62f1096bb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MEAPR01MB3783; x-ms-traffictypediagnostic: MEAPR01MB3783: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051); SRVR:MEAPR01MB3783; BCL:0; PCL:0; RULEID:; SRVR:MEAPR01MB3783; x-forefront-prvs: 08220FA8D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(396003)(376002)(346002)(189003)(199004)(55016002)(39060400002)(6246003)(53936002)(236005)(71190400001)(9686003)(606006)(71200400001)(478600001)(25786009)(72206003)(54896002)(68736007)(3846002)(5250100002)(14454004)(66574009)(2501003)(966005)(86362001)(6116002)(790700001)(2900100001)(5660300001)(93886005)(7736002)(6506007)(26005)(14444005)(99286004)(256004)(6306002)(316002)(486006)(446003)(11346002)(33656002)(66066001)(53546011)(476003)(229853002)(106356001)(102836004)(81156014)(97736004)(6436002)(74316002)(105586002)(8676002)(2906002)(186003)(8936002)(7696005)(76176011)(81166006)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:MEAPR01MB3783; H:MEAPR01MB3542.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: khKhyI3P2B3b3urHMRHfGO0gDKZ/ohEdCOUUrh3nXjktQ3rMVEYk43gY/5MZRAQIfPP/ht90KV44UjUOLP+bCtB0REtbw1CrH3QSO40OVBYS8QOT1LfMrkhsLnPsHcJTm/ViJBtx3qjcB4V8x3MORSx/GXwfP27IHUcnagRPZ/uiPP2I07ysjbWvjbFmFygsGVNhLLAEnwEvJDrjmJot6ISLkTWtBF0DEljOyoA1Wn2I1NPAuo7j+iN172Z3Lv79AOEnnfAvPJddyjtI0ilyozDJFOMFRK4LlLXlEmsfKH6LFT1/XK7KgEXeVMPiaWvAGg6og7wICzPlgVoalo8rtAwo0sO2WqY5xBTCERyot7Y= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MEAPR01MB35428606C09BF315DE04CC79E5E10MEAPR01MB3542ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7e40b1b6-e8f3-4c64-9f2d-08d62f1096bb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 00:29:21.2983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB3783 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 00:29:35 -0000 --_000_MEAPR01MB35428606C09BF315DE04CC79E5E10MEAPR01MB3542ausp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme is a decent attempt at JSON canonicalization (and an appendix lists a few o= ther attempts). This one sorts object members based on their UTF-16 encoding (without escap= es), and assumes double precision floats is the model for numbers. -- James Manger From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Bret Jordan Sent: Thursday, 11 October 2018 11:02 AM To: Jim Schaad Cc: Nathaniel McCallum ; jose@ietf.org Subject: Re: [jose] Canonical JSON form Other implementations say that you should preserver the order of the fields= you read when serialized which is part of JSON for the browser implementat= ions but not necessarily elsewhere. Preserving order is hard. Depending on your programming language you might= be deserializing the content in to a struct or you may be using a map. What I need is a way for individuals and organizations to be able to pass a= round and share JSON data and collaboratively work on that JSON data and si= gn the parts that they have done. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can= not be unscrambled is an egg." --_000_MEAPR01MB35428606C09BF315DE04CC79E5E10MEAPR01MB3542ausp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

h= ttps://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme<= o:p>

is a decen= t attempt at JSON canonicalization (and an appendix lists a few other attem= pts).

This one s= orts object members based on their UTF-16 encoding (without escapes), and a= ssumes double precision floats is the model for numbers.

 = ;

--

James Manger

 = ;

From: = jose [mailto:jose-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org<= br> Subject: Re: [jose] Canonical JSON form

 


Other implementations say that you should preserver the order of the fields= you read when serialized which is part of JSON for the browser implementat= ions but not necessarily elsewhere.

 

Preserving order is hard.  Depending on your pr= ogramming language you might be deserializing the content in to a struct or= you may be using a map. 

 

What I need is a way for individuals and organizatio= ns to be able to pass around and share JSON data and collaboratively work o= n that JSON data and sign the parts that they have done. 

 

 

 

Than= ks,

Bret=

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

"Without cryptography vihv vivc c= e xhrnrw, however, the only thing that can not be unscrambled is an egg.&qu= ot;

 

 

--_000_MEAPR01MB35428606C09BF315DE04CC79E5E10MEAPR01MB3542ausp_-- From nobody Wed Oct 10 18:42:49 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFCA130DFB for ; Wed, 10 Oct 2018 18:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 OboAZrr9G4Vp for ; Wed, 10 Oct 2018 18:42:45 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 542F5130DF3 for ; Wed, 10 Oct 2018 18:42:44 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:f955:f038:a7d9:69e9] (unknown [IPv6:2601:282:202:b210:f955:f038:a7d9:69e9]) by alkaline-solutions.com (Postfix) with ESMTPSA id 230F53167C; Thu, 11 Oct 2018 01:42:44 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2708F5CF-41B5-462A-82D4-F6215B5D9E77" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.42\)) Date: Wed, 10 Oct 2018 19:42:43 -0600 In-Reply-To: Cc: Bret Jordan , "jose@ietf.org" To: "Manger, James" References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> X-Mailer: Apple Mail (2.3445.100.42) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 01:42:48 -0000 --Apple-Mail=_2708F5CF-41B5-462A-82D4-F6215B5D9E77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Even this I-D presents some interesting potential compatibility issues = when round-tripping from canonical JSON to an internal representation = and back, such as an implementation normalizing external text, or = storing numbers in numerical types other than double. The bigger issue in the past has not been the body of work defining a = canonicalization scheme, but that people did that in the past for XML = signatures. It became a huge interoperability issue due not just to the = complexity of the canonicalization scheme[s], but to the difficulty in = detecting and dealing with modifications to the canonical form. This = also gracefully went down the slipper slope to signing portions and even = specific features of a document, and tooling needing to accommodate = preserving canonical form when e.g. signed documents were placed inside = other documents. -DW > On Oct 10, 2018, at 6:29 PM, Manger, James = wrote: >=20 > = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme = --Apple-Mail=_2708F5CF-41B5-462A-82D4-F6215B5D9E77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Even = this I-D presents some interesting potential compatibility issues when = round-tripping from canonical JSON to an internal representation and = back, such as an implementation normalizing external text, or storing = numbers in numerical types other than double.

The bigger issue in the past has not = been the body of work defining a canonicalization scheme, but that = people did that in the past for XML signatures. It became a huge = interoperability issue due not just to the complexity of the = canonicalization scheme[s], but to the difficulty in detecting and = dealing with modifications to the canonical form. This also gracefully = went down the slipper slope to signing portions and even specific = features of a document, and tooling needing to accommodate preserving = canonical form when e.g. signed documents were placed inside other = documents.

-DW
= --Apple-Mail=_2708F5CF-41B5-462A-82D4-F6215B5D9E77-- From nobody Wed Oct 10 18:48:19 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C190130DF9 for ; Wed, 10 Oct 2018 18:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VwPDUIiivUYD for ; Wed, 10 Oct 2018 18:48:15 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 A44AA130DF6 for ; Wed, 10 Oct 2018 18:48:15 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id w67so7347137ota.7 for ; Wed, 10 Oct 2018 18:48:15 -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=kDTy6VXx4ezu0XtHP9tk2lLzQZ2mSdwmnBg7De3r8+E=; b=QAHyUBcKRrv1qJ26vi2sQsbSvyucGLUuTDP8twQiQ2OzSDftaL7QWWYc3VxQMWgwXr 9fqim0HVAYiQlL8LbVXlWk5bBojC0Xi0LUx2KXfkN9cWzM5CtT0/6y7MYQZ1wNdcEP2g 0utxBpKqmNri7JYfLgiQxGRGMSGOTIlmidU+OTzh4oGvTacOLGIivybAFeQFBCyG085h H7JZpmuM0THqvJQ44MlefaGIcchp5OD2AbplQ5pcvfGEJYzHBUhXC4Brcg86Gfmx/Kto WB/AkZCgMNL7DCR/xvzlgEcCjM5L2yoYz2AGBDi60R3be63z0YpJhxpDCMZiLOuASZhS 61Jg== 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=kDTy6VXx4ezu0XtHP9tk2lLzQZ2mSdwmnBg7De3r8+E=; b=KB6nMJSvdwQK+gyTkArzqj1lAnPoAktNXx1NrB2D2Uf7U7KocbAEjtnbxEsSFshDOp Q7bZCvF5o+UREGJbA8+oc2++mg1WrR+RGiO3p4IvtbyJdyYWdnQcAMDCiMCxRp7Ck5V3 ianJS9EVaBlfDkEuPtXQsk8BsYrmvFa4eVOe0ovkSUhKj93eqMLawryvn31Z1WJdmgNx hHskFuRaTGB7/FU01SDeyP/ZgHTKRS3DtE91hgTjSiVnrjK1cldnG9etF95DDxEgAS/C 59bbkqdUR8bwo0jMCXbtkdnK2N9Aaw66IpjT2yHOtFaP4fcqGcoLw3mNufhOx98CYNFN jHpA== X-Gm-Message-State: ABuFfoiiBsI2cakcdtWecjmHycIveBbGHI+B1FTgDLqjUgOLajObLChS pqp0vbzh673e9Xcsv3G1b68nqxEDiSB2KPJhUFU= X-Google-Smtp-Source: ACcGV61ZHByGmlDqVJLH5pM0HryFhQTmMYNlnRaOxV0ugIvvIVp6AEMnPZA5kbofAzIIe16M5Mc99tlncuZd8zFbawQ= X-Received: by 2002:a9d:61c3:: with SMTP id h3mr11831336otk.361.1539222495035; Wed, 10 Oct 2018 18:48:15 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> In-Reply-To: From: Kathleen Moriarty Date: Wed, 10 Oct 2018 21:47:38 -0400 Message-ID: To: "Manger, James" Cc: Bret Jordan , jose@ietf.org Content-Type: multipart/alternative; boundary="0000000000000c11120577ea2a69" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 01:48:18 -0000 --0000000000000c11120577ea2a69 Content-Type: text/plain; charset="UTF-8" Bret, You could define it within a draft in a different working group other than JOSE and ask for reviewers from JOSE to review and comment to catch problems. Although already described above, there are issues with this and JSON, which is why the WG didn't want to do canonicalization. I'm assuming you want to do basically what was done for RID in XML using JSON. You may want to look at the set of possibilities to replicate as they are all likely needed with what you are trying to do or just as part of your gap analysis. https://tools.ietf.org/html/rfc6545#section-9.1 Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop authentication too. To David's point in the message that follows this (came in while typing), RID signed portions of the message to enable interoperability and you are likely to need to do very similar things that are described in RID related to the policy work I had previously mentioned for your gap analysis as being similar functionality. If you haven't looked at that part of the document, I think it will be helpful. Best regards, Kathleen On Wed, Oct 10, 2018 at 8:29 PM Manger, James < James.H.Manger@team.telstra.com> wrote: > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme > > is a decent attempt at JSON canonicalization (and an appendix lists a few > other attempts). > > This one sorts object members based on their UTF-16 encoding (without > escapes), and assumes double precision floats is the model for numbers. > > > > -- > > James Manger > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Bret Jordan > *Sent:* Thursday, 11 October 2018 11:02 AM > *To:* Jim Schaad > *Cc:* Nathaniel McCallum ; jose@ietf.org > *Subject:* Re: [jose] Canonical JSON form > > > > > Other implementations say that you should preserver the order of the > fields you read when serialized which is part of JSON for the browser > implementations but not necessarily elsewhere. > > > > Preserving order is hard. Depending on your programming language you > might be deserializing the content in to a struct or you may be using a > map. > > > > What I need is a way for individuals and organizations to be able to pass > around and share JSON data and collaboratively work on that JSON data and > sign the parts that they have done. > > > > > > > > Thanks, > > Bret > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Best regards, Kathleen --0000000000000c11120577ea2a69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bret,

You could define= it within a draft in a different working group other than JOSE and ask for= reviewers from JOSE to review and comment to catch problems.=C2=A0 Althoug= h already described above, there are issues with this and JSON, which is wh= y the WG didn't want to do canonicalization.

I= 'm assuming you want to do basically what was done for RID in XML using= JSON.=C2=A0 You may want to look at the set of possibilities to replicate = as they are all likely needed with what you are trying to do or just as par= t of your gap analysis.

Also look at 9.3.1 and 9.3.2 as you're likely = to also need multi-hop authentication too.

To Davi= d's point in the message that follows this (came in while typing), RID = signed portions of the message to enable interoperability and you are likel= y to need to do very similar things that are described in RID related to th= e policy work I had previously mentioned for your gap analysis as being sim= ilar functionality.=C2=A0 If you haven't looked at that part of the doc= ument, I think it will be helpful.

Best regards,
Kathleen



On Wed, Oct 10, 2018 at 8:29 PM Mange= r, James <James.H.Man= ger@team.telstra.com> wrote:

https://to= ols.ietf.org/html/draft-rundgren-json-canonicalization-scheme=

is a decent attempt at JSON canonical= ization (and an appendix lists a few other attempts).<= /p>

This one sorts object members based o= n their UTF-16 encoding (without escapes), and assumes double precision flo= ats is the model for numbers.

=C2=A0

--

James Manger

=C2=A0

From: = jose [mailto:jos= e-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org
Subject: Re: [jose] Canonical JSON form

=C2=A0


Other implementations say that you should preserver the order of the fields= you read when serialized which is part of JSON for the browser implementat= ions but not necessarily elsewhere.

=C2=A0

Preserving order is hard.=C2=A0 Depending on your pr= ogramming language you might be deserializing the content in to a struct or= you may be using a map.=C2=A0

=C2=A0

What I need is a way for individuals and organizatio= ns to be able to pass around and share JSON data and collaboratively work o= n that JSON data and sign the parts that they have done.=C2=A0

=C2=A0

=C2=A0

=C2=A0

Thanks,=

Bret

PGP Fingerprint:=C2=A063B4 FC53 680A 6= B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 0050=

"Without cryptography vihv vivc c= e xhrnrw, however, the only thing that can not be unscrambled is an egg.&qu= ot;

=C2=A0

=C2=A0

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


--

Best regards,
Kathleen
--0000000000000c11120577ea2a69-- From nobody Wed Oct 10 22:33:49 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96022130E26 for ; Wed, 10 Oct 2018 22:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1ct8u6N6Yq7 for ; Wed, 10 Oct 2018 22:33:46 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 A4FC2130E21 for ; Wed, 10 Oct 2018 22:33:46 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id a13-v6so8123132wrt.5 for ; Wed, 10 Oct 2018 22:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JzEhU3jIg/Wa+AUvroJDr/PdWdA/Ot4Nn15Fp3KcJg0=; b=AkEKQFVheaUsAYzmxyDqC5Cf/Zlpea3aT+/Cq84sBcmntjCHDE7+B5uhw7slouHo2T MP7OfFSCSsRtWUlD+ZBicHgomeKar3D/6AmStrW7YVNUyb8YyOjv+wUfIdFfwwzcFPpX hguldo3hLb0L/an/4mRRs5csdNALsvR+jr5vk= 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=JzEhU3jIg/Wa+AUvroJDr/PdWdA/Ot4Nn15Fp3KcJg0=; b=Xf4k7wcBU5V/FUr+7PPC3ggDoqyUKv8lLrGi2GgR2BwdKGYGnnFoCPmVoQxtx4tBtm prAAY8RLM6SHEmAt/Cviy1+rTbECDtt1bOocWFncMUGxaAdu/wWxndOHeEVxsBgP34fy w9EW38urAhKR671iaD4nBQhfb1pXRAbIKHycOd0wzA0HqTchezqq9IX5/qZ12P/lzXdt BdtEnx//Rs9mNufSygaMUKVqmQmLqPqiMVYGIGAISRm83qLcuowGIoggknSURLtaXYIi 4AGtBvOR72DgZN1QfxpF2/587Poym9MovZM4rfHX/g2AoBFNKn0oGzSG1AyM/1rbt9bK H6Zw== X-Gm-Message-State: ABuFfoiCM6GBzmqyhsJTClwXFt8V9axio4OHde9zgBFG7Wp+0BlbykXy pivEA8zjJkTTZRwGMnQX5QmJY8fDRvf6WHrh5kabWwabvXn1/Z20L/GqXpQSmTN1tF/3buhsJ7y aMdGNWqOIj1mdxVSRVdj0/eKcH3Izt6rcbtWQD44Z+XMbZF25PTN6laNDdL55qkGq X-Google-Smtp-Source: ACcGV62iKd5wvbOGrrcounSDCMqGuSJVPAHYEmnf+NgBy3DxPvIdfxSphIk64p69o7iaCuhM6/IPyw== X-Received: by 2002:adf:f5c6:: with SMTP id k6-v6mr109482wrp.59.1539236024691; Wed, 10 Oct 2018 22:33:44 -0700 (PDT) Received: from [192.168.1.65] (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id t24-v6sm41976488wra.5.2018.10.10.22.33.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 22:33:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16A366) In-Reply-To: <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> Date: Thu, 11 Oct 2018 06:33:42 +0100 Cc: Jim Schaad , Nathaniel McCallum , jose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> To: Bret Jordan Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 05:33:49 -0000 > On 11 Oct 2018, at 01:02, Bret Jordan wrote: >=20 >>=20 >> Other implementations say that you should preserver the order of the fiel= ds you read when serialized which is part of JSON for the browser implementa= tions but not necessarily elsewhere. >=20 > Preserving order is hard. Depending on your programming language you migh= t be deserializing the content in to a struct or you may be using a map.=20 >=20 > What I need is a way for individuals and organizations to be able to pass a= round and share JSON data and collaboratively work on that JSON data and sig= n the parts that they have done.=20 Have you considered Git with PGP-signed commits? It solves this use-case ext= remely well. =E2=80=94 Neil= From nobody Wed Oct 10 23:44:20 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF48130E3E for ; Wed, 10 Oct 2018 23:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kEwxoYkWe9SS for ; Wed, 10 Oct 2018 23:44:16 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 F0850130E3B for ; Wed, 10 Oct 2018 23:44:15 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id 23-v6so3684067pgc.8 for ; Wed, 10 Oct 2018 23:44:15 -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=/6hS6yjSfKkysiqu7NcWm1pdHAYXTFyCb9NMt2g9SvM=; b=R3atSymlGlKZSzRsfRLXxsjc5nWrQEejre/U3kNRCTDGVroLmUJZtXD2kGlLBhtBVL bVZnXszJJIw9QMidqzcLxTKHTCqgj0+QAwV/X2MsM3qDi0iQUqiTp0yZG4KRhyK9ol57 bY59K5CjibvKcoFIsR56BHTs+2O9T4I7VLvsUzxy3U5XtEkpH7eI0A8MqOGAPfi8mxiC IpcF3D21Qc0md9W9F1ZX4+FfunjCc5DzLMi424Lmpi5HQ86YOZl9vSttFGVt4EYvrIdJ tY9j0hL+cZmg+P1Sya3hHjDy4IDG828rUspGRHmgtYL9RLvXgAvjozaKgF2XTBPussy+ YZ+A== 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=/6hS6yjSfKkysiqu7NcWm1pdHAYXTFyCb9NMt2g9SvM=; b=nTN4x/+muCj4wchHrxRGNQy+6JV3fnNo6mLoZ3lHDML0nUKkK59fc5jb7e4A2QgrUB Pfudam2V5uA8KSVTQHdAscD61j8vsG4F6JaKGRB3fR+eO4EmoAMI1x0I+IcZipegPe2l bdAzlUL37lllMj68y2KMauw/WjIKC2fp4poybTrFK1lEmOFgYQTLKDI8ddWuZ6gQH3Cq y3CECRbdxkYZOrPNQFhEI4DobfVyvuMiIOp9m3sfj46PLCnF415PHmnn047tJ4Nsv9+f 2ANf1bbtCevz127C4485utJ+jatvTNnJ0Jo2Z25DZhE3/FyI/tzMkihAOgeBOFxbwfdd u1Ug== X-Gm-Message-State: ABuFfoh2ydxMmVPyAmmw15Hm6eGSTJR7r15ORDxZVXIO7VXzkrYMD6Hr ILyemG6/OGpRFh3RQYMqc2PW/3kxZCpiAR5AUunbmA== X-Google-Smtp-Source: ACcGV60Jk6uvVBJnBLkSvFdB+IWwTATvTxMDmepnOngMsO8R/LqzEW1Twn5Nk9pfaJWmG/xEQgb7BgihJUuH8YJq1co= X-Received: by 2002:a65:648f:: with SMTP id e15-v6mr311252pgv.250.1539240254798; Wed, 10 Oct 2018 23:44:14 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> In-Reply-To: <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> From: Samuel Erdtman Date: Thu, 11 Oct 2018 08:44:04 +0200 Message-ID: To: neil.madden@forgerock.com Cc: jordan.ietf@gmail.com, Jim Schaad , npmccallum@redhat.com, jose@ietf.org Content-Type: multipart/alternative; boundary="0000000000009c95840577ee4cf6" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:44:18 -0000 --0000000000009c95840577ee4cf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I for one think this is interesting. I have published two implementations of the draft James mentions, draft-rundgren-json-canonicalization-scheme , = ( Java and JavaScript ) and I know Anders (the author of the draft) has implementations in .NET and Python too (all working well together). The I have my self been part in writing a draft that uses this canonicalization mechanism to create signed cleartext JSON ( draft-erdtman-jose-cleartext-jws ). I have ported a JavaScript JOSE implementation to this new schema without any issues and Anders has at least a Java implementation. Finally there was a resent conversation about this subject on the OAuth mailing-list recently. Best regards //Samuel On Thu, Oct 11, 2018 at 7:33 AM Neil Madden wrote: > > > On 11 Oct 2018, at 01:02, Bret Jordan wrote: > > > >> > >> Other implementations say that you should preserver the order of the > fields you read when serialized which is part of JSON for the browser > implementations but not necessarily elsewhere. > > > > Preserving order is hard. Depending on your programming language you > might be deserializing the content in to a struct or you may be using a > map. > > > > What I need is a way for individuals and organizations to be able to > pass around and share JSON data and collaboratively work on that JSON dat= a > and sign the parts that they have done. > > Have you considered Git with PGP-signed commits? It solves this use-case > extremely well. > > =E2=80=94 Neil > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --0000000000009c95840577ee4cf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I for one think this is interesting.=

I have published two implementations of the draft= James mentions, draft-rundgren-json-canonicalization-scheme, = (Java and JavaScript) and I= know Anders (the author of the draft) has implementations in .NET and Pyth= on too (all working well together).

The I have= my self been part in writing a draft that uses this canonicalization mecha= nism to create signed cleartext JSON (draft-erdtman-jose= -cleartext-jws). I have ported a JavaScript JOSE implementation to this= new schema without any issues and Anders has at least a Java implementatio= n.

Finally there was a resent conversation abo= ut this subject on the OAuth mailing-list recently.
=
Best regards
//Samuel


On Thu, Oct 11, 201= 8 at 7:33 AM Neil Madden <neil.madden@forgerock.com> wrote:

> On 11 Oct 2018, at 01:02, Bret Jordan <jordan.ietf@gmail.com> wrote:
>
>>
>> Other implementations say that you should preserver the order of t= he fields you read when serialized which is part of JSON for the browser im= plementations but not necessarily elsewhere.
>
> Preserving order is hard.=C2=A0 Depending on your programming language= you might be deserializing the content in to a struct or you may be using = a map.
>
> What I need is a way for individuals and organizations to be able to p= ass around and share JSON data and collaboratively work on that JSON data a= nd sign the parts that they have done.

Have you considered Git with PGP-signed commits? It solves this use-case ex= tremely well.

=E2=80=94 Neil
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--0000000000009c95840577ee4cf6-- From nobody Thu Oct 11 07:33:06 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01F9130E97 for ; Thu, 11 Oct 2018 07:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kFZA8DC9cuBX for ; Thu, 11 Oct 2018 07:33:01 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 360C3130E95 for ; Thu, 11 Oct 2018 07:33:01 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id a197-v6so3656162ywh.9 for ; Thu, 11 Oct 2018 07:33:01 -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=jTbP0x6+Bmec76wqQ1WcBwb/8b9lSBKqQrbSIn4ItHg=; b=A4ZFGVNN6zUl//EZJbtdxFPJ4Bi6TmEVRwIjAq9+d/Z/SbvdN0hXeCz6m597iwi0R8 IV6eaFBwMBhe2Jl3J+Qnci7eiqeQaW0Ke7+X1ShgyMAGgeDqfYkJkO9gysd/rbsXhMxA KHIvwC5z+nPDRN990hBvfvezk76tohdn7EPsJVk7Z8kY6AjEOKo6rn89eR22lESfodN8 RSnu+1bY7XodLF/reWVgvjFEylLFhuySfADj7XTcQEw0TPW1+DqPPym9kr+Lfn8eeLop KERPe4tgg0ueB65MZMpiiQvhldzRS3mqgJcwsambztO7OPHHK7C3UV8tnEdG/eCUAysk YM6g== 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=jTbP0x6+Bmec76wqQ1WcBwb/8b9lSBKqQrbSIn4ItHg=; b=ErN3tKg3KJQiVWfG4ssg80ULSbfRWSvRl8dtdhy5pYofRQ2RLg9pxxoOGUM/RANLyj NvkbPXeLdVgl0QBUZjLHU+qS6iEZUxMs2ycTJQQtKjtDSL43OFXtiWiJZJ6YH3dQlaEb 171gQypvx+W13Qpl14HIIN4b7pIhOqOJBkW3I1lz48tWX4um4R8xGEdqbk06DmGg2gXt vtsEtGCMuQSm3d2516mjyDZM0KOHNAb2lxbN6Pyo9qd4j0QlA/Hs4g29GRV0r2dRWDpY XPAN+J2R5HZQ6Z6rC1Eg/Y8hmQfgbADkADdynfVrP3kdAh0LrDLjbysUur/k3hZZqmSI TJdQ== X-Gm-Message-State: ABuFfogUJVcRTIlDe3kWm0js4W58IHr2DYyjtp4yBVQBUReRmLFI0PCg FAEbHYbc4nmfCql31wzp0w1OMb8F X-Google-Smtp-Source: ACcGV60yWqOSoiLkFrKmg37oQp2taILvlkisDjT7Lyh1IeSjGhDGwAGLm5i2bvL2CKSTBn6rAgY+BA== X-Received: by 2002:a0d:df8d:: with SMTP id i135-v6mr953566ywe.349.1539268380496; Thu, 11 Oct 2018 07:33:00 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:7534:8ac9:bb4c:ce9d? ([2605:a601:3260:266:7534:8ac9:bb4c:ce9d]) by smtp.gmail.com with ESMTPSA id s3-v6sm11094028ywc.72.2018.10.11.07.32.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 07:32:59 -0700 (PDT) From: Bret Jordan Message-Id: <797C369C-519D-48CE-B544-C68F156FCA33@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CEE600C9-87E0-417B-AF6C-06E0D7407492" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 08:32:20 -0600 In-Reply-To: Cc: "Manger, James" , jose@ietf.org To: Kathleen Moriarty References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 14:33:05 -0000 --Apple-Mail=_CEE600C9-87E0-417B-AF6C-06E0D7407492 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Awesome advise. Thanks. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty = wrote: >=20 > Bret, >=20 > You could define it within a draft in a different working group other = than JOSE and ask for reviewers from JOSE to review and comment to catch = problems. Although already described above, there are issues with this = and JSON, which is why the WG didn't want to do canonicalization. >=20 > I'm assuming you want to do basically what was done for RID in XML = using JSON. You may want to look at the set of possibilities to = replicate as they are all likely needed with what you are trying to do = or just as part of your gap analysis. >=20 > https://tools.ietf.org/html/rfc6545#section-9.1 = > Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop = authentication too. >=20 > To David's point in the message that follows this (came in while = typing), RID signed portions of the message to enable interoperability = and you are likely to need to do very similar things that are described = in RID related to the policy work I had previously mentioned for your = gap analysis as being similar functionality. If you haven't looked at = that part of the document, I think it will be helpful. >=20 > Best regards, > Kathleen >=20 >=20 >=20 > On Wed, Oct 10, 2018 at 8:29 PM Manger, James = > wrote: > = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme = > is a decent attempt at JSON canonicalization (and an appendix lists a = few other attempts). >=20 > This one sorts object members based on their UTF-16 encoding (without = escapes), and assumes double precision floats is the model for numbers. >=20 > =20 >=20 > -- >=20 > James Manger >=20 > =20 >=20 > From: jose [mailto:jose-bounces@ietf.org = ] On Behalf Of Bret Jordan > Sent: Thursday, 11 October 2018 11:02 AM > To: Jim Schaad > > Cc: Nathaniel McCallum >; jose@ietf.org > Subject: Re: [jose] Canonical JSON form >=20 > =20 >=20 >=20 > Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere. >=20 > =20 >=20 > Preserving order is hard. Depending on your programming language you = might be deserializing the content in to a struct or you may be using a = map.=20 >=20 > =20 >=20 > What I need is a way for individuals and organizations to be able to = pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.=20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Thanks, >=20 > Bret >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >=20 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_CEE600C9-87E0-417B-AF6C-06E0D7407492 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Awesome advise.  Thanks.


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Bret,

You could define it within a draft in a = different working group other than JOSE and ask for reviewers from JOSE = to review and comment to catch problems.  Although already = described above, there are issues with this and JSON, which is why the = WG didn't want to do canonicalization.

I'm assuming you want to do basically = what was done for RID in XML using JSON.  You may want to look at = the set of possibilities to replicate as they are all likely needed with = what you are trying to do or just as part of your gap = analysis.

Also look at 9.3.1 and 9.3.2 as you're = likely to also need multi-hop authentication too.
To David's point in the message that = follows this (came in while typing), RID signed portions of the message = to enable interoperability and you are likely to need to do very similar = things that are described in RID related to the policy work I had = previously mentioned for your gap analysis as being similar = functionality.  If you haven't looked at that part of the document, = I think it will be helpful.

Best regards,
Kathleen



On Wed, Oct 10, 2018 = at 8:29 PM Manger, James <James.H.Manger@team.telstra.com> wrote:

https://tools.ietf.org/html/draft-rundgren-json-canonicalizatio= n-scheme

is a decent attempt at JSON canonicalization (and = an appendix lists a few other attempts).

This one sorts object members based on their UTF-16 = encoding (without escapes), and assumes double precision floats is the = model for numbers.

 

=

--

James Manger

 

=

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org
Subject: Re: [jose] Canonical JSON form

 


Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere.

 

Preserving order is hard.  = Depending on your programming language you might be deserializing the = content in to a struct or you may be using a map. 

 

What I need is a way for = individuals and organizations to be able to pass around and share JSON = data and collaboratively work on that JSON data and sign the parts that = they have done. 

 

 

 

Thanks,

Bret

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

"Without cryptography vihv vivc ce xhrnrw, however, = the only thing that can not be unscrambled is an egg."

 

 

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


--

Best = regards,
Kathleen

= --Apple-Mail=_CEE600C9-87E0-417B-AF6C-06E0D7407492-- From nobody Thu Oct 11 07:34:58 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0A8130E95 for ; Thu, 11 Oct 2018 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2pTDCLavtaNV for ; Thu, 11 Oct 2018 07:34:53 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853AC130E88 for ; Thu, 11 Oct 2018 07:34:53 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id m129-v6so3671365ywc.1 for ; Thu, 11 Oct 2018 07:34:53 -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=Yst+gWR6DcHkVUc6fRJ0crXuxNRvudwu2gWtibMHQWo=; b=VijScT4ASdcYkMoLBo6x6ReWYUUihGDFImFC037Wryo/woAPaNB85jxjdKFr9T3j2O 0TkSblphcqGFnl9nazkrKQAP+CpXB7nOvfpyEY4+6ktngkLGrztnOKU6BRNe+gBsjfNp oqchfNQ0uqgutZJFLA6VN1X7NvdBe4L06qABObZcohJLtvCjphav46utnYlhIvnEjVD9 2oxF4L4440zLnCoYXx3DlFwna6qGDAqqzsAH6vNR0n5frq4q5Tmc+aLzkTXDXwxwsnHF 2MQJSUdB6JYIUdjwDg+OURvDV1/JppEL+VU2AE9pjLydMOkistYMp99S6JcWfBATDCz3 hx7A== 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=Yst+gWR6DcHkVUc6fRJ0crXuxNRvudwu2gWtibMHQWo=; b=awrJ3dyerFNGBKdjT0M/yDszD+EJHQEczafGyRTQYHnpsErZll4iUjZm6v7gnvvUx1 WLK9sMnXx+wQvCCQUnq6nTWfoz17xr3daLBsGWYeBBzSTJCtJ3zOWCXvYuJ8EK2aD7/T BseQA4h0faPigzCVeqMpL7uLMK3Q1VgDLT47LWKMgvDkf+/7p0CgJxjWj1qnoGPoPmZd tl1k542kTfBUbSLtPQ7+RG4wbchcx/hzoBb6gn1GE9auPeLer0FVLKg9fUZBOi5QMznB ktdEeovVgHHhueaWMi+5FHww3h/CRunximzc9Nen31oKXoAwibA1yEi6z735TzvEpQpZ 4H8Q== X-Gm-Message-State: ABuFfoi8uaytmXAyKDL2S/wTeCTOU3X+PXZQaclpV3KkOnSZdMoFGI5H nED8rzeGxmRkLb0DkNg+P2n7+Q92 X-Google-Smtp-Source: ACcGV60NM4X8rYG0QpG2qyFxiivpBH5fDtIXp8nFTWtzL7tjBdHUP0rLS/S3jBBiqr+nxAFVOUm2hQ== X-Received: by 2002:a81:2b41:: with SMTP id r62-v6mr1039284ywr.234.1539268492872; Thu, 11 Oct 2018 07:34:52 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:7534:8ac9:bb4c:ce9d? ([2605:a601:3260:266:7534:8ac9:bb4c:ce9d]) by smtp.gmail.com with ESMTPSA id 71-v6sm10905055ywd.101.2018.10.11.07.34.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 07:34:51 -0700 (PDT) From: Bret Jordan Message-Id: <8E99AF32-6DBC-48BA-B4E8-768AFE196FB7@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C89F028D-FE12-4475-9AF1-4DDD3A700099" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 08:34:13 -0600 In-Reply-To: <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> Cc: Jim Schaad , Nathaniel McCallum , jose@ietf.org To: Neil Madden References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 14:34:57 -0000 --Apple-Mail=_C89F028D-FE12-4475-9AF1-4DDD3A700099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Neil, That is interesting. But as others have said, I need to be able to = round trip the content. The JSON data needs to be consumed by = solutions, acted on, added to, and resigned. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 10, 2018, at 11:33 PM, Neil Madden = wrote: >=20 >=20 >> On 11 Oct 2018, at 01:02, Bret Jordan wrote: >>=20 >>>=20 >>> Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere. >>=20 >> Preserving order is hard. Depending on your programming language you = might be deserializing the content in to a struct or you may be using a = map.=20 >>=20 >> What I need is a way for individuals and organizations to be able to = pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.=20 >=20 > Have you considered Git with PGP-signed commits? It solves this = use-case extremely well. >=20 > =E2=80=94 Neil --Apple-Mail=_C89F028D-FE12-4475-9AF1-4DDD3A700099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Neil,

That = is interesting.  But as others have said, I need to be able to = round trip the content.  The JSON data needs to be consumed by = solutions, acted on, added to, and resigned.

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 11:33 PM, Neil Madden <neil.madden@forgerock.com> wrote:


On 11 Oct 2018, at = 01:02, Bret Jordan <jordan.ietf@gmail.com> wrote:


Other = implementations say that you should preserver the order of the fields = you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere.

Preserving order is hard. =  Depending on your programming language you might be deserializing = the content in to a struct or you may be using a map.

What I need is a way for individuals and organizations to be = able to pass around and share JSON data and collaboratively work on that = JSON data and sign the parts that they have done.

Have you considered Git with = PGP-signed commits? It solves this use-case extremely well.

=E2=80=94 = Neil

= --Apple-Mail=_C89F028D-FE12-4475-9AF1-4DDD3A700099-- From nobody Thu Oct 11 07:40:58 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41F4130E9E for ; Thu, 11 Oct 2018 07:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1-aApinPBw8S for ; Thu, 11 Oct 2018 07:40:54 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 BD5D6126CC7 for ; Thu, 11 Oct 2018 07:40:48 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id v1-v6so3671606ywv.6 for ; Thu, 11 Oct 2018 07:40:48 -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=mHuktTF5YUdXQY/UqIIXx2vM8upFAWnK8FeJsv+xzS8=; b=JUsKRYB0A91/UeBjIXzQDMjW9x2xbKscNUIq+cqZ1nh+mjWHYlZKPApTWQ3835FsPD DPfvkCKWkLG8dqtt5rw4t/PtUMhTxdDGvO4KWLdInyRNf4A7p6RnMjHWNW+7Eo2bEEG+ u8yrH1MXu395ngXkag3d+OHUQ4jzeDyd7PHVQNERRwiKsn8FboS5vEDeAFNkCK4NSF3r yboD6Gae4lg/DW5P84DpZcucFahlJbXADCrycpHYsrSoRJBe9fTZQ+UHXwLLR6rwoG9I J6rnHmq0E3+Yg5MzjR1sidpr7UYBn+aR2tfnFNhj9WtQP2ksdA9nAXFgUZzAqhjICfMl fEYA== 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=mHuktTF5YUdXQY/UqIIXx2vM8upFAWnK8FeJsv+xzS8=; b=PUFQh3VAdczPLyGu+Ruphd6jrUsQu89MiHmaBAxpgzI9V/K5FmsYsofZbEuOA8e28b SBH9WUq4VCun3QCuqwMbN9tSH7voqJLT76aSojfwNipDS5OtdQvcOneeYVYBlCS1rbRg y+pmEyuvPv0SsHJHXXZQ4ZXDtJsp99Sx4F60mwrQAWQKbUDMohOQr8Dt6lGMXmV8yp9E vQs89nYTvfNCwGej0IwFDF6TI0iOLkmS7CWH/ooMY2ixty8Nea9KYZAkcJeXTj+75WB6 KkvJdyN4PUY4Be8XV1CpNFZKURkLvwVVyl6NGL51JRG39ZsJiiDEePhb+3PQANb9vQdd 7K2g== X-Gm-Message-State: ABuFfoh1uIjJMStstn8q0YvOvKDBNSEmymxv53NYl+RoObZsyASBSOrk 3EHuQxrLCr1jwZ+Nk6TUYO4= X-Google-Smtp-Source: ACcGV62YFNT+8j1dUGub+Pahi4dMYVOC3vKCfH6vCNGqx2xqtdtxKUt1fs9WZsoXS+RQPdylsHjYZA== X-Received: by 2002:a81:5489:: with SMTP id i131-v6mr985428ywb.87.1539268847655; Thu, 11 Oct 2018 07:40:47 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:7534:8ac9:bb4c:ce9d? ([2605:a601:3260:266:7534:8ac9:bb4c:ce9d]) by smtp.gmail.com with ESMTPSA id s3-v6sm11098071ywc.72.2018.10.11.07.40.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 07:40:46 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_27BC8545-66B3-423F-B814-ED4D8E69AB19" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 08:40:41 -0600 In-Reply-To: Cc: neil.madden@forgerock.com, Jim Schaad , npmccallum@redhat.com, jose@ietf.org To: Samuel Erdtman References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 14:40:57 -0000 --Apple-Mail=_27BC8545-66B3-423F-B814-ED4D8E69AB19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is a lot of value that the market could gain from something like = this. I think it would be great if we could do this work here in the = IETF. I for one would be willing to spend some time on it if we can = somehow get the work kickstarted. =20 I know of several large projects (most outside the IETF, but one is an = upcoming IETF project) that need this for their solutions. For the IETF = one, we will be hosting a WebEx to talk through it on the 24th, see the = CACAO mailing list if you are interested.=20 Things that I see we need to figure out are: 1) Canonicalization of JSON to enable round-tripping=20 2) Ability to sign JSON string data 3) Ability to have JSON signatures located in the content themselves = with nested signatures and partial tree signatures Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 11, 2018, at 12:44 AM, Samuel Erdtman = wrote: >=20 > I for one think this is interesting. >=20 > I have published two implementations of the draft James mentions, = draft-rundgren-json-canonicalization-scheme = ,= (Java = and JavaScript = ) and I know Anders (the = author of the draft) has implementations in .NET and Python too (all = working well together). >=20 > The I have my self been part in writing a draft that uses this = canonicalization mechanism to create signed cleartext JSON = (draft-erdtman-jose-cleartext-jws = ). I = have ported a JavaScript JOSE implementation to this new schema without = any issues and Anders has at least a Java implementation. >=20 > Finally there was a resent conversation about this subject on the = OAuth mailing-list = = recently. >=20 > Best regards > //Samuel >=20 >=20 > On Thu, Oct 11, 2018 at 7:33 AM Neil Madden > wrote: >=20 > > On 11 Oct 2018, at 01:02, Bret Jordan > wrote: > >=20 > >>=20 > >> Other implementations say that you should preserver the order of = the fields you read when serialized which is part of JSON for the = browser implementations but not necessarily elsewhere. > >=20 > > Preserving order is hard. Depending on your programming language = you might be deserializing the content in to a struct or you may be = using a map.=20 > >=20 > > What I need is a way for individuals and organizations to be able to = pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.=20 >=20 > Have you considered Git with PGP-signed commits? It solves this = use-case extremely well. >=20 > =E2=80=94 Neil > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = --Apple-Mail=_27BC8545-66B3-423F-B814-ED4D8E69AB19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There= is a lot of value that the market could gain from something like this. =  I think it would be great if we could do this work here in the = IETF.  I for one would be willing to spend some time on it if we = can somehow get the work kickstarted.  

I know of several large projects (most = outside the IETF, but one is an upcoming IETF project) that need this = for their solutions. For the IETF one, we will be hosting a WebEx to = talk through it on the 24th, see the CACAO mailing list if you are = interested. 

Things that I see we need to figure out are:

1) Canonicalization of = JSON to enable round-tripping 

2) Ability to sign JSON string = data

3) = Ability to have JSON signatures located in the content themselves with = nested signatures and partial tree signatures



Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 11, 2018, at 12:44 AM, Samuel Erdtman <samuel@erdtman.se> = wrote:

I for = one think this is interesting.

I have published two implementations of = the draft James mentions, draft-rundgren-json-canonicalization-scheme, (Java and JavaScript) and I know Anders (the author of the draft) = has implementations in .NET and Python too (all working well = together).

The I have my self been part in writing a draft that uses = this canonicalization mechanism to create signed cleartext JSON (draft-erdtman-jose-cleartext-jws). I = have ported a JavaScript JOSE implementation to this new schema without = any issues and Anders has at least a Java implementation.

Finally there was a resent conversation about this subject on = the OAuth mailing-list recently.

Best regards
//Samuel


On Thu, Oct 11, 2018 = at 7:33 AM Neil Madden <neil.madden@forgerock.com> wrote:

> On 11 Oct 2018, at 01:02, Bret Jordan <jordan.ietf@gmail.com> wrote:
>
>>
>> Other implementations say that you should preserver the order = of the fields you read when serialized which is part of JSON for the = browser implementations but not necessarily elsewhere.
>
> Preserving order is hard.  Depending on your programming = language you might be deserializing the content in to a struct or you = may be using a map.
>
> What I need is a way for individuals and organizations to be able = to pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.

Have you considered Git with PGP-signed commits? It solves this use-case = extremely well.

=E2=80=94 Neil
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_27BC8545-66B3-423F-B814-ED4D8E69AB19-- From nobody Thu Oct 11 10:24:11 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B1130EBB for ; Thu, 11 Oct 2018 10:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VioQR0dq7QeV for ; Thu, 11 Oct 2018 10:24:06 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 25A1A130EB9 for ; Thu, 11 Oct 2018 10:24:06 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id q4-v6so7208519iob.8 for ; Thu, 11 Oct 2018 10:24:06 -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=2A2B2u0pfIYEqkRog7irUjKnP0qt0BzXGp9bUhQL2K0=; b=XxYcVy03wGW+7ZQqvuAzpZ/+csqMzmsdwJP5k1ZfAwE8ulHWSpPKXc7riNQ/9hmoVy g7d275TNOBAgdxTe5Ha8IuNdtL9+MsQnqmko/mBfgtnYdzbaTTW0UGuLSJ52vkc9ouMq mDF/Y0Iem1Fuoct3ScRHeTAM/0JO22NcNBvocgdvq8Lw6MOh6zfVWMObNKap/qCbDkPu ExA2dLvWcaj2Y7a/az/e/F8WG8OVp2eTAwnTKaBeu28sA3hr67FhLvoCAAQw0FgFSdaj JsqY7gi3goSlWafR/bugNYhxxou89+r6AaHptgEYPtFQNCQ6QitR/KfxeqH4pJPyttkF U0ug== 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=2A2B2u0pfIYEqkRog7irUjKnP0qt0BzXGp9bUhQL2K0=; b=HK/jfCZldYhkwQKu0j7vNsE+gtRuMTTXctAIaN9bwqRNfOVRIwBO5dAb46ktMJDEt6 xUIiOtU8Zh3Joq1BYOTp8X7J96uPN2ZLwkZlRbzS4uhbrXqVHeCv7b2jjhO90VBYpuxj 0lZWhh69YstVeotleZzsp6ZoiJj8xy+qvDC52USK3ygd2+Nvnl4LYDLXiEuXxAFgr6Zt 8FCdkkIMmbWrKnM6VdPQMajRCOFQGpgzsO0tR5C2DUFB2hH/mscAV070crX04YyJdhW5 r9qZx+4H9I4kNGr6QOFkAZ5vubuH5qZpTrrwz7YSdD+5HTxMgKWLvJ9dQ9ZFE8Sjgk51 yXIQ== X-Gm-Message-State: ABuFfog5GAV1pcUZsyAX5KRXai5CcxYIulkVBShrktKRvT8dzume2fy6 LzqvsWgLTbZPCl9gXeejJb4= X-Google-Smtp-Source: ACcGV61ICrwGJ3YZ/mro9hpJH9Ur9udJACDLI/gpef6G0b+sFP20XD9lu3Y84M2KEOyp4W7gEymOjg== X-Received: by 2002:a6b:1885:: with SMTP id 127-v6mr1652985ioy.263.1539278645423; Thu, 11 Oct 2018 10:24:05 -0700 (PDT) Received: from [172.16.255.50] ([216.194.115.4]) by smtp.gmail.com with ESMTPSA id b20-v6sm3472730iob.26.2018.10.11.10.24.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 10:24:04 -0700 (PDT) From: Bret Jordan Message-Id: <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_217078F6-C741-40A0-B0B0-CD51DE0FAD33" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 11:23:56 -0600 In-Reply-To: Cc: "Manger, James" , jose@ietf.org To: Kathleen Moriarty References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 17:24:09 -0000 --Apple-Mail=_217078F6-C741-40A0-B0B0-CD51DE0FAD33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, =46rom your comments I take it is okay then to do a draft proposal in = another WG and then have this mailing list review it? Would we then = restart JOSE if the draft was good to have it standardized in JOSE or = just some other WG? =20 I just want to be sensitive to the work that has already been done and = build on it. I also do not want to do things that are =E2=80=9Cbad = form=E2=80=9D. We are all in this boat together, and I just want to = work with everyone to row in the same direction. BTW, I have spoken with a few other vendors and service providers and = they are also very interested in this work as it would solve a lot of = problems they have or are seeing.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty = wrote: >=20 > Bret, >=20 > You could define it within a draft in a different working group other = than JOSE and ask for reviewers from JOSE to review and comment to catch = problems. Although already described above, there are issues with this = and JSON, which is why the WG didn't want to do canonicalization. >=20 > I'm assuming you want to do basically what was done for RID in XML = using JSON. You may want to look at the set of possibilities to = replicate as they are all likely needed with what you are trying to do = or just as part of your gap analysis. >=20 > https://tools.ietf.org/html/rfc6545#section-9.1 = > Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop = authentication too. >=20 > To David's point in the message that follows this (came in while = typing), RID signed portions of the message to enable interoperability = and you are likely to need to do very similar things that are described = in RID related to the policy work I had previously mentioned for your = gap analysis as being similar functionality. If you haven't looked at = that part of the document, I think it will be helpful. >=20 > Best regards, > Kathleen >=20 >=20 >=20 > On Wed, Oct 10, 2018 at 8:29 PM Manger, James = > wrote: > = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme = > is a decent attempt at JSON canonicalization (and an appendix lists a = few other attempts). >=20 > This one sorts object members based on their UTF-16 encoding (without = escapes), and assumes double precision floats is the model for numbers. >=20 > =20 >=20 > -- >=20 > James Manger >=20 > =20 >=20 > From: jose [mailto:jose-bounces@ietf.org = ] On Behalf Of Bret Jordan > Sent: Thursday, 11 October 2018 11:02 AM > To: Jim Schaad > > Cc: Nathaniel McCallum >; jose@ietf.org > Subject: Re: [jose] Canonical JSON form >=20 > =20 >=20 >=20 > Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere. >=20 > =20 >=20 > Preserving order is hard. Depending on your programming language you = might be deserializing the content in to a struct or you may be using a = map.=20 >=20 > =20 >=20 > What I need is a way for individuals and organizations to be able to = pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.=20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Thanks, >=20 > Bret >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >=20 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_217078F6-C741-40A0-B0B0-CD51DE0FAD33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

=46rom your comments I take it is okay then to do a draft = proposal in another WG and then have this mailing list review it? =  Would we then restart JOSE if the draft was good to have it = standardized in JOSE or just some other WG?  

I just want to be = sensitive to the work that has already been done and build on it. =  I also do not want to do things that are =E2=80=9Cbad form=E2=80=9D.=  We are all in this boat together, and I just want to work with = everyone to row in the same direction.

BTW, I have spoken with a few other = vendors and service providers and they are also very interested in this = work as it would solve a lot of problems they have or are = seeing. 

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Bret,

You could define it within a draft in a = different working group other than JOSE and ask for reviewers from JOSE = to review and comment to catch problems.  Although already = described above, there are issues with this and JSON, which is why the = WG didn't want to do canonicalization.

I'm assuming you want to do basically = what was done for RID in XML using JSON.  You may want to look at = the set of possibilities to replicate as they are all likely needed with = what you are trying to do or just as part of your gap = analysis.

Also look at 9.3.1 and 9.3.2 as you're = likely to also need multi-hop authentication too.
To David's point in the message that = follows this (came in while typing), RID signed portions of the message = to enable interoperability and you are likely to need to do very similar = things that are described in RID related to the policy work I had = previously mentioned for your gap analysis as being similar = functionality.  If you haven't looked at that part of the document, = I think it will be helpful.

Best regards,
Kathleen



On Wed, Oct 10, 2018 = at 8:29 PM Manger, James <James.H.Manger@team.telstra.com> wrote:

https://tools.ietf.org/html/draft-rundgren-json-canonicalizatio= n-scheme

is a decent attempt at JSON canonicalization (and = an appendix lists a few other attempts).

This one sorts object members based on their UTF-16 = encoding (without escapes), and assumes double precision floats is the = model for numbers.

 

=

--

James Manger

 

=

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org
Subject: Re: [jose] Canonical JSON form

 


Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere.

 

Preserving order is hard.  = Depending on your programming language you might be deserializing the = content in to a struct or you may be using a map. 

 

What I need is a way for = individuals and organizations to be able to pass around and share JSON = data and collaboratively work on that JSON data and sign the parts that = they have done. 

 

 

 

Thanks,

Bret

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

"Without cryptography vihv vivc ce xhrnrw, however, = the only thing that can not be unscrambled is an egg."

 

 

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


--

Best = regards,
Kathleen

= --Apple-Mail=_217078F6-C741-40A0-B0B0-CD51DE0FAD33-- From nobody Thu Oct 11 10:26:18 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36A1130E4D for ; Thu, 11 Oct 2018 10:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZafDC_B9G_W9 for ; Thu, 11 Oct 2018 10:26:14 -0700 (PDT) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 8D15E130EB9 for ; Thu, 11 Oct 2018 10:26:14 -0700 (PDT) Received: by mail-yb1-xb41.google.com with SMTP id h1-v6so3915161ybm.4 for ; Thu, 11 Oct 2018 10:26:14 -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=59+t9TRfSCHATgo41qh0+I+ET8MXRfPtQ4jMo9PorjA=; b=XLPN3WTxgza6ej6+VxfA9t1reQCcDXx9kWftm25iSdo6McGBhkj57TIdltE/9YxZlu 7ggBjR0jqs9woBzhinBbrcfNnBeVMOkmeG4UsP4p0aFl5ojyb+c3BE3yzdnnY00mEh+0 l8+icSL1hTvTUWnfaX1ESBTiBLyQkhI3EvxaEFXuk4HP1+lGoERPoEu+R+UZGY12/+Fl H9Ub7QIbhRuwU0lhJBL3cCdOdgM8LREe8vq3eDhJY8LJZTY0MaCei0XJ7DmCIdx64VCb DNAfzMX16VXWOOe3Njqk4SKX5TcQsgKdjLojbkltsg699/8k3b6lZSnA0zaT9bg9LZGl 2hyQ== 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=59+t9TRfSCHATgo41qh0+I+ET8MXRfPtQ4jMo9PorjA=; b=G7BRe99k3T+IKmht8i1IcLCPIO3Qe3qSAtZqZA5QiEk+TYpC5wYQ0TElK6valYKpxo gmtcnW43llCOziaq+IRot5sGeb8Ac5JuLF4PQ0fvxEC3lt3bedXb7aSGuY82FrGmbYDL JzZFb5tbgYvCI8qyoIX36caRfwI5TG2YTbGQNZD421U0HYMbr6c5WjzjBpyqoM0uqx6r n/20AlwbGlSi+SkZFmli0FrFFYsMnzUzCBurQHuSVFTRlQBX3BPCMMgiMNOuUHOwBqJM Kbz4ZccL7m9sZUlSnbaZWwDoP0CP06tYaNloVuFW2jBwaBY+NYkn1p0rAjQbMj6M03Rz e8wQ== X-Gm-Message-State: ABuFfogXWOr/IJBxu6cNXA1d4oTZ2xntC0ll8dD+oihPfBVGJGpDEZCq oXaaU0dKRRqEPY4+g2wdqcdN4hpmIwjCO+EU5QM= X-Google-Smtp-Source: ACcGV61k59fKyU8ZsZeOitw2ZnsKFazr39ZiiSkISC/SZICxti+J1wvyx3AeoQX1PXGpzwh3UFL82xYb2MIhPUel2k8= X-Received: by 2002:a25:a489:: with SMTP id g9-v6mr1403091ybi.276.1539278772757; Thu, 11 Oct 2018 10:26:12 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <69EB3C20-0863-4D00-948B-989EB69D67CD@forgerock.com> <8E99AF32-6DBC-48BA-B4E8-768AFE196FB7@gmail.com> In-Reply-To: <8E99AF32-6DBC-48BA-B4E8-768AFE196FB7@gmail.com> From: Sergey Beryozkin Date: Thu, 11 Oct 2018 18:26:01 +0100 Message-ID: To: jordan.ietf@gmail.com Cc: neil.madden@forgerock.com, Jim Schaad , Nathaniel McCallum , jose@ietf.org Content-Type: multipart/alternative; boundary="00000000000075e8b60577f744a2" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 17:26:17 -0000 --00000000000075e8b60577f744a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi If the signature can be verified then what difference does it make what the signature value is, the same for every JSON variation or not ? If JSON1, JSON2, etc, with some minor formatting differences, all make it, after being validated, into SomeJsonBean, then it should work ? Thanks, Sergey On Thu, Oct 11, 2018 at 3:35 PM Bret Jordan wrote: > Neil, > > That is interesting. But as others have said, I need to be able to round > trip the content. The JSON data needs to be consumed by solutions, acted > on, added to, and resigned. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > On Oct 10, 2018, at 11:33 PM, Neil Madden > wrote: > > > On 11 Oct 2018, at 01:02, Bret Jordan wrote: > > > Other implementations say that you should preserver the order of the > fields you read when serialized which is part of JSON for the browser > implementations but not necessarily elsewhere. > > > Preserving order is hard. Depending on your programming language you > might be deserializing the content in to a struct or you may be using a > map. > > What I need is a way for individuals and organizations to be able to pass > around and share JSON data and collaboratively work on that JSON data and > sign the parts that they have done. > > > Have you considered Git with PGP-signed commits? It solves this use-case > extremely well. > > =E2=80=94 Neil > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --00000000000075e8b60577f744a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

If the signature can be v= erified then what difference does it make what the signature value is, the = same for every JSON variation or not ? If JSON1, JSON2, etc, with some mino= r formatting differences, all make it, after being validated, into SomeJson= Bean, then it should work ?

Thanks, Sergey=C2=A0 <= br>

On Thu, Oct = 11, 2018 at 3:35 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
Neil,<= div>
That is interesting.=C2=A0 But as others have said, I ne= ed to be able to round trip the content.=C2=A0 The JSON data needs to be co= nsumed by solutions, acted on, added to, and resigned.

Thanks,
Bret
<= span class=3D"m_-8840283613740599602Apple-style-span" style=3D"border-colla= pse:separate;text-align:-webkit-auto;border-spacing:0px">
PGP Fingerprint= :=C2=A063B4 FC53 680A 6B7D 1447= =C2=A0F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, h= owever, the only thing that can not be unscrambled is an egg."<= /div>

On Oct 10, 2018, at 11:33 PM, Neil = Madden <n= eil.madden@forgerock.com> wrote:


On = 11 Oct 2018, at 01:02, Bret Jordan <jordan.ietf@gmail.com> wrote:


Other implementations say that you should preserver t= he order of the fields you read when serialized which is part of JSON for t= he browser implementations but not necessarily elsewhere.
<= br>Preserving order is hard.=C2=A0 Depending on your programming language y= ou might be deserializing the content in to a struct or you may be using a = map.

What I need is a way for individuals and organizations to be a= ble to pass around and share JSON data and collaboratively work on that JSO= N data and sign the parts that they have done.

Have yo= u considered Git with PGP-signed commits? It solves this use-case extremely= well.

=E2=80=94 Neil

= _______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--00000000000075e8b60577f744a2-- From nobody Thu Oct 11 11:06:41 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A17130EB9 for ; Thu, 11 Oct 2018 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fmSNaKYURf_0 for ; Thu, 11 Oct 2018 11:06:37 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 66AA9130E82 for ; Thu, 11 Oct 2018 11:06:37 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id p125-v6so7807592oic.3 for ; Thu, 11 Oct 2018 11:06:37 -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=apoRRhTQ76KrGUzRjTg+YF47FkgsddVt4ZvT/FN/l9k=; b=OCyV/0zI8swGaIJqUdEWvfd6/Y86d7gERSakgau08NAxESHVvvqi09MWQO/k+gbOqC APRvv1ecRes9k+iNK7unh1eG+riz6ACDZR8ZIjzWDiR1jH16o8uhnAR9Q3sVyfP7iZnD wBsgZI6TFqVeJtaOjM5knjjeZjPksge582tKySZ3o3IsQD8brzEq3U0ni+nOT25RwBTQ qH+tVMNVC0x3sHeabJG+CxBpi8jPl90WCpSD59KYYYKpt56GCoxNoZxlu2qwM+v6axwX xtfYJmkYt13csJuWli/d9EmCvsDESQbO4a42Aml/o7jfQwHUmOKjtzSNoe9LwhQOH2EJ Az/w== 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=apoRRhTQ76KrGUzRjTg+YF47FkgsddVt4ZvT/FN/l9k=; b=dcl3QLG5JthWMAbksJ9bhikQCF/HkXcPDb978h0d4MTeIrEcIEltDTdgFcINZEOYiO SLEnzEjWoPHSFlm1setM7UQWSsbiLA8BnnGpEQIRLc89+7BKnT4gWlVA/q+76iNukqHS BTsq4TxXXKSy4XfJO2Omw78+x78kRfKmM4rulVvFQ5HT1WvpQDV8tD4cGLqnPXUCCye4 MpqkZRxjJTf4xxNSeKZlfH37hkPkE0V7xOxtkc5sqFyuN2ypNtqEsu9G5e1jd+SojjyV UtImdNB9D7Ldg8WYhvlRByxtt/24uYx5JYZw/5uEOqCvfx5ssaCfYnAx3NLtMItzvPkV Kcew== X-Gm-Message-State: ABuFfogzRRVy7S7d0+ZMAlz8Je14qgs6qnOx8duLO78vtn/UlreYtB+6 feJ+uuANOBNFOLSOl2pGLmYBpPRDlZtta7quO5k= X-Google-Smtp-Source: ACcGV63w/yyT9EhPYvOtx5mgB3qn83dGcYdFKvdkFGAlHkCdZnCv5sVDzm1L91uNwcNs1Wtc29uWHQpKNeZtTF8BOAM= X-Received: by 2002:aca:e501:: with SMTP id c1-v6mr1406312oih.281.1539281196622; Thu, 11 Oct 2018 11:06:36 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> In-Reply-To: <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> From: Kathleen Moriarty Date: Thu, 11 Oct 2018 14:06:00 -0400 Message-ID: To: Bret Jordan Cc: "Manger, James" , jose@ietf.org Content-Type: multipart/alternative; boundary="000000000000ef2af20577f7d463" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 18:06:41 -0000 --000000000000ef2af20577f7d463 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bret, JOSE is closed, so a new WG would have to be formed if this were to be done in a WG. That might be reopening JOSE or something else. Another possibility is for James to try to progress his existing draft and determine interest. Has it been presented at SecDispatch yet to gauge interest and uncover problems? You could also consider alternate solutions. The problems cited were problems with XML already. Since RID defined the same capability, you could test out interoperability using RID in XML more extensively as you'd be mapping the same functionality into JSON. This would give you in your new effort feedback into design considerations and help you determine if you really want to go this route or perhaps some other solution may be preferred (see Neil's message). In any case, more work should be done before a new WG around canonicalization is performed IMO, but I am also no longer an AD, so advice from current ones may vary :-) Best, Kathleen On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan wrote: > Kathleen, > > From your comments I take it is okay then to do a draft proposal in > another WG and then have this mailing list review it? Would we then > restart JOSE if the draft was good to have it standardized in JOSE or jus= t > some other WG? > > I just want to be sensitive to the work that has already been done and > build on it. I also do not want to do things that are =E2=80=9Cbad form= =E2=80=9D. We are > all in this boat together, and I just want to work with everyone to row i= n > the same direction. > > BTW, I have spoken with a few other vendors and service providers and the= y > are also very interested in this work as it would solve a lot of problems > they have or are seeing. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Bret, > > You could define it within a draft in a different working group other tha= n > JOSE and ask for reviewers from JOSE to review and comment to catch > problems. Although already described above, there are issues with this a= nd > JSON, which is why the WG didn't want to do canonicalization. > > I'm assuming you want to do basically what was done for RID in XML using > JSON. You may want to look at the set of possibilities to replicate as > they are all likely needed with what you are trying to do or just as part > of your gap analysis. > > https://tools.ietf.org/html/rfc6545#section-9.1 > Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop > authentication too. > > To David's point in the message that follows this (came in while typing), > RID signed portions of the message to enable interoperability and you are > likely to need to do very similar things that are described in RID relate= d > to the policy work I had previously mentioned for your gap analysis as > being similar functionality. If you haven't looked at that part of the > document, I think it will be helpful. > > Best regards, > Kathleen > > > > On Wed, Oct 10, 2018 at 8:29 PM Manger, James < > James.H.Manger@team.telstra.com> wrote: > >> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme >> >> is a decent attempt at JSON canonicalization (and an appendix lists a fe= w >> other attempts). >> >> This one sorts object members based on their UTF-16 encoding (without >> escapes), and assumes double precision floats is the model for numbers. >> >> >> >> -- >> >> James Manger >> >> >> >> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Bret Jordan >> *Sent:* Thursday, 11 October 2018 11:02 AM >> *To:* Jim Schaad >> *Cc:* Nathaniel McCallum ; jose@ietf.org >> *Subject:* Re: [jose] Canonical JSON form >> >> >> >> >> Other implementations say that you should preserver the order of the >> fields you read when serialized which is part of JSON for the browser >> implementations but not necessarily elsewhere. >> >> >> >> Preserving order is hard. Depending on your programming language you >> might be deserializing the content in to a struct or you may be using a >> map. >> >> >> >> What I need is a way for individuals and organizations to be able to pas= s >> around and share JSON data and collaboratively work on that JSON data an= d >> sign the parts that they have done. >> >> >> >> >> >> >> >> Thanks, >> >> Bret >> >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg." >> >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > > > -- > > Best regards, > Kathleen > > > --=20 Best regards, Kathleen --000000000000ef2af20577f7d463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bret,

JOSE is closed, so a new WG wo= uld have to be formed if this were to be done in a WG.=C2=A0 That might be = reopening JOSE or something else.=C2=A0 Another possibility is for James to= try to progress his existing draft and determine interest.=C2=A0 Has it be= en presented at SecDispatch yet to gauge interest and uncover problems?

You could also consider alternate solutions.=C2=A0 Th= e problems cited were problems with XML already.=C2=A0 Since RID defined th= e same capability, you could test out interoperability using RID in XML mor= e extensively as you'd be mapping the same functionality into JSON.=C2= =A0 This would give you in your new effort feedback into design considerati= ons and help you determine if you really want to go this route or perhaps s= ome other solution may be preferred (see Neil's message).=C2=A0 In any = case, more work should be done before a new WG around canonicalization is p= erformed IMO, but I am also no longer an AD, so advice from current ones ma= y vary :-)

Best,
Kathleen
On Thu, Oct 11, 2018 at 1:24 P= M Bret Jordan <jordan.ietf@gmai= l.com> wrote:
Kathleen,

=
From your comments I take it is okay then to do a draft proposal in an= other WG and then have this mailing list review it?=C2=A0 Would we then res= tart JOSE if the draft was good to have it standardized in JOSE or just som= e other WG? =C2=A0

I just want to be sensitive to = the work that has already been done and build on it.=C2=A0 I also do not wa= nt to do things that are =E2=80=9Cbad form=E2=80=9D.=C2=A0 We are all in th= is boat together, and I just want to work with everyone to row in the same = direction.

BTW, I have spoken with a few other ven= dors and service providers and they are also very interested in this work a= s it would solve a lot of problems they have or are seeing.=C2=A0

Thanks,
Bret
<= span class=3D"m_-7808765980908274049Apple-style-span" style=3D"border-colla= pse:separate;text-align:-webkit-auto;border-spacing:0px">
PGP Fingerprint= :=C2=A063B4 FC53 680A 6B7D 1447= =C2=A0F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, h= owever, the only thing that can not be unscrambled is an egg."<= /div>

On Oct 10, 2018, at 7:47 PM, Kathle= en Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

=
Bret,

You could define it within a draf= t in a different working group other than JOSE and ask for reviewers from J= OSE to review and comment to catch problems.=C2=A0 Although already describ= ed above, there are issues with this and JSON, which is why the WG didn'= ;t want to do canonicalization.

I'm assuming y= ou want to do basically what was done for RID in XML using JSON.=C2=A0 You = may want to look at the set of possibilities to replicate as they are all l= ikely needed with what you are trying to do or just as part of your gap ana= lysis.

Also look at 9.3.1 and 9.3.2 as you're likely= to also need multi-hop authentication too.

To Dav= id's point in the message that follows this (came in while typing), RID= signed portions of the message to enable interoperability and you are like= ly to need to do very similar things that are described in RID related to t= he policy work I had previously mentioned for your gap analysis as being si= milar functionality.=C2=A0 If you haven't looked at that part of the do= cument, I think it will be helpful.

Best regards,<= /div>
Kathleen



On Wed, Oct 10, 2018 at 8:29 PM Mang= er, James <James.H.Manger@team.telstra.com> wrote:

https://tools= .ietf.org/html/draft-rundgren-json-canonicalization-scheme

is a decent attempt at JS= ON canonicalization (and an appendix lists a few other attempts).=

This one sorts object = members based on their UTF-16 encoding (without escapes), and assumes doubl= e precision floats is the model for numbers.

= =C2=A0

--

James Manger

=C2=A0

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org
Subject: Re: [jose] Canonical JSON form

=C2=A0


Other implementations say that you should preserver the order of the fields= you read when serialized which is part of JSON for the browser implementat= ions but not necessarily elsewhere.

=C2=A0

Preserving order is hard.=C2=A0 Depending on yo= ur programming language you might be deserializing the content in to a stru= ct or you may be using a map.=C2=A0

=C2=A0

What I need is a way for individuals and organi= zations to be able to pass around and share JSON data and collaboratively w= ork on that JSON data and sign the parts that they have done.=C2=A0<= u>

=C2=A0

=C2=A0

=C2=A0

Thanks,

Bret

PGP Fingerprint:=C2=A063B4 FC53 6= 80A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv v= ivc ce xhrnrw, however, the only thing that can not be unscrambled is an eg= g."

=C2=A0

=C2=A0

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


--

Best regards,
Kathleen



--

Best regards,
Kathleen
--000000000000ef2af20577f7d463-- From nobody Thu Oct 11 11:23:13 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508FA1200D7 for ; Thu, 11 Oct 2018 11:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, 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=oracle.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 NI78MRpaFNZk for ; Thu, 11 Oct 2018 11:23:08 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.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 A8311130ECF for ; Thu, 11 Oct 2018 11:23:08 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9BIITUa190909; Thu, 11 Oct 2018 18:23:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=yTQfQIiY7jeGplpCwMeLg1/lYpjFr4ETP3VZ6i1agJM=; b=ULz86inHvfJURRQQKvrityEKCMrM8bF0u0LWGFKERNJhIsI/PkJT+U4nn1gZpZb/YzgK YA/G8EGE5LWHtB7uzBa7uS0sbpqzKIDYh1BqYsOHdnWH6P1Cg/agd6dIkN7iRPqF626N sHP8aYzxhdFIlZrxMCGgAkMPACLa2TgnWBVYxhyf36FsY6s5MMPemhe2FkfxWDjBGizQ pg6EkyApXYb5CiiVHseNAOdEMDBK8B/uQ9g+5LAEXStLuorLArO9iKVYx+Tf244RKP1c saahy2gABDA8RMaIiz4xqrG47+DS3vY8zF3A9UyOMECPLU5N6aXNxO/YpKTHVnrRurlr xg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2mxnpre2kj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Oct 2018 18:23:06 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9BIN5wM003877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Oct 2018 18:23:05 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9BIN4G5032343; Thu, 11 Oct 2018 18:23:04 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Oct 2018 18:23:04 +0000 From: Phil Hunt Message-Id: <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_88EA06CB-34F5-4C31-B63B-8CE68E11F254" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 11:23:02 -0700 In-Reply-To: Cc: Bret Jordan , "Manger, James" , jose@ietf.org To: Kathleen Moriarty References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9042 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810110173 Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 18:23:12 -0000 --Apple-Mail=_88EA06CB-34F5-4C31-B63B-8CE68E11F254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am not sure of the value of canonicalization. I prefer bytestream = encoding style where the original content goes with the signature. Another example is ATLAS which signs encoded http requests. Some JSON formats will have the same issues that XMLDSIG had. For = example, SCIM supports multiple ways to identfiy attributes much like = XML (it uses IANA registered schemas). You can reference an attribute = with the full path or just its name. We tried to avoid schemas, but = localized extensibility and easy of coding forced us to do this. So for = SCIM it is easier to canonicalize than XML, but I would not say simple. =20= In the end, I felt it was a good trade-off because of an assumption to = sign encoded json data instead. Note: SCIM does not yet have a signed format. I anticipate however the = development of signed SCIM events per the new SET spec. If you were to proceed, I would recommend including considerations = identifying JSON formats not well suited to canonicalization. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 11, 2018, at 11:06 AM, Kathleen Moriarty = wrote: >=20 > Hi Bret, >=20 > JOSE is closed, so a new WG would have to be formed if this were to be = done in a WG. That might be reopening JOSE or something else. Another = possibility is for James to try to progress his existing draft and = determine interest. Has it been presented at SecDispatch yet to gauge = interest and uncover problems? >=20 > You could also consider alternate solutions. The problems cited were = problems with XML already. Since RID defined the same capability, you = could test out interoperability using RID in XML more extensively as = you'd be mapping the same functionality into JSON. This would give you = in your new effort feedback into design considerations and help you = determine if you really want to go this route or perhaps some other = solution may be preferred (see Neil's message). In any case, more work = should be done before a new WG around canonicalization is performed IMO, = but I am also no longer an AD, so advice from current ones may vary :-) >=20 > Best, > Kathleen >=20 > On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan > wrote: > Kathleen, >=20 > =46rom your comments I take it is okay then to do a draft proposal in = another WG and then have this mailing list review it? Would we then = restart JOSE if the draft was good to have it standardized in JOSE or = just some other WG? =20 >=20 > I just want to be sensitive to the work that has already been done and = build on it. I also do not want to do things that are =E2=80=9Cbad = form=E2=80=9D. We are all in this boat together, and I just want to = work with everyone to row in the same direction. >=20 > BTW, I have spoken with a few other vendors and service providers and = they are also very interested in this work as it would solve a lot of = problems they have or are seeing.=20 >=20 > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 >> On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty = > wrote: >>=20 >> Bret, >>=20 >> You could define it within a draft in a different working group other = than JOSE and ask for reviewers from JOSE to review and comment to catch = problems. Although already described above, there are issues with this = and JSON, which is why the WG didn't want to do canonicalization. >>=20 >> I'm assuming you want to do basically what was done for RID in XML = using JSON. You may want to look at the set of possibilities to = replicate as they are all likely needed with what you are trying to do = or just as part of your gap analysis. >>=20 >> https://tools.ietf.org/html/rfc6545#section-9.1 = >> Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop = authentication too. >>=20 >> To David's point in the message that follows this (came in while = typing), RID signed portions of the message to enable interoperability = and you are likely to need to do very similar things that are described = in RID related to the policy work I had previously mentioned for your = gap analysis as being similar functionality. If you haven't looked at = that part of the document, I think it will be helpful. >>=20 >> Best regards, >> Kathleen >>=20 >>=20 >>=20 >> On Wed, Oct 10, 2018 at 8:29 PM Manger, James = > wrote: >> = https://tools..ietf.org/html/draft-rundgren-json-canonicalization-scheme = >> is a decent attempt at JSON canonicalization (and an appendix lists a = few other attempts). >>=20 >> This one sorts object members based on their UTF-16 encoding (without = escapes), and assumes double precision floats is the model for numbers. >>=20 >> =20 >>=20 >> -- >>=20 >> James Manger >>=20 >> =20 >>=20 >> From: jose [mailto:jose-bounces@ietf.org = ] On Behalf Of Bret Jordan >> Sent: Thursday, 11 October 2018 11:02 AM >> To: Jim Schaad > >> Cc: Nathaniel McCallum >; jose@ietf.org >> Subject: Re: [jose] Canonical JSON form >>=20 >> =20 >>=20 >>=20 >> Other implementations say that you should preserver the order of the = fields you read when serialized which is part of JSON for the browser = implementations but not necessarily elsewhere. >>=20 >> =20 >>=20 >> Preserving order is hard. Depending on your programming language you = might be deserializing the content in to a struct or you may be using a = map.=20 >>=20 >> =20 >>=20 >> What I need is a way for individuals and organizations to be able to = pass around and share JSON data and collaboratively work on that JSON = data and sign the parts that they have done.=20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> Thanks, >>=20 >> Bret >>=20 >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>=20 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>=20 >> =20 >>=20 >> =20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose = >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > jose mailing list > jose@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE= &r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DMMo12b48B6GqvKdy8eBzH= 6ZAMMue9XSrSjSfwjHnqkQ&s=3D68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=3D= = --Apple-Mail=_88EA06CB-34F5-4C31-B63B-8CE68E11F254 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am not sure of the value of canonicalization.  I prefer bytestream = encoding style where the original content goes with the signature.

Another example is ATLAS = which signs encoded http requests.

Some JSON formats will have the same = issues that XMLDSIG had.  For example, SCIM supports multiple ways = to identfiy attributes much like XML (it uses IANA registered schemas). = You can reference an attribute with the full path or just its name. =  We tried to avoid schemas, but localized extensibility and easy of = coding forced us to do this.  So for SCIM it is easier to = canonicalize than XML, but I would not say simple.  

In the = end, I felt it was a good trade-off because of an assumption to sign = encoded json data instead.

Note:  SCIM does not yet have a = signed format. I anticipate however the development of signed SCIM = events per the new SET spec.

If you were to proceed, I would = recommend including considerations identifying JSON formats not well = suited to canonicalization.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
phil.hunt@oracle.com

On Oct 11, 2018, at 11:06 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi = Bret,

JOSE is = closed, so a new WG would have to be formed if this were to be done in a = WG.  That might be reopening JOSE or something else.  Another = possibility is for James to try to progress his existing draft and = determine interest.  Has it been presented at SecDispatch yet to = gauge interest and uncover problems?

You could also consider alternate = solutions.  The problems cited were problems with XML = already.  Since RID defined the same capability, you could test out = interoperability using RID in XML more extensively as you'd be mapping = the same functionality into JSON.  This would give you in your new = effort feedback into design considerations and help you determine if you = really want to go this route or perhaps some other solution may be = preferred (see Neil's message).  In any case, more work should be = done before a new WG around canonicalization is performed IMO, but I am = also no longer an AD, so advice from current ones may vary :-)

Best,
Kathleen

On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
Kathleen,

=46rom your comments I take it is okay then to do a draft = proposal in another WG and then have this mailing list review it?  = Would we then restart JOSE if the draft was good to have it standardized = in JOSE or just some other WG?  

I just want to be sensitive to the work = that has already been done and build on it.  I also do not want to = do things that are =E2=80=9Cbad form=E2=80=9D.  We are all in this = boat together, and I just want to work with everyone to row in the same = direction.

BTW, = I have spoken with a few other vendors and service providers and they = are also very interested in this work as it would solve a lot of = problems they have or are seeing. 

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 10, 2018, at 7:47 PM, Kathleen = Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Bret,

You = could define it within a draft in a different working group other than = JOSE and ask for reviewers from JOSE to review and comment to catch = problems.  Although already described above, there are issues with = this and JSON, which is why the WG didn't want to do = canonicalization.

I'm assuming you want to do basically what was done for RID = in XML using JSON.  You may want to look at the set of = possibilities to replicate as they are all likely needed with what you = are trying to do or just as part of your gap analysis.

Also look at 9.3.1 and 9.3.2 as you're = likely to also need multi-hop authentication too.
To David's point in the message that = follows this (came in while typing), RID signed portions of the message = to enable interoperability and you are likely to need to do very similar = things that are described in RID related to the policy work I had = previously mentioned for your gap analysis as being similar = functionality.  If you haven't looked at that part of the document, = I think it will be helpful.

Best regards,
Kathleen



On Wed, Oct 10, 2018 = at 8:29 PM Manger, James <James.H.Manger@team.telstra.com> wrote:

https://tools..ietf.org/html/draft-rundgren-json-canonicalizati= on-scheme

is a decent = attempt at JSON canonicalization (and an appendix lists a few other = attempts).

This one sorts = object members based on their UTF-16 encoding (without escapes), and = assumes double precision floats is the model for numbers.

 

--

James Manger

 

From: jose = [mailto:jose-bounces@ietf.org] On Behalf = Of Bret Jordan
Sent: Thursday, 11 October 2018 = 11:02 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>; jose@ietf.org
Subject: 
Re: [jose] Canonical JSON = form

 


Other implementations say that you should preserver the order = of the fields you read when serialized which is part of JSON for the = browser implementations but not necessarily elsewhere.

 

Preserving order is hard.  Depending on your = programming language you might be deserializing the content in to a = struct or you may be using a map. 

 

What I need is a way for individuals and = organizations to be able to pass around and share JSON data and = collaboratively work on that JSON data and sign the parts that they have = done. 

 

 

 

Thanks,

Bret

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

"Without cryptography = vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled = is an egg."

 

 

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


-- 

Best regards,
Kathleen



-- 

Best regards,
Kathleen
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3DMMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=3D68ephlmudUEVF-9E= E70huCbhCWZMtZFLhQwmunkXcbc&e=3D

= --Apple-Mail=_88EA06CB-34F5-4C31-B63B-8CE68E11F254-- From nobody Thu Oct 11 12:04:12 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C17130EDD for ; Thu, 11 Oct 2018 12:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FIKMfr2cyRSp for ; Thu, 11 Oct 2018 12:03:59 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 6F13A130F13 for ; Thu, 11 Oct 2018 12:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9BJ3oXd010002; Thu, 11 Oct 2018 21:03:55 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42WL3T660qz1Bpf; Thu, 11 Oct 2018 21:03:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> Date: Thu, 11 Oct 2018 21:03:49 +0200 Cc: Kathleen Moriarty , "Manger, James" , jose@ietf.org, Bret Jordan X-Mao-Original-Outgoing-Id: 560977427.06664-01278306aabfbed98d947bd3fe347812 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 19:04:02 -0000 On Oct 11, 2018, at 20:23, Phil Hunt wrote: >=20 > I am not sure of the value of canonicalization. I prefer bytestream = encoding style where the original content goes with the signature. I=E2=80=99m afraid a lot of people are sitting in front of their screens = silently agreeing, but not typing anything because their hands are tied = up in an interminable facepalm. So, for the record: To the people asking for a c14n solution for signature: If you want = XMLDSig, you know where to find it. The basic approach of having humongous XML documents that get signatures = added to themselves as part of the document only makes sense in certain = processing models that went out of favor with XML. JOSE does the right thing for more modern applications. I=E2=80=99m not opposed to doing some =E2=80=9Cc14n=E2=80=9D work on = serialization schemes =E2=80=94 deterministic serialization has other = applications than just XMLDSig. That would be work for a JSONbis WG (but I fear the interest level among = JSON experts will be low). I definitely do not like giving the message that c14n-based signatures = are the new thing that will replace doing the right thing (JOSE, that = is). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 11 12:10:32 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E824F12008A for ; Thu, 11 Oct 2018 12:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 M30gC-AYBOlO for ; Thu, 11 Oct 2018 12:10:26 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 A396B130F0F for ; Thu, 11 Oct 2018 12:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1539285025; x=1570821025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uvRHnlkMdC/B6Z03ot0U5Oi2jSKnrAWG+UJQm3IUp8I=; b=1zXcpkCmrHm3JigA/GA5Umum3xkKMxBzsCMUIct5yh8YCE4efPH7tIJV ELKPc9RJFTYD1dQ5gX3XiqKtOY0NimeJVD6TI4fujM3PQVUpuZe5nVuQr W7ITCKpRNWPN4yf60tuMkL9pRbWZ8FZZ/NHI6I2sZ3cx/cd/IR9e0Fvz/ d08sYerSLdIn/5r0PKRsoKUn+WurXWEYYCWvs2lde5igRIBsrYIh3/RpM fCqDK90Z76YvfemaIsRD33lQIpv9V0FkYTzuCq0F4jRWZrYF6fDVwnDJg f0G2pyibwdbr2+caw5+/esBCwgxz60tqL+it6wPY+g6Qmh8lN8WBWFq0d A==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 21:10:22 +0200 X-IronPort-AV: E=Sophos;i="5.54,369,1534802400"; d="scan'208,217";a="271633717" Received: from he105789.emea1.cds.t-internal.com ([10.169.118.28]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Oct 2018 21:10:22 +0200 Received: from HE101953.EMEA1.cds.t-internal.com (10.169.118.78) by HE105789.emea1.cds.t-internal.com (10.169.118.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 21:10:22 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101953.EMEA1.cds.t-internal.com (10.169.118.78) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Oct 2018 21:10:22 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 11 Oct 2018 21:10:19 +0200 Received: from LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE (10.158.170.9) by LEXPR01MB1085.DEUPRD01.PROD.OUTLOOK.DE (10.158.170.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.28; Thu, 11 Oct 2018 19:10:20 +0000 Received: from LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE ([fe80::4c1d:345:7b40:8da7]) by LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE ([fe80::4c1d:345:7b40:8da7%2]) with mapi id 15.20.1207.029; Thu, 11 Oct 2018 19:10:20 +0000 From: To: , CC: , , Thread-Topic: [jose] Canonical JSON form Thread-Index: AQHUYMwaB98XZpFud0i4H76S15NehKUY2XsAgAAaOgCAAAPogIAAL5qAgAACeoCAAAeegIAAFeAAgAEFmQCAAAvBAIAABMIAgAAKBKA= Date: Thu, 11 Oct 2018 19:10:20 +0000 Message-ID: References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> In-Reply-To: <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Axel.Nennker@telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEXPR01MB1085; 6:o4Zgq6876AxK1/fZgyIHTLUCJ3DqqWm1VzWlDtRZnUhAPZWwkOrLfGVxGa4RYG0/tyYjdEGq1Y94+9V/AP3cEW7d7c3vWESXBzFtzHVC3F03YstK8t9DTv7EQn6g+DeRqmCgjqHnZkjdLNu9aVeHMXt6nT1Qc85WjAWzEweDdJRG59EPZT2rZOZcoz5p9rFJrX0WzKTTO1fVm4mCpt4U3u8rGWZmGGkqzmq8utmlkl+JW32a+ZwIxTzKCAn5QTBkaSlZiKpPNcjXYhaBDz2dzSHUs63ljKLz3OlSGWmJeb9gMEdpLXG3UezB6BjDgwsPrAlwluRHGzOO6s2F8SZbB2cMp/IdivBsz5+CV79takUryfh3rija4j0Hmh+VmyYNhqOs8rTB3UWwJwhdagY8M344FQi5g+HhlUGm06o0XQF2vmcDUcEXaNtkotOE+F+LrXbo/RbVUeAF6wpvD4oaTQ==; 5:1W+/IAHO7yhX6drHZcuXi4Y8vTV/0fshqXZCi2gfE81Y9TPDUrzIdApjXmDJv1te0rnYeJTYkU7sA1oxtB6wDqKCI+0D1n4n4EFOnWyQi1lPXu76dVE0Uai+5dGDcN7t2cQmA9AlQOFjf0t71MrlVZZMDHaiIjhN1i1LDspl8fw=; 7:7oEPkk1J2sxDqm1If2gncHmNecZ5hqukLPk+IzgyyqzVY66QBBmixbWs/BFn5GIV6rPbN8rqY4NddX89CQA17/izgl2F/q1gy2aSsVyHEQ9E8EqhgCdxACJJLVx7lZW3p8aa6Um0A8CKcDbXrOp+Hdhzt/pDdOtf1GnOMGUbP+YsgtGYaZ2pe7JtnijGab7tCgMNm+2aq6+/jEs+NImlsK91OUHC9hjfrIWR/XpyO5t6KfxdFfCQa44vmvFfsilJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0a41ee82-fef3-484d-f8f8-08d62fad307f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:LEXPR01MB1085; x-ms-traffictypediagnostic: LEXPR01MB1085: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(272811157607776)(67441168502697)(146099531331640)(10436049006162)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(163750095850); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231355)(944501410)(4982022)(52105095)(93006095)(93001095)(3002001)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991060); SRVR:LEXPR01MB1085; BCL:0; PCL:0; RULEID:; SRVR:LEXPR01MB1085; x-forefront-prvs: 08220FA8D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(366004)(39860400002)(199004)(189003)(110136005)(966005)(478600001)(68736007)(5660300001)(4326008)(6246003)(2900100001)(14454004)(53386004)(6306002)(54896002)(229853002)(72206003)(19609705001)(2906002)(86362001)(446003)(7736002)(33656002)(11346002)(1680700002)(186003)(561944003)(476003)(39060400002)(6116002)(790700001)(3846002)(486006)(66066001)(256004)(106356001)(105586002)(102836004)(316002)(14444005)(26005)(66574009)(9686003)(81166006)(53936002)(55016002)(54906003)(236005)(606006)(75402003)(71190400001)(74482002)(97736004)(93886005)(8676002)(8936002)(52396003)(5250100002)(76176011)(81156014)(7696005)(71200400001)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB1085; H:LEXPR01MB1087.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: N3/x/PaHzmSYH1MdOkcqSA7a0XnLL6G/EHUkyz+qg9kDEL3GQVoTZk+dxnj3wl+8amonvsXY/xjrk3wGPBQkMX/ishzqf/POSyYPLu3+6XpbKd3rTeYRjmSwrbEGww9AeBwhPztC03SaTL4XnG6dvJ6Dj0z1XiCCconRrb3kNPG4rhiCDOKPN50hUr9+HiMOC0WjSLhb5u0BCq4qfoifPjcgZmjRyGM8Pqt5cxSjW/fZj5MkeAWnY8+FMZqsmnKNmb7XHwpAFQEZ6wr4hFFLHfntXrwkF94lYVJDRTS/yYUCCD+9Y+UxAv7hHvGXiCspRWL98KWPkt4mz7T5lp/Gh0E8tb+G24xV/PZKlrJbGB8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LEXPR01MB108728E1534F022A779A9883EDE10LEXPR01MB1087DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0a41ee82-fef3-484d-f8f8-08d62fad307f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 19:10:20.8732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB1085 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 19:10:31 -0000 --_000_LEXPR01MB108728E1534F022A779A9883EDE10LEXPR01MB1087DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCBQaGlsLiBYbWxkc2lnIHdhcyBhIHBhaW4gZm9yIGRldmVs b3BlcnMsIGxpYnJhcmllcyBkaWQgaXQgZGlmZmVyZW50bHkgdGh1cyBjYXVzaW5nIGludGVyb3Bl cmFiaWxpdHkgcHJvYmxlbXMuDQpKb3NlIHdhcyBkZXNpZ25lZCBzaW1wbGUgYnV0IGEgY2Fub25p Y2FsIEpTT04gZm9ybSBpbnRyb2R1Y2VzIG5ldyBjb21wbGV4aXR5Lg0KV2UgaGFkIHRoZSBzYW1l IHdpdGggT2F1dGgxIOKAkyBkZXZlbG9wZXJzIHdlcmUgbm90IGFibGUgdG8gc29ydCB0aGUgVVJM IHBhcmFtZXRlcnMgYWNjb3JkaW5nIHRvIHRoZSBzcGVjLg0KU28gam9zZSBpcyBiZXR0ZXIgb2Zm IHdpdGhvdXQgY2Fub25pY2FsIEpTT04uDQoNCi8vQXhlbA0KDQoNCkZyb206IGpvc2UgW21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IERv bm5lcnN0YWcsIDExLiBPa3RvYmVyIDIwMTggMjA6MjMNClRvOiBLYXRobGVlbiBNb3JpYXJ0eSA8 a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQpDYzogTWFuZ2VyLCBKYW1lcyA8SmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT47IGpvc2VAaWV0Zi5vcmc7IEJyZXQgSm9yZGFu IDxqb3JkYW4uaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW2pvc2VdIENhbm9uaWNhbCBK U09OIGZvcm0NCg0KSSBhbSBub3Qgc3VyZSBvZiB0aGUgdmFsdWUgb2YgY2Fub25pY2FsaXphdGlv bi4gIEkgcHJlZmVyIGJ5dGVzdHJlYW0gZW5jb2Rpbmcgc3R5bGUgd2hlcmUgdGhlIG9yaWdpbmFs IGNvbnRlbnQgZ29lcyB3aXRoIHRoZSBzaWduYXR1cmUuDQoNCkFub3RoZXIgZXhhbXBsZSBpcyBB VExBUyB3aGljaCBzaWducyBlbmNvZGVkIGh0dHAgcmVxdWVzdHMuDQoNClNvbWUgSlNPTiBmb3Jt YXRzIHdpbGwgaGF2ZSB0aGUgc2FtZSBpc3N1ZXMgdGhhdCBYTUxEU0lHIGhhZC4gIEZvciBleGFt cGxlLCBTQ0lNIHN1cHBvcnRzIG11bHRpcGxlIHdheXMgdG8gaWRlbnRmaXkgYXR0cmlidXRlcyBt dWNoIGxpa2UgWE1MIChpdCB1c2VzIElBTkEgcmVnaXN0ZXJlZCBzY2hlbWFzKS4gWW91IGNhbiBy ZWZlcmVuY2UgYW4gYXR0cmlidXRlIHdpdGggdGhlIGZ1bGwgcGF0aCBvciBqdXN0IGl0cyBuYW1l LiAgV2UgdHJpZWQgdG8gYXZvaWQgc2NoZW1hcywgYnV0IGxvY2FsaXplZCBleHRlbnNpYmlsaXR5 IGFuZCBlYXN5IG9mIGNvZGluZyBmb3JjZWQgdXMgdG8gZG8gdGhpcy4gIFNvIGZvciBTQ0lNIGl0 IGlzIGVhc2llciB0byBjYW5vbmljYWxpemUgdGhhbiBYTUwsIGJ1dCBJIHdvdWxkIG5vdCBzYXkg c2ltcGxlLg0KDQpJbiB0aGUgZW5kLCBJIGZlbHQgaXQgd2FzIGEgZ29vZCB0cmFkZS1vZmYgYmVj YXVzZSBvZiBhbiBhc3N1bXB0aW9uIHRvIHNpZ24gZW5jb2RlZCBqc29uIGRhdGEgaW5zdGVhZC4N Cg0KTm90ZTogIFNDSU0gZG9lcyBub3QgeWV0IGhhdmUgYSBzaWduZWQgZm9ybWF0LiBJIGFudGlj aXBhdGUgaG93ZXZlciB0aGUgZGV2ZWxvcG1lbnQgb2Ygc2lnbmVkIFNDSU0gZXZlbnRzIHBlciB0 aGUgbmV3IFNFVCBzcGVjLg0KDQpJZiB5b3Ugd2VyZSB0byBwcm9jZWVkLCBJIHdvdWxkIHJlY29t bWVuZCBpbmNsdWRpbmcgY29uc2lkZXJhdGlvbnMgaWRlbnRpZnlpbmcgSlNPTiBmb3JtYXRzIG5v dCB3ZWxsIHN1aXRlZCB0byBjYW5vbmljYWxpemF0aW9uLg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jw b3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRp ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KT24g T2N0IDExLCAyMDE4LCBhdCAxMTowNiBBTSwgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbT4+IHdyb3RlOg0KDQpIaSBCcmV0LA0KDQpKT1NFIGlzIGNsb3NlZCwgc28gYSBuZXcgV0cg d291bGQgaGF2ZSB0byBiZSBmb3JtZWQgaWYgdGhpcyB3ZXJlIHRvIGJlIGRvbmUgaW4gYSBXRy4g IFRoYXQgbWlnaHQgYmUgcmVvcGVuaW5nIEpPU0Ugb3Igc29tZXRoaW5nIGVsc2UuICBBbm90aGVy IHBvc3NpYmlsaXR5IGlzIGZvciBKYW1lcyB0byB0cnkgdG8gcHJvZ3Jlc3MgaGlzIGV4aXN0aW5n IGRyYWZ0IGFuZCBkZXRlcm1pbmUgaW50ZXJlc3QuICBIYXMgaXQgYmVlbiBwcmVzZW50ZWQgYXQg U2VjRGlzcGF0Y2ggeWV0IHRvIGdhdWdlIGludGVyZXN0IGFuZCB1bmNvdmVyIHByb2JsZW1zPw0K DQpZb3UgY291bGQgYWxzbyBjb25zaWRlciBhbHRlcm5hdGUgc29sdXRpb25zLiAgVGhlIHByb2Js ZW1zIGNpdGVkIHdlcmUgcHJvYmxlbXMgd2l0aCBYTUwgYWxyZWFkeS4gIFNpbmNlIFJJRCBkZWZp bmVkIHRoZSBzYW1lIGNhcGFiaWxpdHksIHlvdSBjb3VsZCB0ZXN0IG91dCBpbnRlcm9wZXJhYmls aXR5IHVzaW5nIFJJRCBpbiBYTUwgbW9yZSBleHRlbnNpdmVseSBhcyB5b3UnZCBiZSBtYXBwaW5n IHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgaW50byBKU09OLiAgVGhpcyB3b3VsZCBnaXZlIHlvdSBp biB5b3VyIG5ldyBlZmZvcnQgZmVlZGJhY2sgaW50byBkZXNpZ24gY29uc2lkZXJhdGlvbnMgYW5k IGhlbHAgeW91IGRldGVybWluZSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZ28gdGhpcyByb3V0ZSBv ciBwZXJoYXBzIHNvbWUgb3RoZXIgc29sdXRpb24gbWF5IGJlIHByZWZlcnJlZCAoc2VlIE5laWwn cyBtZXNzYWdlKS4gIEluIGFueSBjYXNlLCBtb3JlIHdvcmsgc2hvdWxkIGJlIGRvbmUgYmVmb3Jl IGEgbmV3IFdHIGFyb3VuZCBjYW5vbmljYWxpemF0aW9uIGlzIHBlcmZvcm1lZCBJTU8sIGJ1dCBJ IGFtIGFsc28gbm8gbG9uZ2VyIGFuIEFELCBzbyBhZHZpY2UgZnJvbSBjdXJyZW50IG9uZXMgbWF5 IHZhcnkgOi0pDQoNCkJlc3QsDQpLYXRobGVlbg0KDQpPbiBUaHUsIE9jdCAxMSwgMjAxOCBhdCAx OjI0IFBNIEJyZXQgSm9yZGFuIDxqb3JkYW4uaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpvcmRhbi5p ZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KS2F0aGxlZW4sDQoNCkZyb20geW91ciBjb21tZW50cyBJ IHRha2UgaXQgaXMgb2theSB0aGVuIHRvIGRvIGEgZHJhZnQgcHJvcG9zYWwgaW4gYW5vdGhlciBX RyBhbmQgdGhlbiBoYXZlIHRoaXMgbWFpbGluZyBsaXN0IHJldmlldyBpdD8gIFdvdWxkIHdlIHRo ZW4gcmVzdGFydCBKT1NFIGlmIHRoZSBkcmFmdCB3YXMgZ29vZCB0byBoYXZlIGl0IHN0YW5kYXJk aXplZCBpbiBKT1NFIG9yIGp1c3Qgc29tZSBvdGhlciBXRz8NCg0KSSBqdXN0IHdhbnQgdG8gYmUg c2Vuc2l0aXZlIHRvIHRoZSB3b3JrIHRoYXQgaGFzIGFscmVhZHkgYmVlbiBkb25lIGFuZCBidWls ZCBvbiBpdC4gIEkgYWxzbyBkbyBub3Qgd2FudCB0byBkbyB0aGluZ3MgdGhhdCBhcmUg4oCcYmFk IGZvcm3igJ0uICBXZSBhcmUgYWxsIGluIHRoaXMgYm9hdCB0b2dldGhlciwgYW5kIEkganVzdCB3 YW50IHRvIHdvcmsgd2l0aCBldmVyeW9uZSB0byByb3cgaW4gdGhlIHNhbWUgZGlyZWN0aW9uLg0K DQpCVFcsIEkgaGF2ZSBzcG9rZW4gd2l0aCBhIGZldyBvdGhlciB2ZW5kb3JzIGFuZCBzZXJ2aWNl IHByb3ZpZGVycyBhbmQgdGhleSBhcmUgYWxzbyB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhpcyB3b3Jr IGFzIGl0IHdvdWxkIHNvbHZlIGEgbG90IG9mIHByb2JsZW1zIHRoZXkgaGF2ZSBvciBhcmUgc2Vl aW5nLg0KDQpUaGFua3MsDQpCcmV0DQpQR1AgRmluZ2VycHJpbnQ6IDYzQjQgRkM1MyA2ODBBIDZC N0QgMTQ0NyAgRjJDMCA3NEY4IEFDQUUgNzQxNSAwMDUwDQoiV2l0aG91dCBjcnlwdG9ncmFwaHkg dmlodiB2aXZjIGNlIHhocm5ydywgaG93ZXZlciwgdGhlIG9ubHkgdGhpbmcgdGhhdCBjYW4gbm90 IGJlIHVuc2NyYW1ibGVkIGlzIGFuIGVnZy4iDQoNCg0KT24gT2N0IDEwLCAyMDE4LCBhdCA3OjQ3 IFBNLCBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkJyZXQs DQoNCllvdSBjb3VsZCBkZWZpbmUgaXQgd2l0aGluIGEgZHJhZnQgaW4gYSBkaWZmZXJlbnQgd29y a2luZyBncm91cCBvdGhlciB0aGFuIEpPU0UgYW5kIGFzayBmb3IgcmV2aWV3ZXJzIGZyb20gSk9T RSB0byByZXZpZXcgYW5kIGNvbW1lbnQgdG8gY2F0Y2ggcHJvYmxlbXMuICBBbHRob3VnaCBhbHJl YWR5IGRlc2NyaWJlZCBhYm92ZSwgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHRoaXMgYW5kIEpTT04s IHdoaWNoIGlzIHdoeSB0aGUgV0cgZGlkbid0IHdhbnQgdG8gZG8gY2Fub25pY2FsaXphdGlvbi4N Cg0KSSdtIGFzc3VtaW5nIHlvdSB3YW50IHRvIGRvIGJhc2ljYWxseSB3aGF0IHdhcyBkb25lIGZv ciBSSUQgaW4gWE1MIHVzaW5nIEpTT04uICBZb3UgbWF5IHdhbnQgdG8gbG9vayBhdCB0aGUgc2V0 IG9mIHBvc3NpYmlsaXRpZXMgdG8gcmVwbGljYXRlIGFzIHRoZXkgYXJlIGFsbCBsaWtlbHkgbmVl ZGVkIHdpdGggd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkbyBvciBqdXN0IGFzIHBhcnQgb2YgeW91 ciBnYXAgYW5hbHlzaXMuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTQ1I3Nl Y3Rpb24tOS4xPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM2NTQ1LTIzc2VjdGlvbi0yRDkuMSZkPUR3TUZh USZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09TU1vMTJiNDhCNkdxdktkeThl QnpINlpBTU11ZTlYU3JTalNmd2pIbnFrUSZzPTIydTlORXJVMG96QzUtTWZjZ2pyeUdjZGVHVF9Y NXQ5T0NTU1l0dlktYTAmZT0+DQpBbHNvIGxvb2sgYXQgOS4zLjEgYW5kIDkuMy4yIGFzIHlvdSdy ZSBsaWtlbHkgdG8gYWxzbyBuZWVkIG11bHRpLWhvcCBhdXRoZW50aWNhdGlvbiB0b28uDQoNClRv IERhdmlkJ3MgcG9pbnQgaW4gdGhlIG1lc3NhZ2UgdGhhdCBmb2xsb3dzIHRoaXMgKGNhbWUgaW4g d2hpbGUgdHlwaW5nKSwgUklEIHNpZ25lZCBwb3J0aW9ucyBvZiB0aGUgbWVzc2FnZSB0byBlbmFi bGUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgeW91IGFyZSBsaWtlbHkgdG8gbmVlZCB0byBkbyB2ZXJ5 IHNpbWlsYXIgdGhpbmdzIHRoYXQgYXJlIGRlc2NyaWJlZCBpbiBSSUQgcmVsYXRlZCB0byB0aGUg cG9saWN5IHdvcmsgSSBoYWQgcHJldmlvdXNseSBtZW50aW9uZWQgZm9yIHlvdXIgZ2FwIGFuYWx5 c2lzIGFzIGJlaW5nIHNpbWlsYXIgZnVuY3Rpb25hbGl0eS4gIElmIHlvdSBoYXZlbid0IGxvb2tl ZCBhdCB0aGF0IHBhcnQgb2YgdGhlIGRvY3VtZW50LCBJIHRoaW5rIGl0IHdpbGwgYmUgaGVscGZ1 bC4NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg0KDQoNCk9uIFdlZCwgT2N0IDEwLCAyMDE4 IGF0IDg6MjkgUE0gTWFuZ2VyLCBKYW1lcyA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4+IHdyb3RlOg0KaHR0cHM6 Ly90b29scy4uaWV0Zi5vcmcvaHRtbC9kcmFmdC1ydW5kZ3Jlbi1qc29uLWNhbm9uaWNhbGl6YXRp b24tc2NoZW1lPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRHJ1bmRncmVuLTJEanNvbi0yRGNhbm9u aWNhbGl6YXRpb24tMkRzY2hlbWUmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZtPU1NbzEyYjQ4QjZHcXZLZHk4ZUJ6SDZaQU1NdWU5WFNyU2pTZndqSG5xa1Emcz1z WnE5VHYxLXIyUkxFa1ZSNTB0WGtNTmRGaTZuT21xV21Fa3VOYmRUSmlvJmU9Pg0KaXMgYSBkZWNl bnQgYXR0ZW1wdCBhdCBKU09OIGNhbm9uaWNhbGl6YXRpb24gKGFuZCBhbiBhcHBlbmRpeCBsaXN0 cyBhIGZldyBvdGhlciBhdHRlbXB0cykuDQpUaGlzIG9uZSBzb3J0cyBvYmplY3QgbWVtYmVycyBi YXNlZCBvbiB0aGVpciBVVEYtMTYgZW5jb2RpbmcgKHdpdGhvdXQgZXNjYXBlcyksIGFuZCBhc3N1 bWVzIGRvdWJsZSBwcmVjaXNpb24gZmxvYXRzIGlzIHRoZSBtb2RlbCBmb3IgbnVtYmVycy4NCg0K LS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBqb3NlIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQnJldCBKb3Jk YW4NClNlbnQ6IFRodXJzZGF5LCAxMSBPY3RvYmVyIDIwMTggMTE6MDIgQU0NClRvOiBKaW0gU2No YWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29t Pj4NCkNjOiBOYXRoYW5pZWwgTWNDYWxsdW0gPG5wbWNjYWxsdW1AcmVkaGF0LmNvbTxtYWlsdG86 bnBtY2NhbGx1bUByZWRoYXQuY29tPj47IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdIENhbm9uaWNhbCBKU09OIGZvcm0NCg0KDQpPdGhlciBp bXBsZW1lbnRhdGlvbnMgc2F5IHRoYXQgeW91IHNob3VsZCBwcmVzZXJ2ZXIgdGhlIG9yZGVyIG9m IHRoZSBmaWVsZHMgeW91IHJlYWQgd2hlbiBzZXJpYWxpemVkIHdoaWNoIGlzIHBhcnQgb2YgSlNP TiBmb3IgdGhlIGJyb3dzZXIgaW1wbGVtZW50YXRpb25zIGJ1dCBub3QgbmVjZXNzYXJpbHkgZWxz ZXdoZXJlLg0KDQpQcmVzZXJ2aW5nIG9yZGVyIGlzIGhhcmQuICBEZXBlbmRpbmcgb24geW91ciBw cm9ncmFtbWluZyBsYW5ndWFnZSB5b3UgbWlnaHQgYmUgZGVzZXJpYWxpemluZyB0aGUgY29udGVu dCBpbiB0byBhIHN0cnVjdCBvciB5b3UgbWF5IGJlIHVzaW5nIGEgbWFwLg0KDQpXaGF0IEkgbmVl ZCBpcyBhIHdheSBmb3IgaW5kaXZpZHVhbHMgYW5kIG9yZ2FuaXphdGlvbnMgdG8gYmUgYWJsZSB0 byBwYXNzIGFyb3VuZCBhbmQgc2hhcmUgSlNPTiBkYXRhIGFuZCBjb2xsYWJvcmF0aXZlbHkgd29y ayBvbiB0aGF0IEpTT04gZGF0YSBhbmQgc2lnbiB0aGUgcGFydHMgdGhhdCB0aGV5IGhhdmUgZG9u ZS4NCg0KDQoNClRoYW5rcywNCkJyZXQNClBHUCBGaW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEg NkI3RCAxNDQ3ICBGMkMwIDc0RjggQUNBRSA3NDE1IDAwNTANCiJXaXRob3V0IGNyeXB0b2dyYXBo eSB2aWh2IHZpdmMgY2UgeGhybnJ3LCBob3dldmVyLCB0aGUgb25seSB0aGluZyB0aGF0IGNhbiBu b3QgYmUgdW5zY3JhbWJsZWQgaXMgYW4gZWdnLiINCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5v cmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2U8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19qb3NlJmQ9RHdNRmFRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFX Tnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1NTW8xMmI0OEI2R3F2S2R5OGVCekg2WkFN TXVlOVhTclNqU2Z3akhucWtRJnM9NjhlcGhsbXVkVUVWRi05RUU3MGh1Q2JoQ1daTXRaRkxoUXdt dW5rWGNiYyZlPT4NCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0KDQoNCg0KLS0N Cg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWls dG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYuLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2pvc2UmZD1Ed0lD QWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPU1NbzEyYjQ4QjZHcXZLZHk4 ZUJ6SDZaQU1NdWU5WFNyU2pTZndqSG5xa1Emcz02OGVwaGxtdWRVRVZGLTlFRTcwaHVDYmhDV1pN dFpGTGhRd211bmtYY2JjJmU9PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fam9zZSZkPUR3SUNB ZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09TU1vMTJiNDhCNkdxdktkeThl QnpINlpBTU11ZTlYU3JTalNmd2pIbnFrUSZzPTY4ZXBobG11ZFVFVkYtOUVFNzBodUNiaENXWk10 WkZMaFF3bXVua1hjYmMmZT0+DQoNCg== --_000_LEXPR01MB108728E1534F022A779A9883EDE10LEXPR01MB1087DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt c3R5bGUtc3Bhbjt9DQpzcGFuLm0tNzgwODc2NTk4MDkwODI3NDA0OWFwcGxlLXN0eWxlLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6bV8tNzgwODc2NTk4MDkwODI3NDA0OWFwcGxlLXN0eWxlLXNwYW47 fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29u dmVydGVkLXNwYWNlO30NCnNwYW4ubS03ODA4NzY1OTgwOTA4Mjc0MDQ5bS0zNTc5MjI4MTYxNDUy ODg2OTkzYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTptXy03ODA4NzY1OTgwOTA4 Mjc0MDQ5bV8tMzU3OTIyODE2MTQ1Mjg4Njk5M2FwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdmVyeSBtdWNoIGFncmVlIHdpdGgg UGhpbC4gWG1sZHNpZyB3YXMgYSBwYWluIGZvciBkZXZlbG9wZXJzLCBsaWJyYXJpZXMgZGlkIGl0 IGRpZmZlcmVudGx5IHRodXMgY2F1c2luZyBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5Kb3NlIHdhcyBkZXNpZ25lZCBzaW1wbGUgYnV0IGEgY2Fub25pY2FsIEpT T04gZm9ybSBpbnRyb2R1Y2VzIG5ldyBjb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBo YWQgdGhlIHNhbWUgd2l0aCBPYXV0aDEg4oCTIGRldmVsb3BlcnMgd2VyZSBub3QgYWJsZSB0byBz b3J0IHRoZSBVUkwgcGFyYW1ldGVycyBhY2NvcmRpbmcgdG8gdGhlIHNwZWMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlNvIGpvc2UgaXMgYmV0dGVyIG9mZiB3aXRob3V0IGNhbm9uaWNhbCBKU09OLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Ly9BeGVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g am9zZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IERvbm5lcnN0YWcsIDExLiBPa3RvYmVyIDIwMTgg MjA6MjM8YnI+DQo8Yj5Ubzo8L2I+IEthdGhsZWVuIE1vcmlhcnR5ICZsdDtrYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hbmdlciwgSmFtZXMgJmx0 O0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20mZ3Q7OyBqb3NlQGlldGYub3JnOyBCcmV0 IEpvcmRhbiAmbHQ7am9yZGFuLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2pvc2VdIENhbm9uaWNhbCBKU09OIGZvcm08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzdXJlIG9mIHRoZSB2YWx1ZSBvZiBjYW5v bmljYWxpemF0aW9uLiAmbmJzcDtJIHByZWZlciBieXRlc3RyZWFtIGVuY29kaW5nIHN0eWxlIHdo ZXJlIHRoZSBvcmlnaW5hbCBjb250ZW50IGdvZXMgd2l0aCB0aGUgc2lnbmF0dXJlLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBleGFtcGxlIGlz IEFUTEFTIHdoaWNoIHNpZ25zIGVuY29kZWQgaHR0cCByZXF1ZXN0cy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBKU09OIGZvcm1hdHMg d2lsbCBoYXZlIHRoZSBzYW1lIGlzc3VlcyB0aGF0IFhNTERTSUcgaGFkLiAmbmJzcDtGb3IgZXhh bXBsZSwgU0NJTSBzdXBwb3J0cyBtdWx0aXBsZSB3YXlzIHRvIGlkZW50Zml5IGF0dHJpYnV0ZXMg bXVjaCBsaWtlIFhNTCAoaXQgdXNlcyBJQU5BIHJlZ2lzdGVyZWQgc2NoZW1hcykuIFlvdSBjYW4g cmVmZXJlbmNlIGFuIGF0dHJpYnV0ZSB3aXRoIHRoZSBmdWxsIHBhdGggb3IganVzdCBpdHMNCiBu YW1lLiAmbmJzcDtXZSB0cmllZCB0byBhdm9pZCBzY2hlbWFzLCBidXQgbG9jYWxpemVkIGV4dGVu c2liaWxpdHkgYW5kIGVhc3kgb2YgY29kaW5nIGZvcmNlZCB1cyB0byBkbyB0aGlzLiAmbmJzcDtT byBmb3IgU0NJTSBpdCBpcyBlYXNpZXIgdG8gY2Fub25pY2FsaXplIHRoYW4gWE1MLCBidXQgSSB3 b3VsZCBub3Qgc2F5IHNpbXBsZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgZW5kLCBJIGZlbHQgaXQgd2Fz IGEgZ29vZCB0cmFkZS1vZmYgYmVjYXVzZSBvZiBhbiBhc3N1bXB0aW9uIHRvIHNpZ24gZW5jb2Rl ZCBqc29uIGRhdGEgaW5zdGVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlOiAmbmJzcDtTQ0lNIGRvZXMgbm90IHlldCBo YXZlIGEgc2lnbmVkIGZvcm1hdC4gSSBhbnRpY2lwYXRlIGhvd2V2ZXIgdGhlIGRldmVsb3BtZW50 IG9mIHNpZ25lZCBTQ0lNIGV2ZW50cyBwZXIgdGhlIG5ldyBTRVQgc3BlYy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IHdlcmUgdG8g cHJvY2VlZCwgSSB3b3VsZCByZWNvbW1lbmQgaW5jbHVkaW5nIGNvbnNpZGVyYXRpb25zIGlkZW50 aWZ5aW5nIEpTT04gZm9ybWF0cyBub3Qgd2VsbCBzdWl0ZWQgdG8gY2Fub25pY2FsaXphdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRp dHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5A aW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMTEsIDIwMTgsIGF0 IDExOjA2IEFNLCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgQnJldCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Sk9TRSBpcyBjbG9zZWQsIHNvIGEgbmV3IFdHIHdvdWxkIGhhdmUgdG8g YmUgZm9ybWVkIGlmIHRoaXMgd2VyZSB0byBiZSBkb25lIGluIGEgV0cuJm5ic3A7IFRoYXQgbWln aHQgYmUgcmVvcGVuaW5nIEpPU0Ugb3Igc29tZXRoaW5nIGVsc2UuJm5ic3A7IEFub3RoZXIgcG9z c2liaWxpdHkgaXMgZm9yIEphbWVzIHRvDQogdHJ5IHRvIHByb2dyZXNzIGhpcyBleGlzdGluZyBk cmFmdCBhbmQgZGV0ZXJtaW5lIGludGVyZXN0LiZuYnNwOyBIYXMgaXQgYmVlbiBwcmVzZW50ZWQg YXQgU2VjRGlzcGF0Y2ggeWV0IHRvIGdhdWdlIGludGVyZXN0IGFuZCB1bmNvdmVyIHByb2JsZW1z PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBjb3Vs ZCBhbHNvIGNvbnNpZGVyIGFsdGVybmF0ZSBzb2x1dGlvbnMuJm5ic3A7IFRoZSBwcm9ibGVtcyBj aXRlZCB3ZXJlIHByb2JsZW1zIHdpdGggWE1MIGFscmVhZHkuJm5ic3A7IFNpbmNlIFJJRCBkZWZp bmVkIHRoZSBzYW1lIGNhcGFiaWxpdHksIHlvdSBjb3VsZCB0ZXN0IG91dCBpbnRlcm9wZXJhYmls aXR5DQogdXNpbmcgUklEIGluIFhNTCBtb3JlIGV4dGVuc2l2ZWx5IGFzIHlvdSdkIGJlIG1hcHBp bmcgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBpbnRvIEpTT04uJm5ic3A7IFRoaXMgd291bGQgZ2l2 ZSB5b3UgaW4geW91ciBuZXcgZWZmb3J0IGZlZWRiYWNrIGludG8gZGVzaWduIGNvbnNpZGVyYXRp b25zIGFuZCBoZWxwIHlvdSBkZXRlcm1pbmUgaWYgeW91IHJlYWxseSB3YW50IHRvIGdvIHRoaXMg cm91dGUgb3IgcGVyaGFwcyBzb21lIG90aGVyIHNvbHV0aW9uIG1heQ0KIGJlIHByZWZlcnJlZCAo c2VlIE5laWwncyBtZXNzYWdlKS4mbmJzcDsgSW4gYW55IGNhc2UsIG1vcmUgd29yayBzaG91bGQg YmUgZG9uZSBiZWZvcmUgYSBuZXcgV0cgYXJvdW5kIGNhbm9uaWNhbGl6YXRpb24gaXMgcGVyZm9y bWVkIElNTywgYnV0IEkgYW0gYWxzbyBubyBsb25nZXIgYW4gQUQsIHNvIGFkdmljZSBmcm9tIGN1 cnJlbnQgb25lcyBtYXkgdmFyeSA6LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkthdGhsZWVuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5PbiBUaHUsIE9jdCAxMSwgMjAxOCBhdCAxOjI0IFBNIEJyZXQgSm9yZGFu ICZsdDs8YSBocmVmPSJtYWlsdG86am9yZGFuLmlldGZAZ21haWwuY29tIj5qb3JkYW4uaWV0ZkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkthdGhsZWVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tIHlv dXIgY29tbWVudHMgSSB0YWtlIGl0IGlzIG9rYXkgdGhlbiB0byBkbyBhIGRyYWZ0IHByb3Bvc2Fs IGluIGFub3RoZXIgV0cgYW5kIHRoZW4gaGF2ZSB0aGlzIG1haWxpbmcgbGlzdCByZXZpZXcgaXQ/ Jm5ic3A7IFdvdWxkIHdlIHRoZW4gcmVzdGFydCBKT1NFIGlmIHRoZSBkcmFmdCB3YXMgZ29vZA0K IHRvIGhhdmUgaXQgc3RhbmRhcmRpemVkIGluIEpPU0Ugb3IganVzdCBzb21lIG90aGVyIFdHPyAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGp1 c3Qgd2FudCB0byBiZSBzZW5zaXRpdmUgdG8gdGhlIHdvcmsgdGhhdCBoYXMgYWxyZWFkeSBiZWVu IGRvbmUgYW5kIGJ1aWxkIG9uIGl0LiZuYnNwOyBJIGFsc28gZG8gbm90IHdhbnQgdG8gZG8gdGhp bmdzIHRoYXQgYXJlIOKAnGJhZCBmb3Jt4oCdLiZuYnNwOyBXZSBhcmUgYWxsIGluIHRoaXMgYm9h dCB0b2dldGhlciwNCiBhbmQgSSBqdXN0IHdhbnQgdG8gd29yayB3aXRoIGV2ZXJ5b25lIHRvIHJv dyBpbiB0aGUgc2FtZSBkaXJlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+QlRXLCBJIGhhdmUgc3Bva2VuIHdpdGggYSBmZXcgb3RoZXIgdmVuZG9y cyBhbmQgc2VydmljZSBwcm92aWRlcnMgYW5kIHRoZXkgYXJlIGFsc28gdmVyeSBpbnRlcmVzdGVk IGluIHRoaXMgd29yayBhcyBpdCB3b3VsZCBzb2x2ZSBhIGxvdCBvZiBwcm9ibGVtcyB0aGV5IGhh dmUgb3IgYXJlIHNlZWluZy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0ibS03ODA4NzY1OTgwOTA4Mjc0MDQ5YXBwbGUtc3R5bGUtc3BhbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0ibS03ODA4NzY1OTgwOTA4Mjc0MDQ5YXBwbGUtc3R5bGUtc3BhbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkJyZXQ8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzdDN0M3QyI+ UEdQIEZpbmdlcnByaW50OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJzcDtGMkMw IDc0RjggQUNBRSA3NDE1IDAwNTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3QzdDN0MiPiZxdW90O1dpdGhvdXQgY3J5cHRvZ3JhcGh5IHZpaHYgdml2 YyBjZSB4aHJucncsIGhvd2V2ZXIsIHRoZSBvbmx5IHRoaW5nIHRoYXQgY2FuIG5vdCBiZSB1bnNj cmFtYmxlZCBpcyBhbiBlZ2cuJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBPY3QgMTAsIDIwMTgsIGF0IDc6NDcg UE0sIEthdGhsZWVuIE1vcmlhcnR5ICZsdDs8YSBocmVmPSJtYWlsdG86a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+QnJldCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+WW91IGNvdWxkIGRlZmluZSBpdCB3aXRoaW4gYSBkcmFmdCBpbiBhIGRpZmZlcmVudCB3b3Jr aW5nIGdyb3VwIG90aGVyIHRoYW4gSk9TRSBhbmQgYXNrIGZvciByZXZpZXdlcnMgZnJvbSBKT1NF IHRvIHJldmlldyBhbmQgY29tbWVudCB0byBjYXRjaCBwcm9ibGVtcy4mbmJzcDsgQWx0aG91Z2gg YWxyZWFkeQ0KIGRlc2NyaWJlZCBhYm92ZSwgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHRoaXMgYW5k IEpTT04sIHdoaWNoIGlzIHdoeSB0aGUgV0cgZGlkbid0IHdhbnQgdG8gZG8gY2Fub25pY2FsaXph dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JJ20g YXNzdW1pbmcgeW91IHdhbnQgdG8gZG8gYmFzaWNhbGx5IHdoYXQgd2FzIGRvbmUgZm9yIFJJRCBp biBYTUwgdXNpbmcgSlNPTi4mbmJzcDsgWW91IG1heSB3YW50IHRvIGxvb2sgYXQgdGhlIHNldCBv ZiBwb3NzaWJpbGl0aWVzIHRvIHJlcGxpY2F0ZSBhcyB0aGV5IGFyZSBhbGwgbGlrZWx5IG5lZWRl ZA0KIHdpdGggd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkbyBvciBqdXN0IGFzIHBhcnQgb2YgeW91 ciBnYXAgYW5hbHlzaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzY1NDUtMjNzZWN0aW9uLTJEOS4xJmFt cDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1w O209TU1vMTJiNDhCNkdxdktkeThlQnpINlpBTU11ZTlYU3JTalNmd2pIbnFrUSZhbXA7cz0yMnU5 TkVyVTBvekM1LU1mY2dqcnlHY2RlR1RfWDV0OU9DU1NZdHZZLWEwJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTQ1I3NlY3Rpb24tOS4xPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsc28gbG9vayBhdCA5LjMuMSBhbmQgOS4zLjIgYXMgeW91 J3JlIGxpa2VseSB0byBhbHNvIG5lZWQgbXVsdGktaG9wIGF1dGhlbnRpY2F0aW9uIHRvby48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UbyBEYXZpZCdzIHBv aW50IGluIHRoZSBtZXNzYWdlIHRoYXQgZm9sbG93cyB0aGlzIChjYW1lIGluIHdoaWxlIHR5cGlu ZyksIFJJRCBzaWduZWQgcG9ydGlvbnMgb2YgdGhlIG1lc3NhZ2UgdG8gZW5hYmxlIGludGVyb3Bl cmFiaWxpdHkgYW5kIHlvdSBhcmUgbGlrZWx5IHRvIG5lZWQgdG8gZG8gdmVyeQ0KIHNpbWlsYXIg dGhpbmdzIHRoYXQgYXJlIGRlc2NyaWJlZCBpbiBSSUQgcmVsYXRlZCB0byB0aGUgcG9saWN5IHdv cmsgSSBoYWQgcHJldmlvdXNseSBtZW50aW9uZWQgZm9yIHlvdXIgZ2FwIGFuYWx5c2lzIGFzIGJl aW5nIHNpbWlsYXIgZnVuY3Rpb25hbGl0eS4mbmJzcDsgSWYgeW91IGhhdmVuJ3QgbG9va2VkIGF0 IHRoYXQgcGFydCBvZiB0aGUgZG9jdW1lbnQsIEkgdGhpbmsgaXQgd2lsbCBiZSBoZWxwZnVsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5LYXRobGVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gV2VkLCBPY3QgMTAsIDIwMTggYXQgODoyOSBQ TSBNYW5nZXIsIEphbWVzICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50 ZWxzdHJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2Ry YWZ0LTJEcnVuZGdyZW4tMkRqc29uLTJEY2Fub25pY2FsaXphdGlvbi0yRHNjaGVtZSZhbXA7ZD1E d01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZh bXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPU1N bzEyYjQ4QjZHcXZLZHk4ZUJ6SDZaQU1NdWU5WFNyU2pTZndqSG5xa1EmYW1wO3M9c1pxOVR2MS1y MlJMRWtWUjUwdFhrTU5kRmk2bk9tcVdtRWt1TmJkVEppbyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3Rvb2xzLi5pZXRmLm9yZy9odG1sL2RyYWZ0LXJ1bmRncmVuLWpzb24tY2Fub25p Y2FsaXphdGlvbi1zY2hlbWU8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXMgYSBkZWNlbnQgYXR0ZW1wdCBh dCBKU09OIGNhbm9uaWNhbGl6YXRpb24gKGFuZCBhbiBhcHBlbmRpeCBsaXN0cyBhIGZldyBvdGhl ciBhdHRlbXB0cykuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUFV IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBvbmUgc29ydHMgb2JqZWN0IG1lbWJlcnMg YmFzZWQgb24gdGhlaXIgVVRGLTE2IGVuY29kaW5nICh3aXRob3V0IGVzY2FwZXMpLCBhbmQgYXNz dW1lcw0KIGRvdWJsZSBwcmVjaXNpb24gZmxvYXRzIGlzIHRoZSBtb2RlbCBmb3IgbnVtYmVycy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08L3NwYW4+PHNwYW4g bGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5KYW1lcyBNYW5nZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+am9zZQ0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+QnJldCBKb3JkYW48 YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+VGh1cnNkYXksIDExIE9jdG9iZXIgMjAxOCAxMTowMiBBTTxicj4NCjxiPlRvOjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmltIFNj aGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iIHRhcmdldD0i X2JsYW5rIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk5hdGhhbmllbCBN Y0NhbGx1bSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5wbWNjYWxsdW1AcmVkaGF0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm5wbWNjYWxsdW1AcmVkaGF0LmNvbTwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBb am9zZV0gQ2Fub25pY2FsIEpTT04gZm9ybTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpPdGhlciBpbXBsZW1lbnRhdGlvbnMg c2F5IHRoYXQgeW91IHNob3VsZCBwcmVzZXJ2ZXIgdGhlIG9yZGVyIG9mIHRoZSBmaWVsZHMgeW91 IHJlYWQgd2hlbiBzZXJpYWxpemVkIHdoaWNoIGlzIHBhcnQgb2YgSlNPTiBmb3IgdGhlIGJyb3dz ZXIgaW1wbGVtZW50YXRpb25zIGJ1dCBub3QgbmVjZXNzYXJpbHkgZWxzZXdoZXJlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlByZXNlcnZpbmcgb3JkZXIgaXMgaGFyZC4mbmJzcDsgRGVwZW5kaW5nIG9u IHlvdXIgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgeW91IG1pZ2h0IGJlIGRlc2VyaWFsaXppbmcgdGhl IGNvbnRlbnQNCiBpbiB0byBhIHN0cnVjdCBvciB5b3UgbWF5IGJlIHVzaW5nIGEgbWFwLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgSSBuZWVkIGlzIGEgd2F5IGZvciBpbmRpdmlkdWFs cyBhbmQgb3JnYW5pemF0aW9ucyB0byBiZSBhYmxlIHRvIHBhc3MgYXJvdW5kIGFuZCBzaGFyZSBK U09OIGRhdGENCiBhbmQgY29sbGFib3JhdGl2ZWx5IHdvcmsgb24gdGhhdCBKU09OIGRhdGEgYW5k IHNpZ24gdGhlIHBhcnRzIHRoYXQgdGhleSBoYXZlIGRvbmUuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJtLTc4MDg3NjU5ODA5MDgyNzQwNDltLTM1Nzky MjgxNjE0NTI4ODY5OTNhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rcyw8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGNsYXNzPSJtLTc4MDg3NjU5ODA5MDgyNzQwNDltLTM1NzkyMjgxNjE0NTI4 ODY5OTNhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJy ZXQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzdDN0M3QyI+UEdQIEZpbmdlcnByaW50OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAm bmJzcDtGMkMwIDc0RjggQUNBRSA3NDE1IDAwNTA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3QzdDN0Mi PiZxdW90O1dpdGhvdXQgY3J5cHRvZ3JhcGh5IHZpaHYgdml2YyBjZSB4aHJucncsIGhvd2V2ZXIs IHRoZSBvbmx5IHRoaW5nIHRoYXQgY2FuIG5vdCBiZSB1bnNjcmFtYmxlZA0KIGlzIGFuIGVnZy4m cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQVUi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2pvc2UmYW1wO2Q9RHdNRmFRJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1 RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1NTW8xMmI0OEI2 R3F2S2R5OGVCekg2WkFNTXVlOVhTclNqU2Z3akhucWtRJmFtcDtzPTY4ZXBobG11ZFVFVkYtOUVF NzBodUNiaENXWk10WkZMaFF3bXVua1hjYmMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+LS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkthdGhsZWVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkthdGhsZWVuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWls dG86am9zZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+am9zZUBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fam9zZSZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ Wmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlx UGtBSTFhTGNMTjRLWk5BJmFtcDttPU1NbzEyYjQ4QjZHcXZLZHk4ZUJ6SDZaQU1NdWU5WFNyU2pT ZndqSG5xa1EmYW1wO3M9NjhlcGhsbXVkVUVWRi05RUU3MGh1Q2JoQ1daTXRaRkxoUXdtdW5rWGNi YyZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYuLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2pv c2UmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZhbXA7bT1NTW8xMmI0OEI2R3F2S2R5OGVCekg2WkFNTXVlOVhTclNqU2Z3akhucWtRJmFtcDtz PTY4ZXBobG11ZFVFVkYtOUVFNzBodUNiaENXWk10WkZMaFF3bXVua1hjYmMmYW1wO2U9PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_LEXPR01MB108728E1534F022A779A9883EDE10LEXPR01MB1087DEUP_-- From nobody Thu Oct 11 12:58:53 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD4F130DFC for ; Thu, 11 Oct 2018 12:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DxEg79GWB6A5 for ; Thu, 11 Oct 2018 12:58:51 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 9DFB1124D68 for ; Thu, 11 Oct 2018 12:58:50 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id y11-v6so11005852wrd.4 for ; Thu, 11 Oct 2018 12:58:50 -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=MASfEC0RzRT8Uzqsia3auu9UWot+6hrI442e64aoeGQ=; b=f4Jix2v8W3jlmhJVVERL2DWzP8gCVaggHUHcpqmjBdBq73wQoN+MXAQg/v6S7W5Iba 7FA8w7EHuQ+qWdLCwZ/jKAM8Lljn/cwmlRXDzExAr0r9cYdoCBstuS/MBwaG7EkRF6Hb 0jJogfuraAfBXEMFKEqaXV0EVrRsp2wr4EPRW8KIty/rpcrgQppW4M4Znq86NlYCetFJ /aGBBRoulmtGksmrvrDwykvWBpp6zw66MbQHQc34Y5Erx8lX/pd0u33sS8rXuz09YOtn Ia9+cL5J4kf05LaXp+yHMbzY5UeS0pEAwMlimRj98k0muQ2PbSbPqoJT0P3GGeJulma6 HPVA== 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=MASfEC0RzRT8Uzqsia3auu9UWot+6hrI442e64aoeGQ=; b=eXZlxfzo8NQ2lhAOtVlxj7/SzwB6QSHwbOoQzMSZu8B9gpPiuv9TA6MYhUxwaC1pJN RXIyQSqVucZuH4ok1qJKOrAggmXE9waCczBgYiZfe/5tXX60Dux4Uk/1MnTPIjPJ3sJ4 +bw9gHKcrrZDnsnk0TeLt4INrXU33ub2AEOp9b1kT6Gj2xfI8hh856T0ghX2NijkUYbO u/WJe6RCG7ILT1aw9GlF0zCtvxFEME+5UaattxTnBZZyH5y2FLbYaiUNp9kO4XxemFXJ bkW5DvUui45su0401wucw4jrfrQpMIkfgsOVCZ6jqd459WqDLPbvQ7NnGnAq7grlyQrX fLDg== X-Gm-Message-State: ABuFfogC7n2fg47/SYd1rCuhBfTYcrVgLEgxIvx1YfwA7pv2zysMzexy lR5FT/iVlLmnr8r5fczNFZ1LxF2z X-Google-Smtp-Source: ACcGV63nbvDxpW4VIk2NwXQYgvXcwWk78p1EtUgQpPtRsF0b2EHTCyyvtkverCnwlHMGqCq/BjjedQ== X-Received: by 2002:adf:9f0f:: with SMTP id l15-v6mr2842539wrf.206.1539287928517; Thu, 11 Oct 2018 12:58:48 -0700 (PDT) Received: from [192.168.43.218] (76.19.136.77.rev.sfr.net. [77.136.19.76]) by smtp.googlemail.com with ESMTPSA id u76-v6sm38052272wmd.10.2018.10.11.12.58.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 12:58:47 -0700 (PDT) To: Carsten Bormann , Phil Hunt Cc: Kathleen Moriarty , "Manger, James" , Bret Jordan , jose@ietf.org References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> From: Anders Rundgren Message-ID: <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> Date: Thu, 11 Oct 2018 21:58:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 19:58:53 -0000 Before dismissing Canonical JSON, you may take it for spin at: https://mobilepki.org/jws-jcs/home This particular signature variant is 100% JWS compatible. Although enveloped signatures may be "out of fashion", I find them quite practical since they don't interfere with the message structure. An example: In the IETF TEEP work (building on JOSE), the designers were forced adding an unsigned outer JSON layer in order to get a reasonable system. The idea is not replacing JOSE, only creating a viable alternative for folks who don't want to shroud their precious JSON data in Base64Url! Thanks, Anders From nobody Thu Oct 11 13:05:19 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB00B12785F for ; Thu, 11 Oct 2018 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 spvXq6OTzv4I for ; Thu, 11 Oct 2018 13:05:16 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 3BAFA127333 for ; Thu, 11 Oct 2018 13:05:16 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id e16-v6so4099423ybk.8 for ; Thu, 11 Oct 2018 13:05:16 -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=JBwKOGoTZapvrQAsJLAUhwWrfBGQ1nTs9YnVHFmgjjs=; b=YLmECJqCo7rIgMOhpoRJYSUz9r7Wpu6uU1nkFBmEK++ypR7GWWiFeSCRxWqC6nE7Rt vIUV7H28NEPL3JIU1zEXmSRU/rKyECwOHGAvfqojornCWe0ERP7x2YyXj78qsKx+RmIe bVBwxqNTX29j72Ym2nDKzfZn9j+/ISGTTthk0Sro2321geQLvhXCtz3tzDFMJ5dH87Nc /QXJF3x7xL7bW7UBg7q151FIk4Z7A+WO8w4t3VRBigANMpnTqd0rc+p+SDNRyBVgfpeB tzFWKeQTo9LkhluJwTIlXpBNN1sknfD2AugY/gAU6NTkBzd8RZirCJsJ8MO4BRa/2Y4N E6+w== 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=JBwKOGoTZapvrQAsJLAUhwWrfBGQ1nTs9YnVHFmgjjs=; b=kzCZs7ol7tE/wlb5pQbA5HYFSwV+2jCGzZAwQR69PGkiSqQMFy4NZBmAZBFqwGdxHL AE4+0uKqHP+Upa9oYX5BS1JFbWZ0s6gZFwlk3/StxVqe2P3aYPqE9sgsTXs6Y03EACyU ijBIEpqM+MT+KdSk9OiqwtS9Y/Wkay0p4TXnH/316c7sUkH80eZgqqg2WVttxCEQKAon Ueiw+Jk9QqXBzCzF1hxeBHBu+QdrHhQZTDLFA+WHEWAIe64OwUa0Dt+Mx3goU35k+jCL PJk6WvWyQuobGylU3kT2s2gsoFCXmfv8eh8dnfccp3aHjwNbII0BF0HBZUmBBQFdhE38 2G/A== X-Gm-Message-State: ABuFfoijN+qSCZ+qZNFH/1jiiJNd1M+8sROGRkeNZ4R5JKkXvXZaTKBn iiDY1IcGZ8d9tcscp400Q+Y= X-Google-Smtp-Source: ACcGV61Vlf/WPjyK4xmKzNXrrld81Bmm5GDxglTAtOWyP9YOkv05HIdl6rhGgjIS5So6kVI77RToLQ== X-Received: by 2002:a25:7ec5:: with SMTP id z188-v6mr1739109ybc.250.1539288315415; Thu, 11 Oct 2018 13:05:15 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:b07e:3f9:8bc0:bb28? ([2605:a601:3260:266:b07e:3f9:8bc0:bb28]) by smtp.gmail.com with ESMTPSA id r8-v6sm18342453ywa.56.2018.10.11.13.05.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 13:05:14 -0700 (PDT) From: Bret Jordan Message-Id: <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D1363C1-26C7-484A-9F7A-7AC1CDF6DD70" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 14:05:08 -0600 In-Reply-To: <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> Cc: Carsten Bormann , Phil Hunt , Kathleen Moriarty , "Manger, James" , jose@ietf.org To: Anders Rundgren References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 20:05:19 -0000 --Apple-Mail=_9D1363C1-26C7-484A-9F7A-7AC1CDF6DD70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anders, I really like what you have done with this. I am trying to figure out = if it will work 100% for my needs, or if it will need some tweaking. If = it does work, then I think we should really try and figure out how we = get your work standardized.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 11, 2018, at 1:58 PM, Anders Rundgren = wrote: >=20 > Before dismissing Canonical JSON, you may take it for spin at: > https://mobilepki.org/jws-jcs/home >=20 > This particular signature variant is 100% JWS compatible. >=20 > Although enveloped signatures may be "out of fashion", I find them = quite practical since they don't interfere with the message structure. >=20 > An example: In the IETF TEEP work (building on JOSE), the designers = were forced adding an unsigned outer JSON layer in order to get a = reasonable system. >=20 > The idea is not replacing JOSE, only creating a viable alternative for = folks who don't want to shroud their precious JSON data in Base64Url! >=20 > Thanks, > Anders --Apple-Mail=_9D1363C1-26C7-484A-9F7A-7AC1CDF6DD70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Anders,

I = really like what you have done with this.  I am trying to figure = out if it will work 100% for my needs, or if it will need some tweaking. =  If it does work, then I think we should really try and figure out = how we get your work standardized. 


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 11, 2018, at 1:58 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Before= dismissing Canonical JSON, you may take it for spin at:
https://mobilepki.org/jws-jcs/home

This particular signature variant is 100% JWS compatible.

Although enveloped signatures may be "out of = fashion", I find them quite practical since they don't interfere with = the message structure.

An example: In the = IETF TEEP work (building on JOSE), the designers were forced adding an = unsigned outer JSON layer in order to get a reasonable system.

The idea is not replacing JOSE, only creating = a viable alternative for folks who don't want to shroud their precious = JSON data in Base64Url!

Thanks,
Anders

= --Apple-Mail=_9D1363C1-26C7-484A-9F7A-7AC1CDF6DD70-- From nobody Thu Oct 11 13:45:24 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD912872C for ; Thu, 11 Oct 2018 13:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 QBCPQa5pt2KR for ; Thu, 11 Oct 2018 13:45:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 4F86612785F for ; Thu, 11 Oct 2018 13:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9BKjBJ3029577; Thu, 11 Oct 2018 22:45:16 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42WNJR2671z1Bq8; Thu, 11 Oct 2018 22:45:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> Date: Thu, 11 Oct 2018 22:45:10 +0200 Cc: Phil Hunt , Kathleen Moriarty , "Manger, James" , Bret Jordan , jose@ietf.org X-Mao-Original-Outgoing-Id: 560983508.960245-fd8857ee84e1aa5a359fb969dc901271 Content-Transfer-Encoding: quoted-printable Message-Id: <771C010E-C469-47E9-80B8-EE8F3FBD5272@tzi.org> References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 20:45:24 -0000 On Oct 11, 2018, at 21:58, Anders Rundgren = wrote: >=20 > shroud their precious JSON data in Base64Url I know how to fix this, but that=E2=80=99s a different WG :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 11 14:36:52 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE70E1277BB for ; Thu, 11 Oct 2018 14:36:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 m19ezWA2CbQq for ; Thu, 11 Oct 2018 14:36:49 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 BBD5E127598 for ; Thu, 11 Oct 2018 14:36:48 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id c22-v6so9641084edc.4 for ; Thu, 11 Oct 2018 14:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2qUi2AqFcLd48QiDAiNumuCEE9TZkQRlNoITzUvYJE=; b=N5MHiBT1SNzNak764IKFjL1wXHHM7+NTKnx0UDNIJGRIe5CwW/wxHn9o6GZwUvJz2F rIRv9HUcNimrkM+wtc+Iwruqvxhz3NYpadWfFIKu4WOLtII+DvSkn1OJyqrAGTIU1T2H BAVa11q+iQpjd9QBu1zCDpILBH3SJA3oBBW2zhjccFmpUBZNd/APPUdJGjCh2kyVa1/E MvKhvY9FtKHNuh0ZHk6T2/H9CkM4lP/fUWAZA2JDgzLdW1UMVTrRJrjrvxA8Zhy3Uikx OEZEXUSDhVjYJts3h1ME0EfJAYIW5WRvJRBx0ns0XV/kmhE2z4uKjib/7b7kjmQglasg +J+A== 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=s2qUi2AqFcLd48QiDAiNumuCEE9TZkQRlNoITzUvYJE=; b=dKp1poEgEgnVvOroppflSCLDpcFlMYt8i3KCFfaslfU9hep96B/pk+Tpr3wEI2kCEC Ay/k4YZ11Bfwt45YMcEKuVgYaETrZ/kkbgJIT6UL3MxecfaHO2xqO2FAJCFaXptEoRVN 6fSQRSZOp2eyM5ye4VZrGchNcMllrb4AsR3tcQVm3mnLak82Be1ToeudzUDOlDOugjNV T4WojgIjSiucaSafXLD7mpOr4wPnmQ/s9Ei17RzEMGNigoyyV0O5SAzZiXE+Zt3F9tKC h36zss43i/DTIhAYTJCSWpxWliU0peRMZUvE6yFSAsTD88eWON5+EDzLowXMzoM6tV17 vU0A== X-Gm-Message-State: ABuFfoiW+u/rsq9x2zEvXzF6BdkjNpkVrxtzwx24xG/0NRbHRokYk9L1 M2yZtWoIpXIr1LsU5tcLTmle9YQTseIssN+kHSp9uQ== X-Google-Smtp-Source: ACcGV62D6ihupR9sw75cDN/x4rglhk1eYXtTx5J7wB6oTbFfyp+7vQ6ejVEW1d88Bpk/LKleK+fBkkPzWF4yyWWJKpg= X-Received: by 2002:a05:6402:786:: with SMTP id d6mr5501990edy.81.1539293807218; Thu, 11 Oct 2018 14:36:47 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <771C010E-C469-47E9-80B8-EE8F3FBD5272@tzi.org> In-Reply-To: <771C010E-C469-47E9-80B8-EE8F3FBD5272@tzi.org> From: Tim Bray Date: Thu, 11 Oct 2018 14:36:34 -0700 Message-ID: To: Carsten Bormann Cc: Anders Rundgren , Kathleen Moriarty , "Manger, James" , jose@ietf.org, Bret Jordan , Phil Hunt Content-Type: multipart/alternative; boundary="00000000000095a3270577fac455" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 21:36:51 -0000 --00000000000095a3270577fac455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think quite a few people might benefit from JSON c14n, but the water was poisoned by the hideous XML experience and there's a general reluctance to go anywhere near it. If we saw a really plausible proposal, we could possibly think about rehydrating the JSON WG to look at it. On Thu., Oct. 11, 2018, 1:45 p.m. Carsten Bormann, wrote: > On Oct 11, 2018, at 21:58, Anders Rundgren > wrote: > > > > shroud their precious JSON data in Base64Url > > I know how to fix this, but that=E2=80=99s a different WG :-) > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --00000000000095a3270577fac455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think quite a few people might benefit from JSON c14n, = but the water was poisoned by the hideous XML experience and there's a = general reluctance to go anywhere near it. If we saw a really plausible pro= posal, we could possibly think about rehydrating the JSON WG to look at it.=

On Thu., Oct. 11, 201= 8, 1:45 p.m. Carsten Bormann, <cabo@tzi.= org> wrote:
On Oct 11, 2018,= at 21:58, Anders Rundgren <anders.rundgren.net@gmail.com= > wrote:
>
> shroud their precious JSON data in Base64Url

I know how to fix this, but that=E2=80=99s a different WG :-)

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

_______________________________________________
jose mailing list
jose@= ietf.org
https://www.ietf.org/mailman/listinfo/jose<= br>
--00000000000095a3270577fac455-- From nobody Thu Oct 11 15:23:17 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231BB128766 for ; Thu, 11 Oct 2018 15:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8A1tiFCLCcl2 for ; Thu, 11 Oct 2018 15:23:14 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 55F6F12785F for ; Thu, 11 Oct 2018 15:23:14 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id o63-v6so4247340yba.2 for ; Thu, 11 Oct 2018 15:23:14 -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=cILg6Q9ashVl3xbastAI0u4RHwLatkpwRjgkIlO7dAg=; b=J7XZQcj4iVtJbG29cSp3lL8iAgNz++ao9cn253pFNojcREuYG0ZLB+RqMwYY4wSxrV 7UOwDbGqPn39jkNSbUjmhsDtm9GCmVJ3WCjYlVEQBv9bjihwpSCtboxT1kVeE0PG5PJO CGO2W67+lz/wIpU5YfqwSRVyrXVG3K/hm5UFYoPFFloskhIxd6Pka1VORaRPXLCX1H6Z fhlph5zuOnGvX+Sf+UGpyfCd7SAeDiGjWCY05c8ak2DFsFFXCDkTXRjDdCTojFajYVU5 kmSpTvmj0oyns/sCNdcQXPhCEBYxko2p19zKHxArfAj1FuFdgHghc94xHOaIHHLuZAkL kioQ== 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=cILg6Q9ashVl3xbastAI0u4RHwLatkpwRjgkIlO7dAg=; b=VUIttiuUkK43IRGuee1FnfVN/om1Aakvd5ZEDNXgJrT5E1x88wyDIH7eAcA2n8c9qc Y6zr8exF5575VAsNz6T14WDS9rYFwOyhx1HZDglhLfyXw4EKcVIXMgmmMgFE+MbXROpB 93/cKHkkvBGiObppR4KSDZyKeAnLgdN9u2CLzd5lesLum/92MnQWACiq78bkfoaYSD+R 54beZuNTnI2O1xpdnPKOnSD0We6rL4ueds6Q9DSDAy+c0pnT8EbuLkh6RTE3BjgmNNmn 408bCbOSDm5a0/4r+hbvHYTP+Sxw5fxksGnC+LsHJncee88N/zpa+Vs4PwduhECsIS3F /pFg== X-Gm-Message-State: ABuFfohcbUFBcXCtmGFybBxNm+izMl19gecGK8IETQlHhslRNdJSViuX RsSPD8ORRD4wrJbJ08D7uzk= X-Google-Smtp-Source: ACcGV63xNHqTpRKOVFoSFED4YhWQqhzAx3btrWuQ5MBXfOoLGQmQy06Xfpkhn/hW96UJ6zUxXj1FTw== X-Received: by 2002:a25:d0cc:: with SMTP id h195-v6mr1960905ybg.348.1539296593611; Thu, 11 Oct 2018 15:23:13 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:a165:a6bc:f6cb:dbc6? ([2605:a601:3260:266:a165:a6bc:f6cb:dbc6]) by smtp.gmail.com with ESMTPSA id a207-v6sm9098298ywe.22.2018.10.11.15.23.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 15:23:12 -0700 (PDT) From: Bret Jordan Message-Id: <28C4A7CB-2F5A-49AF-95D0-3FCB7037665F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C5F0B85-E4DF-4625-B9EC-BC65EEBC5D93" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Oct 2018 16:22:38 -0600 In-Reply-To: Cc: Carsten Bormann , Anders Rundgren , Kathleen Moriarty , "Manger, James" , jose@ietf.org, Phil Hunt To: Tim Bray References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <771C010E-C469-47E9-80B8-EE8F3FBD5272@tzi.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 22:23:16 -0000 --Apple-Mail=_7C5F0B85-E4DF-4625-B9EC-BC65EEBC5D93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have a real need for it with some work I am starting here in the IETF = and work I am doing in other SDOs. So I would love to figure out how to = kickstart this work back to life. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 11, 2018, at 3:36 PM, Tim Bray wrote: >=20 > I think quite a few people might benefit from JSON c14n, but the water = was poisoned by the hideous XML experience and there's a general = reluctance to go anywhere near it. If we saw a really plausible = proposal, we could possibly think about rehydrating the JSON WG to look = at it. >=20 > On Thu., Oct. 11, 2018, 1:45 p.m. Carsten Bormann, > wrote: > On Oct 11, 2018, at 21:58, Anders Rundgren = > = wrote: > >=20 > > shroud their precious JSON data in Base64Url >=20 > I know how to fix this, but that=E2=80=99s a different WG :-) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = --Apple-Mail=_7C5F0B85-E4DF-4625-B9EC-BC65EEBC5D93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = have a real need for it with some work I am starting here in the IETF = and work I am doing in other SDOs.  So I would love to figure out = how to kickstart this work back to life.


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 11, 2018, at 3:36 PM, Tim Bray <tbray@textuality.com> wrote:

I think quite a few people might benefit from JSON c14n, but = the water was poisoned by the hideous XML experience and there's a = general reluctance to go anywhere near it. If we saw a really plausible = proposal, we could possibly think about rehydrating the JSON WG to look = at it.

On Thu., Oct. 11, 2018, 1:45 p.m. Carsten Bormann, <cabo@tzi.org> wrote:
On Oct 11, 2018, at = 21:58, Anders Rundgren <anders.rundgren.net@gmail.com> = wrote:
>
> shroud their precious JSON data in Base64Url

I know how to fix this, but that=E2=80=99s a different WG :-)

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

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_7C5F0B85-E4DF-4625-B9EC-BC65EEBC5D93-- From nobody Thu Oct 11 15:50:21 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604A81277BB for ; Thu, 11 Oct 2018 15:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 gX4eoRt_uEjT for ; Thu, 11 Oct 2018 15:50:18 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 AB368128D0C for ; Thu, 11 Oct 2018 15:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9BMo8qQ007202; Fri, 12 Oct 2018 00:50:13 +0200 (CEST) Received: from client-0051.vpn.uni-bremen.de (client-0051.vpn.uni-bremen.de [134.102.107.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42WR4c3Vc6z1Bq8; Fri, 12 Oct 2018 00:50:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <28C4A7CB-2F5A-49AF-95D0-3FCB7037665F@gmail.com> Date: Fri, 12 Oct 2018 00:50:07 +0200 Cc: Tim Bray , Anders Rundgren , Kathleen Moriarty , "Manger, James" , jose@ietf.org, Phil Hunt X-Mao-Original-Outgoing-Id: 560991000.420799-95024a270d1ba626d80512f4608661c9 Content-Transfer-Encoding: quoted-printable Message-Id: <87E2DA2A-53A6-4AEB-A0EB-6305F234A948@tzi.org> References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <771C010E-C469-47E9-80B8-EE8F3FBD5272@tzi.org> <28C4A7CB-2F5A-49AF-95D0-3FCB7037665F@gmail.com> To: Bret Jordan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 22:50:20 -0000 On Oct 12, 2018, at 00:22, Bret Jordan wrote: >=20 > We have a real need for it with some work I am starting here in the = IETF and work I am doing in other SDOs. So I would love to figure out = how to kickstart this work back to life. If this is about CACAO, let me question this need. Please explain how CACAO would benefit from =E2=80=9Cmonster document = with embedded partial signatures=E2=80=9D. Because of the way this information flows together, a multi-file = approach for composing information from the various stakeholders makes = much more sense to this observer. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 11 23:38:44 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A412130DE2 for ; Thu, 11 Oct 2018 23:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Vt3Rr3G7gIeQ for ; Thu, 11 Oct 2018 23:38:40 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 89C9E130DFD for ; Thu, 11 Oct 2018 23:38:40 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id a13-v6so12147851wrt.5 for ; Thu, 11 Oct 2018 23:38:40 -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=Uvx8P4j31X5/CgA3tSl7JTOgFQiqeHy/ehE1fvGL9aA=; b=D/oq7+yFzEWM2SXphxIE96YOZdJcWMffMm/xzgyRLY47ZIFFCXAL2mwtP6ne5xkuvk Flgc+Tfi0ScAIS/oaZaTyZB48xxoyL+QHUctB1Qr2cJoMhYlHtxusr2tHwkkiGHA0ItO Qelc5EQ6WW1C/V/FxhIKray66/LPsD9D3IsW40H7/43O5AmuutwnQvMOup/bVB0hbPgX OLU9nioXBaIwz6EYCL1mCp7rxqh9dlNIs0PgLuXoMBiHs0nIgcLtw0aBnSHJHcNGpMbF f9QU5hsJ3M2Nyqchzo0tXuepKmOupmILYlUN4TvTIPM6jQLVr2gOI4RpMhQ7bvn/QRYJ gAEw== 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=Uvx8P4j31X5/CgA3tSl7JTOgFQiqeHy/ehE1fvGL9aA=; b=Zn340r75L7ATsXKe0dfpyqM6k6wT4ITtgZa8qk88DUyJil6B2AvFcXsp7Ri7udWQ0y D1GzMdHFlUCm0gxx2U3ReCdsHyG7PQRFrB7/70li2jRrk4LBxAz8SeN7rITORllE6Q0Y W1LtEUXO5FaPT22ufKYLcMzRGkQ941fwV7N93FwsBTb7bodg67OGsZ2JBeMtmL2SGI7G wB35+UfHKao4CYraP11ufmfsYkXmD0TvGb1F9vWJboUAAJ9v0kg+0YB6+SCbmb4TJ5oS moe7jD9NJphxQdW7oiZtkOdpYn4EU9olnN/a4Q4jtX0poHGSYIBl8HaqRKQy7oBHgf73 D0fQ== X-Gm-Message-State: ABuFfojXl616R0bAzXFy8yzydWSNsp0af8bT7Yz+sbxwhQmJYvY4h2Uv u1W6IFwkXaTbotYb40Xov4EajQPu X-Google-Smtp-Source: ACcGV62aLw7MwhXX/RVTfJWUWfdkf/1+2xyV4Wg/ftJBLfe+Bs6Ytj9pmtgjLEZ4LezAlebbe+05ng== X-Received: by 2002:a5d:52ce:: with SMTP id r14-v6mr3934034wrv.123.1539326318394; Thu, 11 Oct 2018 23:38:38 -0700 (PDT) Received: from [192.168.43.218] (92.202.136.77.rev.sfr.net. [77.136.202.92]) by smtp.googlemail.com with ESMTPSA id 90-v6sm343820wrg.86.2018.10.11.23.38.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 23:38:37 -0700 (PDT) To: Bret Jordan Cc: Carsten Bormann , Phil Hunt , Kathleen Moriarty , "Manger, James" , jose@ietf.org References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> From: Anders Rundgren Message-ID: Date: Fri, 12 Oct 2018 08:38:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 06:38:43 -0000 On 2018-10-11 22:05, Bret Jordan wrote: > Anders, > > I really like what you have done with this. I am trying to figure out if it will work 100% for my needs, or if it will need some tweaking. If it does work, then I think we should really try and figure out how we get your work standardized. > Thanx Bret! The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D provides quite a lot of features including an extension option that can be used for adding possibly missing functionality. There is one thing that is good to know for anyone thinking about standardizing Canonical JSON and that's the fact that canonicalization also can be performed on the text level as described by: https://gibson042.github.io/canonicaljson-spec/ This has the advantage that it is very simple and supports the entire JSON RFC without restrictions. So why didn't I took this [superficially obvious] route? There are several reasons for that: A downside of source level canonicalization is that it doesn't integrate with JSON parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 was explicitly designed to eventually be an option of a standard JSON serializer as it already is in my Java reference implementation. Another issue is that it is unclear what the value is with using the JSON "Number" format outside of the IEEE range. In fact, it excludes parsers like JavaScript's JSON.parse() unless JavaScaript would be updated to always use a "BigNumber" as fundamental numeric type. Regards, Anders From nobody Fri Oct 12 08:21:02 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FEF130E22 for ; Fri, 12 Oct 2018 08:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 tz6R-4noyQIs for ; Fri, 12 Oct 2018 08:20:57 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 DC36A130DCB for ; Fri, 12 Oct 2018 08:20:56 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id u88-v6so5068378ybi.0 for ; Fri, 12 Oct 2018 08:20:56 -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=l36UpJazaMV3ENpKOLD4FKK5kldqic/fto4seR0uJaI=; b=fXzKZcmLaz6BxDOfzkc+bPfujrz4bzcE013ZdIDk2jxHll1SpGQqbNEBVh8umxS+QU yQs0MhKGm7QJ20DZRRLgQ4173M03vPnABBTRU0fVDBtzScFSZ9/ze41Fr1fc67RKAxrc YzyJGSP/i8xk9VBXgTuRIFYUpARaaKexfl9YmiCNvylqfPGEliDbUp3pwe0mwEzqDVf6 u3oTksYAO7lmC+cf1eS2OiUP8bqLcwsefaaB0btti0trSZ07V79jqumars6G678lQSmP U+BrrckG64OqultMQZF69Bpab/m4LjSmB4BXCkGGnVu5UrFpmEP08Nt9dBkSH2ruLlFf U+7A== 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=l36UpJazaMV3ENpKOLD4FKK5kldqic/fto4seR0uJaI=; b=Q32kr1LGkt1ickBA35ghAxLprMLr/fvXnC6+LysQsEc6BJ0dg7lsIUPCDiVLL+ztDh Ka4wJDu3jAFcqcuyJ792Lw3GJW9rsjEcqQQiBg1Nw7Z7YpA0bdF63wam+/ZRqJefWd6o yclRVVvDgsLrliVN1oM1G0JwRpKjA+z+t1uB0zEYP+2Nq3KU5ZReljjm/MCBJuxJdBWz 3HX10XvDnEkivlbzBOPs+w8j4S9Krn2T4PWkNEB9bEdwdsiZgrSD7ekBvdNgF2IlCTzW dYTr+jT5rH/wi0qarysGO+8+vbCAmzaFCt2Lx3TDsAvqk9JrFw4pBbjSqqXCs6LeTjmv b7hw== X-Gm-Message-State: ABuFfojUoeoVNEkIJ9BWulkZ0nx9gM1JNvv0q6XIuRnaMR3sx2DFilBN I4eSK/LGP0NlpG0ZKN0F9PI= X-Google-Smtp-Source: ACcGV61Ewz2cVVemJtuGgZOWKbPU9+lDbDGGg0P6SZ01RiYTjarcbiI7vGF37lgfPeYOnR8tCQK/jg== X-Received: by 2002:a25:2c4c:: with SMTP id s73-v6mr3439903ybs.378.1539357656159; Fri, 12 Oct 2018 08:20:56 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:a165:a6bc:f6cb:dbc6? ([2605:a601:3260:266:a165:a6bc:f6cb:dbc6]) by smtp.gmail.com with ESMTPSA id p185-v6sm353935ywc.14.2018.10.12.08.20.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 08:20:54 -0700 (PDT) From: Bret Jordan Message-Id: <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_904146E0-7798-4643-95ED-5EBF67837507" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 12 Oct 2018 09:20:19 -0600 In-Reply-To: Cc: Carsten Bormann , Phil Hunt , Kathleen Moriarty , "Manger, James" , jose@ietf.org To: Anders Rundgren References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 15:21:01 -0000 --Apple-Mail=_904146E0-7798-4643-95ED-5EBF67837507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please correct me if I am wrong=E2=80=A6. The way I understand the = problem is as follows: 1) If you verified the JSON string at consumption time, before it has = been unmarshal-ed, then all you need to do is decide how to handle white = space and carriage returns. You could basically regex remove all white = space and CR / CRLF and have a workable solution. 2) Where this breaks down is, when a tool unmarshals the data into a map = or struct, then you have no guarantee that you would recreate the keys = in the same order (a struct may force it to the order of the struct = definition). So you have no way of being able to verify the hash after = it has been unmarshal-ed. Further, if you recreate the JSON and send it = back out, the next person that gets the data might have a hash that can = not be verified in option 1 above. 3) Another problem once you have unmarshal-ed the data is what do you do = with JSON numbers. Some programming languages store them as a float, = some as who-knows-what. So you would need a way to ensure that the = number was always stored in the same way, especially for strongly typed = systems (is this architecture dependent too?). So the options here are, = if the ontology / semantics of the JSON data were well defined in schema = (a meaning it was standardized and documented), then the code could know = what it should do and interoperability tests could be made to ensure = that it worked. What am I not understanding here? And what am I missing? Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 12, 2018, at 12:38 AM, Anders Rundgren = wrote: >=20 > On 2018-10-11 22:05, Bret Jordan wrote: >> Anders, >> I really like what you have done with this. I am trying to figure = out if it will work 100% for my needs, or if it will need some tweaking. = If it does work, then I think we should really try and figure out how = we get your work standardized. >=20 > Thanx Bret! >=20 > The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 = I-D provides quite a lot of features including an extension option that = can be used for adding possibly missing functionality. >=20 > There is one thing that is good to know for anyone thinking about = standardizing Canonical JSON and that's the fact that canonicalization = also can be performed on the text level as described by: = https://gibson042.github.io/canonicaljson-spec/ >=20 > This has the advantage that it is very simple and supports the entire = JSON RFC without restrictions. >=20 >=20 > So why didn't I took this [superficially obvious] route? There are = several reasons for that: >=20 > A downside of source level canonicalization is that it doesn't = integrate with JSON parsers and serializers. = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01= was explicitly designed to eventually be an option of a standard JSON = serializer as it already is in my Java reference implementation. >=20 > Another issue is that it is unclear what the value is with using the = JSON "Number" format outside of the IEEE range. In fact, it excludes = parsers like JavaScript's JSON.parse() unless JavaScaript would be = updated to always use a "BigNumber" as fundamental numeric type. >=20 > Regards, > Anders --Apple-Mail=_904146E0-7798-4643-95ED-5EBF67837507 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Please correct me if I am wrong=E2=80=A6. The way I = understand the problem is as follows:


1) = If you verified the JSON string at consumption time, before it has been = unmarshal-ed, then all you need to do is decide how to handle white = space and carriage returns.  You could basically regex remove all = white space and CR / CRLF and have a workable solution.

2) Where this breaks = down is, when a tool unmarshals the data into a map or struct, then you = have no guarantee that you would recreate the keys in the same order (a = struct may force it to the order of the struct definition). So you have = no way of being able to verify the hash after it has been unmarshal-ed. =  Further, if you recreate the JSON and send it back out, the next = person that gets the data might have a hash that can not be verified in = option 1 above.

3) Another problem once you have unmarshal-ed the data is = what do you do with JSON numbers.  Some programming languages store = them as a float, some as who-knows-what.  So you would need a way = to ensure that the number was always stored in the same way, especially = for strongly typed systems (is this architecture dependent too?). So the = options here are, if the ontology / semantics of the JSON data were well = defined in schema (a meaning it was standardized and documented), then = the code could know what it should do and interoperability tests could = be made to ensure that it worked.

What am I not understanding here? =  And what am I missing?

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 12, 2018, at 12:38 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

On = 2018-10-11 22:05, Bret Jordan wrote:
Anders,
I really like what you = have done with this.  I am trying to figure out if it will work = 100% for my needs, or if it will need some tweaking.  If it does = work, then I think we should really try and figure out how we get your = work standardized.

Thanx = Bret!

The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01= I-D provides quite a lot of features including an extension option = that can be used for adding possibly missing functionality.

There is one thing that is good to know for = anyone thinking about standardizing Canonical JSON and that's the fact = that canonicalization also can be performed on the text level as = described by: https://gibson042.github.io/canonicaljson-spec/

This has the advantage that it is very simple = and supports the entire JSON RFC without restrictions.


So why didn't I took this [superficially = obvious] route? There are several reasons for that:

A downside of source level canonicalization is that it = doesn't integrate with JSON parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalizatio= n-scheme-01 was explicitly designed to eventually be an option of a = standard JSON serializer as it already is in my Java reference = implementation.

Another issue is that it is = unclear what the value is with using the JSON "Number" format outside of = the IEEE range.  In fact, it excludes parsers like JavaScript's = JSON.parse() unless JavaScaript would be updated to always use a = "BigNumber" as fundamental numeric type.

Regards,
Anders

= --Apple-Mail=_904146E0-7798-4643-95ED-5EBF67837507-- From nobody Fri Oct 12 09:26:32 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F9E130DE6 for ; Fri, 12 Oct 2018 09:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WCBbw5rM7UPP for ; Fri, 12 Oct 2018 09:26:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B923A130DEB for ; Fri, 12 Oct 2018 09:26:25 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 12 Oct 2018 09:21:39 -0700 From: Jim Schaad To: 'Bret Jordan' , 'Anders Rundgren' CC: 'Carsten Bormann' , "'Manger, James'" , 'Kathleen Moriarty' , , 'Phil Hunt' References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> In-Reply-To: <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> Date: Fri, 12 Oct 2018 09:26:15 -0700 Message-ID: <017e01d46248$4e040280$ea0c0780$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017F_01D4620D.A1A837C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNnP1/vuW81sZle9dbx86Tf75xU2AFuBXA/AqJ1qI4BeDi93AGy0bp+AoVGtcgBWQ3ouAHMBZ2PAgPtnXwBomSRnAJU7RiuARLhWd8DID9IqAHgTXhlAXrBW+MCTiSuwKEQJWTA Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:26:30 -0000 ------=_NextPart_000_017F_01D4620D.A1A837C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: jose On Behalf Of Bret Jordan Sent: Friday, October 12, 2018 8:20 AM To: Anders Rundgren Cc: Carsten Bormann ; Manger, James = ; Kathleen Moriarty = ; jose@ietf.org; Phil Hunt = Subject: Re: [jose] Canonical JSON form =20 Please correct me if I am wrong=E2=80=A6. The way I understand the = problem is as follows: =20 =20 1) If you verified the JSON string at consumption time, before it has = been unmarshal-ed, then all you need to do is decide how to handle white = space and carriage returns. You could basically regex remove all white = space and CR / CRLF and have a workable solution. =20 [JLS] Which is what JOSE does =E2=80=93 passes the string in a form that = will not be unmarshal-ed. =20 2) Where this breaks down is, when a tool unmarshals the data into a map = or struct, then you have no guarantee that you would recreate the keys = in the same order (a struct may force it to the order of the struct = definition). So you have no way of being able to verify the hash after = it has been unmarshal-ed. Further, if you recreate the JSON and send it = back out, the next person that gets the data might have a hash that can = not be verified in option 1 above. =20 3) Another problem once you have unmarshal-ed the data is what do you do = with JSON numbers. Some programming languages store them as a float, = some as who-knows-what. So you would need a way to ensure that the = number was always stored in the same way, especially for strongly typed = systems (is this architecture dependent too?). So the options here are, = if the ontology / semantics of the JSON data were well defined in schema = (a meaning it was standardized and documented), then the code could know = what it should do and interoperability tests could be made to ensure = that it worked. =20 [JLS] The issue is not so much what the format that the number is = stored internally in, the problem is how is the number serialized out. = Some have dealt with this problem by storing the string version of the = number along side the numeric version. Not what I consider to be an = acceptable solution but it may be the only one that works. =20 What am I not understanding here? And what am I missing? =20 =20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." On Oct 12, 2018, at 12:38 AM, Anders Rundgren = > = wrote: =20 On 2018-10-11 22:05, Bret Jordan wrote: Anders, I really like what you have done with this. I am trying to figure out = if it will work 100% for my needs, or if it will need some tweaking. If = it does work, then I think we should really try and figure out how we = get your work standardized. Thanx Bret! The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D = provides quite a lot of features including an extension option that can = be used for adding possibly missing functionality. There is one thing that is good to know for anyone thinking about = standardizing Canonical JSON and that's the fact that canonicalization = also can be performed on the text level as described by: = https://gibson042.github.io/canonicaljson-spec/ This has the advantage that it is very simple and supports the entire = JSON RFC without restrictions. So why didn't I took this [superficially obvious] route? There are = several reasons for that: A downside of source level canonicalization is that it doesn't integrate = with JSON parsers and serializers. = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-0= 1 was explicitly designed to eventually be an option of a standard JSON = serializer as it already is in my Java reference implementation. Another issue is that it is unclear what the value is with using the = JSON "Number" format outside of the IEEE range. In fact, it excludes = parsers like JavaScript's JSON.parse() unless JavaScaript would be = updated to always use a "BigNumber" as fundamental numeric type. Regards, Anders =20 ------=_NextPart_000_017F_01D4620D.A1A837C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: jose = <jose-bounces@ietf.org> On Behalf Of Bret = Jordan
Sent: Friday, October 12, 2018 8:20 AM
To: = Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: = Carsten Bormann <cabo@tzi.org>; Manger, James = <James.H.Manger@team.telstra.com>; Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com>; jose@ietf.org; Phil Hunt = <phil.hunt@oracle.com>
Subject: Re: [jose] Canonical = JSON form

 

Please = correct me if I am wrong=E2=80=A6. The way I understand the problem is = as follows:

 

 

1) If you verified the JSON string at consumption = time, before it has been unmarshal-ed, then all you need to do is decide = how to handle white space and carriage returns.  You could = basically regex remove all white space and CR / CRLF and have a workable = solution.

 

[JLS] Which is what JOSE does =E2=80=93 passes the = string in a form that will not be = unmarshal-ed.

 

2) Where this breaks down is, when a tool unmarshals = the data into a map or struct, then you have no guarantee that you would = recreate the keys in the same order (a struct may force it to the order = of the struct definition). So you have no way of being able to verify = the hash after it has been unmarshal-ed.  Further, if you recreate = the JSON and send it back out, the next person that gets the data might = have a hash that can not be verified in option 1 = above.

 

3) Another problem once you have unmarshal-ed the data = is what do you do with JSON numbers.  Some programming languages = store them as a float, some as who-knows-what.  So you would need a = way to ensure that the number was always stored in the same way, = especially for strongly typed systems (is this architecture dependent = too?). So the options here are, if the ontology / semantics of the JSON = data were well defined in schema (a meaning it was standardized and = documented), then the code could know what it should do and = interoperability tests could be made to ensure that it = worked.

 

[JLS]=C2=A0 The issue is not so much what the format = that the number is stored internally in, the problem is how is the = number serialized out. Some have dealt with this problem by storing the = string version of the number along side the numeric version.=C2=A0 Not = what I consider to be an acceptable solution but it may be the only one = that works.

 

What am I not understanding here?  And what am I = missing?

 

 

Thanks,

Bret

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

= "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg."



On Oct 12, 2018, at 12:38 AM, Anders Rundgren <anders.rundgren.net@gmail.c= om> wrote:

 

On = 2018-10-11 22:05, Bret Jordan wrote:

Anders,
I really like what you have done with this. =  I am trying to figure out if it will work 100% for my needs, or if = it will need some tweaking.  If it does work, then I think we = should really try and figure out how we get your work = standardized.


Thanx = Bret!

The = https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D = provides quite a lot of features including an extension option that can = be used for adding possibly missing functionality.

There is one = thing that is good to know for anyone thinking about standardizing = Canonical JSON and that's the fact that canonicalization also can be = performed on the text level as described by: https://gibson04= 2.github.io/canonicaljson-spec/

This has the advantage that = it is very simple and supports the entire JSON RFC without = restrictions.


So why didn't I took this [superficially = obvious] route? There are several reasons for that:

A downside of = source level canonicalization is that it doesn't integrate with JSON = parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalizati= on-scheme-01 was explicitly designed to eventually be an option of a = standard JSON serializer as it already is in my Java reference = implementation.

Another issue is that it is unclear what the = value is with using the JSON "Number" format outside of the = IEEE range.  In fact, it excludes parsers like JavaScript's = JSON.parse() unless JavaScaript would be updated to always use a = "BigNumber" as fundamental numeric = type.

Regards,
Anders

 

------=_NextPart_000_017F_01D4620D.A1A837C0-- From nobody Fri Oct 12 09:47:51 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F103130E89 for ; Fri, 12 Oct 2018 09:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ztOzRByydiTh for ; Fri, 12 Oct 2018 09:47:32 -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 56DC9130E7D for ; Fri, 12 Oct 2018 09:47:30 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id e187-v6so13614122wmf.0 for ; Fri, 12 Oct 2018 09:47:30 -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=UK4yDeDKk3oKr9xzlDe6CJ8LN6SsWhS0b6E2dp3O8v0=; b=lLqN2rS4r4jAm+lAlD424tk9iqkTNQHJinDFiaXq4Nz5FYM+tHkkr5OmLtxxrqh1qg UzOBL9cM4rkYeaCLCtEe35bHpNb8bLA1aX1Gasxy6ViFbqR5zR3rLgN7wVwh1q5YRFXP QMPjv4J2VZ/aa46lICcUaY3juALw6A/AZ6T/37PUku6kFIrpEnN7DPAEnSBGezMn1Hp+ dFI9l1TaILgqj8pJX0H9BgelnHABKu2tmhOM8BixdLsfSm8ZIJ+EQQfZgKPFA8gXEhNZ dA3AwyofqGBnq+b9sanIh0owzq0IHAVCINMvkSskSymr7rS+0RNwzmjt4ZHuRQ9qlodv FRiQ== 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=UK4yDeDKk3oKr9xzlDe6CJ8LN6SsWhS0b6E2dp3O8v0=; b=QIVQ6EQYNJEZB52APn2FJjKr4bCNmtnDzBl8XVOhUzKP/JthF+rrc4GKTMSGO8N+wX gR1w+r+KnTMuyKXi7U8VjnOOqTO494Mxa4IcW+HV8pH5YpVT1WyzqkoxH1W4dRC/3GXB 6S0QaEBnKzYrAaTftyU+NEgot4MTpJCxwJinlbr98Yk9ociSaUf30DEjsNIArM0ED6vV qk5+2LIvhWOuS11hba69/grSq40CFzFGDKpVuMUYEZSWPyjk6SpvhmaSMXQRS/3kddRc TBEvqsyKpesO36edjMfVYdxdYs4Cs2NCSG8YtPLkokDmztKomT65wB8ddda40iu6GbvH SOmA== X-Gm-Message-State: ABuFfogMeUGhvfqNkCJq8fjcqCo8H6W+ZquXaaIkV13vqCVSGlQ03tKh vN6TFmAkusvQea7SHfwsa+JaYHxv X-Google-Smtp-Source: ACcGV63EsFMxJkNmX5Vkm9LyDlbTxqg+r2WQLYGylImwO99aQ/g0ze0+48czPOH7xnqEKUS1VV9/CA== X-Received: by 2002:a1c:2846:: with SMTP id o67-v6mr5613687wmo.60.1539362848137; Fri, 12 Oct 2018 09:47:28 -0700 (PDT) Received: from [192.168.43.218] (110.202.154.77.rev.sfr.net. [77.154.202.110]) by smtp.googlemail.com with ESMTPSA id l67-v6sm3378251wma.20.2018.10.12.09.47.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 09:47:27 -0700 (PDT) To: Bret Jordan Cc: Carsten Bormann , Phil Hunt , Kathleen Moriarty , "Manger, James" , jose@ietf.org References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> From: Anders Rundgren Message-ID: <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> Date: Fri, 12 Oct 2018 18:47:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:47:49 -0000 On 2018-10-12 17:20, Bret Jordan wrote: > Please correct me if I am wrong…. The way I understand the problem is as follows: Hi Bret, Comments in line... > > > 1) If you verified the JSON string at consumption time, before it has been unmarshal-ed, then all you need to do is decide how to handle white space and carriage returns.  You could basically regex remove all white space and CR / CRLF and have a workable solution. It depends on what your goal is. Canonicalization builds on the assumption that there is a unique representation of the data, preferably even after it has passed through a processor like an intermediary. > > 2) Where this breaks down is, when a tool unmarshals the data into a map or struct, then you have no guarantee that you would recreate the keys in the same order (a struct may force it to the order of the struct definition). So you have no way of being able to verify the hash after it has been unmarshal-ed.  Further, if you recreate the JSON and send it back out, the next person that gets the data might have a hash that can not be verified in option 1 above. Right, therefore option 1 is not very useful. Sorting of keys is the cure for this issue. > > 3) Another problem once you have unmarshal-ed the data is what do you do with JSON numbers. Right, but even string data needs adjustments. "\u0020" and " " both represents a space character. > Some programming languages store them as a float, some as who-knows-what.  So you would need a way to ensure that the number was always stored in the same way, especially for strongly typed systems (is this architecture dependent too?). So the options here are, if the ontology / semantics of the JSON data were well defined in schema (a meaning it was standardized and documented), then the code could know what it should do and interoperability tests could be made to ensure that it worked. This is (IMO) the only part of the puzzle that is non-trivial. In my take on the matter, I have "prescribed" that the JSON Number type must be coerced into an IEEE 754 double precision number and be serialized according to ECMAScript V6+ rules. If your application needs higher precision or bigger range, you are forced using the quoted string notation which (AFAIK...) is used by every IETF standard of any significance to date defining a JSON structure. > > What am I not understanding here?  And what am I missing? As I wrote earlier, there are (at least) two entirely different and documented approaches. Using a schema based canonicalizer as you mention is also an option but that is a much more ambitious project. Regards, Anders > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > >> On Oct 12, 2018, at 12:38 AM, Anders Rundgren > wrote: >> >> On 2018-10-11 22:05, Bret Jordan wrote: >>> Anders, >>> I really like what you have done with this.  I am trying to figure out if it will work 100% for my needs, or if it will need some tweaking.  If it does work, then I think we should really try and figure out how we get your work standardized. >> >> Thanx Bret! >> >> The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D provides quite a lot of features including an extension option that can be used for adding possibly missing functionality. >> >> There is one thing that is good to know for anyone thinking about standardizing Canonical JSON and that's the fact that canonicalization also can be performed on the text level as described by: https://gibson042.github.io/canonicaljson-spec/ >> >> This has the advantage that it is very simple and supports the entire JSON RFC without restrictions. >> >> >> So why didn't I took this [superficially obvious] route? There are several reasons for that: >> >> A downside of source level canonicalization is that it doesn't integrate with JSON parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 was explicitly designed to eventually be an option of a standard JSON serializer as it already is in my Java reference implementation. >> >> Another issue is that it is unclear what the value is with using the JSON "Number" format outside of the IEEE range.  In fact, it excludes parsers like JavaScript's JSON.parse() unless JavaScaript would be updated to always use a "BigNumber" as fundamental numeric type. >> >> Regards, >> Anders > From nobody Fri Oct 12 14:32:17 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B2126DBF for ; Fri, 12 Oct 2018 14:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 zzXCVzTkx4qM for ; Fri, 12 Oct 2018 14:32:12 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 8B86F126BED for ; Fri, 12 Oct 2018 14:32:12 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id o8-v6so5442647ybk.13 for ; Fri, 12 Oct 2018 14:32:12 -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=V7ESpT4M3imsGSYozLCZS2J1qMmQBEtoW+iWygUczh8=; b=ABuRKS0mNIBpgEMv4IEZP5r+ZTkeko190ZcGJ/5oEN2WaZZEsQK6WaBviKrGI4usnE EGhO01sBXxouIsP77WxnWIEVTPdF+sKNB0I+BfXJESf4QA5x88WdH3tn7pCEn06M3h1T 8EY/6OvIlEeaeg+0Wlzn1pUdfD6ECs9Twd7eSLM8TzcwpDU9dBedDEuSOzbPQovlr0y7 66cpZqbQGF36rTgWZc3Vqx6m6XVFyBorcZ3ASsC6ofwEqOsVuK6zYBjlR5Ei+ZrPEET1 iJzQ5XAvrIs2DB+Vf5YF/wmucOhabUI/EENZJJ/PNh5tsSebARH636pE19IkcPKXkHW+ Dn5w== 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=V7ESpT4M3imsGSYozLCZS2J1qMmQBEtoW+iWygUczh8=; b=L4O367ykjMdt1S6KPvf1Okur993pyyDlYhmovKHUXmPAR/KokCxl6MjfL8y2OAqNG/ /VlNImU66PMvv4mjaSv9+/yqDNuzyq/7EfwJdXpP6g1O6T2zchB3jeUV3d4Z8pHaKIub Tk9jJDP5MvOKcIgKkq5tfVtUmv8ibSespW9qh5DfYkY4ofwrtQUU4KdDEi2czZj8LQil 0JpGgvhF65taxuYpzbZB75EdDqWDW5QTvTYaiqXCv6C/2sXIXma6tvjYle8PysL5PWfC UycMpM5UkTSL+D2a1AscmNwnO6kSz4yPOIPaX9wOq89DNfVUuqiYfi6p2msFg8ic36Qb Ps0A== X-Gm-Message-State: ABuFfojTmzaBGvbgI26rvN5QqnT7r9DlNnF1fOmrFsWk4M0BbuWnYDl9 Zildu9hS9YYwuPrCvLhPNDU= X-Google-Smtp-Source: ACcGV60zf8PGY03AY0DZjWvxx89Pds0txGgzsm9f83q14jQpNRs5dK7kXaBChKhwwloqHM7T3ZT7mQ== X-Received: by 2002:a25:3186:: with SMTP id x128-v6mr4308767ybx.227.1539379931810; Fri, 12 Oct 2018 14:32:11 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:5c21:51e5:4593:9d31? ([2605:a601:3260:266:5c21:51e5:4593:9d31]) by smtp.gmail.com with ESMTPSA id a207-v6sm611834ywe.22.2018.10.12.14.32.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 14:32:10 -0700 (PDT) From: Bret Jordan Message-Id: <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_83EE5D84-4775-4953-A188-CDD604275331" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 12 Oct 2018 15:31:30 -0600 In-Reply-To: <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> Cc: Carsten Bormann , Phil Hunt , Kathleen Moriarty , "Manger, James" , jose@ietf.org To: Anders Rundgren References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 21:32:16 -0000 --Apple-Mail=_83EE5D84-4775-4953-A188-CDD604275331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Anders, How do we move forward? What can we do to make this happen? Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 12, 2018, at 10:47 AM, Anders Rundgren = wrote: >=20 > On 2018-10-12 17:20, Bret Jordan wrote: >> Please correct me if I am wrong=E2=80=A6. The way I understand the = problem is as follows: >=20 > Hi Bret, > Comments in line... >> 1) If you verified the JSON string at consumption time, before it has = been unmarshal-ed, then all you need to do is decide how to handle white = space and carriage returns. You could basically regex remove all white = space and CR / CRLF and have a workable solution. >=20 > It depends on what your goal is. Canonicalization builds on the = assumption that there is a unique representation of the data, preferably = even after it has passed through a processor like an intermediary. >=20 >> 2) Where this breaks down is, when a tool unmarshals the data into a = map or struct, then you have no guarantee that you would recreate the = keys in the same order (a struct may force it to the order of the struct = definition). So you have no way of being able to verify the hash after = it has been unmarshal-ed. Further, if you recreate the JSON and send it = back out, the next person that gets the data might have a hash that can = not be verified in option 1 above. >=20 > Right, therefore option 1 is not very useful. Sorting of keys is the = cure for this issue. >=20 >=20 >> 3) Another problem once you have unmarshal-ed the data is what do you = do with JSON numbers.=20 >=20 > Right, but even string data needs adjustments. "\u0020" and " " both = represents a space character. >=20 >=20 >> Some programming languages store them as a float, some as = who-knows-what. So you would need a way to ensure that the number was = always stored in the same way, especially for strongly typed systems (is = this architecture dependent too?). So the options here are, if the = ontology / semantics of the JSON data were well defined in schema (a = meaning it was standardized and documented), then the code could know = what it should do and interoperability tests could be made to ensure = that it worked. >=20 > This is (IMO) the only part of the puzzle that is non-trivial. In my = take on the matter, I have "prescribed" that the JSON Number type must = be coerced into an IEEE 754 double precision number and be serialized = according to ECMAScript V6+ rules. >=20 > If your application needs higher precision or bigger range, you are = forced using the quoted string notation which (AFAIK...) is used by = every IETF standard of any significance to date defining a JSON = structure. >=20 >=20 >> What am I not understanding here? And what am I missing? >=20 >=20 > As I wrote earlier, there are (at least) two entirely different and = documented approaches. >=20 > Using a schema based canonicalizer as you mention is also an option = but that is a much more ambitious project. >=20 > Regards, > Anders >=20 >=20 >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>> On Oct 12, 2018, at 12:38 AM, Anders Rundgren = > = wrote: >>>=20 >>> On 2018-10-11 22:05, Bret Jordan wrote: >>>> Anders, >>>> I really like what you have done with this. I am trying to figure = out if it will work 100% for my needs, or if it will need some tweaking. = If it does work, then I think we should really try and figure out how = we get your work standardized. >>>=20 >>> Thanx Bret! >>>=20 >>> The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 = I-D provides quite a lot of features including an extension option that = can be used for adding possibly missing functionality. >>>=20 >>> There is one thing that is good to know for anyone thinking about = standardizing Canonical JSON and that's the fact that canonicalization = also can be performed on the text level as described by: = https://gibson042.github.io/canonicaljson-spec/ >>>=20 >>> This has the advantage that it is very simple and supports the = entire JSON RFC without restrictions. >>>=20 >>>=20 >>> So why didn't I took this [superficially obvious] route? There are = several reasons for that: >>>=20 >>> A downside of source level canonicalization is that it doesn't = integrate with JSON parsers and serializers. = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01= was explicitly designed to eventually be an option of a standard JSON = serializer as it already is in my Java reference implementation. >>>=20 >>> Another issue is that it is unclear what the value is with using the = JSON "Number" format outside of the IEEE range. In fact, it excludes = parsers like JavaScript's JSON.parse() unless JavaScaript would be = updated to always use a "BigNumber" as fundamental numeric type. >>>=20 >>> Regards, >>> Anders >=20 --Apple-Mail=_83EE5D84-4775-4953-A188-CDD604275331 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Anders,

How= do we move forward?  What can we do to make this happen?


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 12, 2018, at 10:47 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

On = 2018-10-12 17:20, Bret Jordan wrote:
Please correct me if I am wrong=E2=80=A6. The = way I understand the problem is as follows:
Hi Bret,
Comments in line...
1) If you verified the = JSON string at consumption time, before it has been unmarshal-ed, then = all you need to do is decide how to handle white space and carriage = returns.  You could basically regex remove all white space and CR / = CRLF and have a workable solution.

It depends on what your goal is.  Canonicalization = builds on the assumption that there is a unique representation of the = data, preferably even after it has passed through a processor like an = intermediary.

2) Where this breaks down is, when a tool unmarshals the data = into a map or struct, then you have no guarantee that you would recreate = the keys in the same order (a struct may force it to the order of the = struct definition). So you have no way of being able to verify the hash = after it has been unmarshal-ed.  Further, if you recreate the JSON = and send it back out, the next person that gets the data might have a = hash that can not be verified in option 1 above.

Right, therefore option 1 is not = very useful.  Sorting of keys is the cure for this issue.


3) Another problem once you have unmarshal-ed the data is = what do you do with JSON numbers.

Right, but even string data needs adjustments.  "\u0020" = and " " both represents a space character.


Some = programming languages store them as a float, some as who-knows-what. =  So you would need a way to ensure that the number was always = stored in the same way, especially for strongly typed systems (is this = architecture dependent too?). So the options here are, if the ontology / = semantics of the JSON data were well defined in schema (a meaning it was = standardized and documented), then the code could know what it should do = and interoperability tests could be made to ensure that it worked.

This is (IMO) the only part of = the puzzle that is non-trivial.  In my take on the matter, I have = "prescribed" that the JSON Number type must be coerced into an IEEE 754 = double precision number and be serialized according to ECMAScript V6+ = rules.

If your application needs higher = precision or bigger range, you are forced using the quoted string = notation which (AFAIK...) is used by every IETF standard of any = significance to date defining a JSON structure.


What am I = not understanding here?  And what am I missing?


As I wrote = earlier, there are (at least) two entirely different and documented = approaches.

Using a schema based = canonicalizer as you mention is also an option but that is a much more = ambitious project.

Regards,
Anders


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."
On Oct 12, 2018, at 12:38 AM, Anders Rundgren = <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:

On 2018-10-11 22:05, Bret Jordan wrote:
Anders,
I = really like what you have done with this.  I am trying to figure = out if it will work 100% for my needs, or if it will need some tweaking. =  If it does work, then I think we should really try and figure out = how we get your work standardized.

Thanx Bret!

The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01= I-D provides quite a lot of features including an extension option = that can be used for adding possibly missing functionality.

There is one thing that is good to know for = anyone thinking about standardizing Canonical JSON and that's the fact = that canonicalization also can be performed on the text level as = described by: https://gibson042.github.io/canonicaljson-spec/

This has the advantage that it is very simple = and supports the entire JSON RFC without restrictions.


So why didn't I took this [superficially = obvious] route? There are several reasons for that:

A downside of source level canonicalization is that it = doesn't integrate with JSON parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalizatio= n-scheme-01 was explicitly designed to eventually be an option of a = standard JSON serializer as it already is in my Java reference = implementation.

Another issue is that it is = unclear what the value is with using the JSON "Number" format outside of = the IEEE range.  In fact, it excludes parsers like JavaScript's = JSON.parse() unless JavaScaript would be updated to always use a = "BigNumber" as fundamental numeric type.

Regards,
Anders


= --Apple-Mail=_83EE5D84-4775-4953-A188-CDD604275331-- From nobody Mon Oct 15 21:30:24 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F19128D0C for ; Mon, 15 Oct 2018 21:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 wNoDPgRN_gpA for ; Mon, 15 Oct 2018 21:30:21 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002068.outbound.protection.outlook.com [40.92.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F781292AD for ; Mon, 15 Oct 2018 21:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsXjq+Z4LSqit3qJCzG4lIb4i70tHLU33QVba2yymNY=; b=NQbtd8CRkFVm/xx8V6dajJc+AqKwQCNITzu7YL9C2C6Ab0HTPsLktFQOHHmEyI1RLAbrHBT6seTxSjylZi5VKEPjvm5j3J6VQE2xRS4ZKN43D4pgauJwKy1W4K2gdUPZUwVC8llkyYxzKP8WJX3ZUz4sWEFrngopcB59/0gYw2Rl+tMu1H8dNlzGhNCasUemk+/rLLecWsM8qEQzj6uHTZqhWnb46Lpvz18h7hQYlPc7iMNF+XIgE4xEoUmaSXWNLS/pgQbacFHlOfEFpsfC4gTB6lGmWmRdqeDS7X5SHi1/EvODMU9kAsNTzrlvftWwlhjzt/F6/HvR3FbaTAnNPg== Received: from BY2NAM01FT030.eop-nam01.prod.protection.outlook.com (10.152.68.59) by BY2NAM01HT074.eop-nam01.prod.protection.outlook.com (10.152.68.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.12; Tue, 16 Oct 2018 04:30:19 +0000 Received: from BL0PR02MB4276.namprd02.prod.outlook.com (10.152.68.55) by BY2NAM01FT030.mail.protection.outlook.com (10.152.69.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.12 via Frontend Transport; Tue, 16 Oct 2018 04:30:19 +0000 Received: from BL0PR02MB4276.namprd02.prod.outlook.com ([fe80::4588:c4c7:8cbe:d7ed]) by BL0PR02MB4276.namprd02.prod.outlook.com ([fe80::4588:c4c7:8cbe:d7ed%5]) with mapi id 15.20.1228.020; Tue, 16 Oct 2018 04:30:19 +0000 From: Michael Jones To: Anders Rundgren CC: "jose@ietf.org" , Kathleen Moriarty , Carsten Bormann , Phil Hunt , "Manger, James" Thread-Topic: Michael Jones 19725 NE 61st Pl, Redmond, WA 98053 425-985-8916 tomorrow (Tuesday) at 5:30am the ... Thread-Index: AQHUZQjxlpru6vIJ8E+rn7q+hqRbEw== Date: Tue, 16 Oct 2018 04:30:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:AAED4EC9E1433B08867328D7DD59251177F1CF71CEB61017D063107A26FFC319; UpperCasedChecksum:476EBA0A07B35B235A1374C156C8CD71E1B49697CF22A4E242125CF97567B1AA; SizeAsReceived:7486; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [e7fOgLP5Jt2kFbEWx84qLguH5W+8jg55AV1Gs3r+3TI=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM01HT074; 6:Yt84uDEt92+lOtvx+Q8pplf70cV5iLrkEhjFaJrVSPl9NNd/MV6aU/nywCWgVqx67L7nnNaonlgPR9IjC14axTlm507GWs6s1jIRX/IXB7ZlIHLlSXT8OQF+LCBoNVBqJQuWL7hZ/8QM7KJgmzWD+6q8CRgy/6gj5EOuMuasTcTyWOtgDyG0iYqgWKexMJgIDQMVCqSXiwhM2DFFP+8kT8IUpbXzrY+SysHhWplnIe2V2F+tOCuDMlCLRhOoYX7ZPB7hsFmQUvD6MXZlK/gaJHQDzncC0rcd29+PbRnNUEb0psne24y/cd1xew6j0Zl9dLQbD8hcH0VnLemQsfZUIkh/CHGJ3Icxa8LxM2slH9WL2HTxwTVG5J6pt6BhAsfpM+KvF+DaP7xn/pw82ceYBzNQBbXg1bSUerrHqAqdO66aThO1spB84VNdFs2tZcbUqDhHsdCJlN4wrOBULKU1Mg==; 5:P9J44Kml7ru0D7hWintCJcdjMH6yTHIfAIY5RyKgDlTmoBUAahsWDvsQhAWCF4ZfhrNukIIxBoDE18HIEvaJG627skmw44tgEavt1Hg+5B8rLKQvVvRvdYcQI0OK3d3hQnrcUh7oM2/aNHJZuK1dYHUW+mf0UvdPihbOfLd8Wec=; 7:K9fs/N+d0xmHhz87WHTHBsC4BSn7jKVnaMmb2FfmXF2EtvjXT27AU4SxWXYIkjcBH4J41exIPqKiY5ZWJsBB27G03oxLisJgb8Z87GgCtTa6FhYZrOJGAdDGCjtlGEouxBT68RdFKcTO4IE8Fqlb9vRc4q7BptU6EvPn21hYvxmLIWtUE2Vk94IhckUwONmhjvzg/Rd/YRiceaB8VNgWxtRkXGQ/5WGu4RXHz+geazZy9D9M1SOX96UTxuGFjQNu x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:BY2NAM01HT074; x-ms-traffictypediagnostic: BY2NAM01HT074: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BY2NAM01HT074; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT074; x-microsoft-antispam-message-info: O/8QhG69HRJlnTDKolQQzwQbdBWQiqXOdE8Xjiu84fpB+BEPKaqU7JVoLl0MewoA Content-Type: multipart/alternative; boundary="_000_BL0PR02MB4276166633D32020763F97C4B7FE0BL0PR02MB4276namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8 X-MS-Exchange-CrossTenant-Network-Message-Id: 83b16a27-e85c-459a-5f0a-08d633201438 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2018 04:30:18.9671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT074 Archived-At: Subject: [jose] Fwd: Michael Jones 19725 NE 61st Pl, Redmond, WA 98053 425-985-8916 tomorrow (Tuesday) at 5:30am the ... X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 04:30:24 -0000 --_000_BL0PR02MB4276166633D32020763F97C4B7FE0BL0PR02MB4276namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KDQpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzgsIGFuIEFUJlQgNEcgTFRFIHNt YXJ0cGhvbmUNCg0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0NCkZyb206 IEJyZXQgSm9yZGFuIDxqb3JkYW4uaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiAxMC8xMy8xOCA2OjMy IEFNIChHTVQrMDk6MDApDQpUbzogQW5kZXJzIFJ1bmRncmVuIDxhbmRlcnMucnVuZGdyZW4ubmV0 QGdtYWlsLmNvbT4NCkNjOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4sICJNYW5nZXIs IEphbWVzIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4sIEthdGhsZWVuIE1vcmlh cnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4sIGpvc2VAaWV0Zi5vcmcsIFBo aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpTdWJqZWN0OiBSZTogW2pvc2VdIENhbm9u aWNhbCBKU09OIGZvcm0NCg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KRnJv bTogQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IDEwLzEzLzE4IDY6 MzIgQU0gKEdNVCswOTowMCkNClRvOiBBbmRlcnMgUnVuZGdyZW4gPGFuZGVycy5ydW5kZ3Jlbi5u ZXRAZ21haWwuY29tPg0KQ2M6IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiwgIk1hbmdl ciwgSmFtZXMiIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPiwgS2F0aGxlZW4gTW9y aWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiwgam9zZUBpZXRmLm9yZywg UGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbam9zZV0gQ2Fu b25pY2FsIEpTT04gZm9ybQ0KDQpBbmRlcnMsDQoNCkhvdyBkbyB3ZSBtb3ZlIGZvcndhcmQ/ICBX aGF0IGNhbiB3ZSBkbyB0byBtYWtlIHRoaXMgaGFwcGVuPw0KDQoNClRoYW5rcywNCkJyZXQNClBH UCBGaW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICBGMkMwIDc0RjggQUNBRSA3 NDE1IDAwNTANCiJXaXRob3V0IGNyeXB0b2dyYXBoeSB2aWh2IHZpdmMgY2UgeGhybnJ3LCBob3dl dmVyLCB0aGUgb25seSB0aGluZyB0aGF0IGNhbiBub3QgYmUgdW5zY3JhbWJsZWQgaXMgYW4gZWdn LiINCg0KT24gT2N0IDEyLCAyMDE4LCBhdCAxMDo0NyBBTSwgQW5kZXJzIFJ1bmRncmVuIDxhbmRl cnMucnVuZGdyZW4ubmV0QGdtYWlsLmNvbTxtYWlsdG86YW5kZXJzLnJ1bmRncmVuLm5ldEBnbWFp bC5jb20+PiB3cm90ZToNCg0KT24gMjAxOC0xMC0xMiAxNzoyMCwgQnJldCBKb3JkYW4gd3JvdGU6 DQpQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25n4oCmLiBUaGUgd2F5IEkgdW5kZXJzdGFu ZCB0aGUgcHJvYmxlbSBpcyBhcyBmb2xsb3dzOg0KDQpIaSBCcmV0LA0KQ29tbWVudHMgaW4gbGlu ZS4uLg0KMSkgSWYgeW91IHZlcmlmaWVkIHRoZSBKU09OIHN0cmluZyBhdCBjb25zdW1wdGlvbiB0 aW1lLCBiZWZvcmUgaXQgaGFzIGJlZW4gdW5tYXJzaGFsLWVkLCB0aGVuIGFsbCB5b3UgbmVlZCB0 byBkbyBpcyBkZWNpZGUgaG93IHRvIGhhbmRsZSB3aGl0ZSBzcGFjZSBhbmQgY2FycmlhZ2UgcmV0 dXJucy4gIFlvdSBjb3VsZCBiYXNpY2FsbHkgcmVnZXggcmVtb3ZlIGFsbCB3aGl0ZSBzcGFjZSBh bmQgQ1IgLyBDUkxGIGFuZCBoYXZlIGEgd29ya2FibGUgc29sdXRpb24uDQoNCkl0IGRlcGVuZHMg b24gd2hhdCB5b3VyIGdvYWwgaXMuICBDYW5vbmljYWxpemF0aW9uIGJ1aWxkcyBvbiB0aGUgYXNz dW1wdGlvbiB0aGF0IHRoZXJlIGlzIGEgdW5pcXVlIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBkYXRh LCBwcmVmZXJhYmx5IGV2ZW4gYWZ0ZXIgaXQgaGFzIHBhc3NlZCB0aHJvdWdoIGEgcHJvY2Vzc29y IGxpa2UgYW4gaW50ZXJtZWRpYXJ5Lg0KDQoyKSBXaGVyZSB0aGlzIGJyZWFrcyBkb3duIGlzLCB3 aGVuIGEgdG9vbCB1bm1hcnNoYWxzIHRoZSBkYXRhIGludG8gYSBtYXAgb3Igc3RydWN0LCB0aGVu IHlvdSBoYXZlIG5vIGd1YXJhbnRlZSB0aGF0IHlvdSB3b3VsZCByZWNyZWF0ZSB0aGUga2V5cyBp biB0aGUgc2FtZSBvcmRlciAoYSBzdHJ1Y3QgbWF5IGZvcmNlIGl0IHRvIHRoZSBvcmRlciBvZiB0 aGUgc3RydWN0IGRlZmluaXRpb24pLiBTbyB5b3UgaGF2ZSBubyB3YXkgb2YgYmVpbmcgYWJsZSB0 byB2ZXJpZnkgdGhlIGhhc2ggYWZ0ZXIgaXQgaGFzIGJlZW4gdW5tYXJzaGFsLWVkLiAgRnVydGhl ciwgaWYgeW91IHJlY3JlYXRlIHRoZSBKU09OIGFuZCBzZW5kIGl0IGJhY2sgb3V0LCB0aGUgbmV4 dCBwZXJzb24gdGhhdCBnZXRzIHRoZSBkYXRhIG1pZ2h0IGhhdmUgYSBoYXNoIHRoYXQgY2FuIG5v dCBiZSB2ZXJpZmllZCBpbiBvcHRpb24gMSBhYm92ZS4NCg0KUmlnaHQsIHRoZXJlZm9yZSBvcHRp b24gMSBpcyBub3QgdmVyeSB1c2VmdWwuICBTb3J0aW5nIG9mIGtleXMgaXMgdGhlIGN1cmUgZm9y IHRoaXMgaXNzdWUuDQoNCg0KMykgQW5vdGhlciBwcm9ibGVtIG9uY2UgeW91IGhhdmUgdW5tYXJz aGFsLWVkIHRoZSBkYXRhIGlzIHdoYXQgZG8geW91IGRvIHdpdGggSlNPTiBudW1iZXJzLg0KDQpS aWdodCwgYnV0IGV2ZW4gc3RyaW5nIGRhdGEgbmVlZHMgYWRqdXN0bWVudHMuICAiXHUwMDIwIiBh bmQgIiAiIGJvdGggcmVwcmVzZW50cyBhIHNwYWNlIGNoYXJhY3Rlci4NCg0KDQpTb21lIHByb2dy YW1taW5nIGxhbmd1YWdlcyBzdG9yZSB0aGVtIGFzIGEgZmxvYXQsIHNvbWUgYXMgd2hvLWtub3dz LXdoYXQuICBTbyB5b3Ugd291bGQgbmVlZCBhIHdheSB0byBlbnN1cmUgdGhhdCB0aGUgbnVtYmVy IHdhcyBhbHdheXMgc3RvcmVkIGluIHRoZSBzYW1lIHdheSwgZXNwZWNpYWxseSBmb3Igc3Ryb25n bHkgdHlwZWQgc3lzdGVtcyAoaXMgdGhpcyBhcmNoaXRlY3R1cmUgZGVwZW5kZW50IHRvbz8pLiBT byB0aGUgb3B0aW9ucyBoZXJlIGFyZSwgaWYgdGhlIG9udG9sb2d5IC8gc2VtYW50aWNzIG9mIHRo ZSBKU09OIGRhdGEgd2VyZSB3ZWxsIGRlZmluZWQgaW4gc2NoZW1hIChhIG1lYW5pbmcgaXQgd2Fz IHN0YW5kYXJkaXplZCBhbmQgZG9jdW1lbnRlZCksIHRoZW4gdGhlIGNvZGUgY291bGQga25vdyB3 aGF0IGl0IHNob3VsZCBkbyBhbmQgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cyBjb3VsZCBiZSBtYWRl IHRvIGVuc3VyZSB0aGF0IGl0IHdvcmtlZC4NCg0KVGhpcyBpcyAoSU1PKSB0aGUgb25seSBwYXJ0 IG9mIHRoZSBwdXp6bGUgdGhhdCBpcyBub24tdHJpdmlhbC4gIEluIG15IHRha2Ugb24gdGhlIG1h dHRlciwgSSBoYXZlICJwcmVzY3JpYmVkIiB0aGF0IHRoZSBKU09OIE51bWJlciB0eXBlIG11c3Qg YmUgY29lcmNlZCBpbnRvIGFuIElFRUUgNzU0IGRvdWJsZSBwcmVjaXNpb24gbnVtYmVyIGFuZCBi ZSBzZXJpYWxpemVkIGFjY29yZGluZyB0byBFQ01BU2NyaXB0IFY2KyBydWxlcy4NCg0KSWYgeW91 ciBhcHBsaWNhdGlvbiBuZWVkcyBoaWdoZXIgcHJlY2lzaW9uIG9yIGJpZ2dlciByYW5nZSwgeW91 IGFyZSBmb3JjZWQgdXNpbmcgdGhlIHF1b3RlZCBzdHJpbmcgbm90YXRpb24gd2hpY2ggKEFGQUlL Li4uKSBpcyB1c2VkIGJ5IGV2ZXJ5IElFVEYgc3RhbmRhcmQgb2YgYW55IHNpZ25pZmljYW5jZSB0 byBkYXRlIGRlZmluaW5nIGEgSlNPTiBzdHJ1Y3R1cmUuDQoNCg0KV2hhdCBhbSBJIG5vdCB1bmRl cnN0YW5kaW5nIGhlcmU/ICBBbmQgd2hhdCBhbSBJIG1pc3Npbmc/DQoNCg0KQXMgSSB3cm90ZSBl YXJsaWVyLCB0aGVyZSBhcmUgKGF0IGxlYXN0KSB0d28gZW50aXJlbHkgZGlmZmVyZW50IGFuZCBk b2N1bWVudGVkIGFwcHJvYWNoZXMuDQoNClVzaW5nIGEgc2NoZW1hIGJhc2VkIGNhbm9uaWNhbGl6 ZXIgYXMgeW91IG1lbnRpb24gaXMgYWxzbyBhbiBvcHRpb24gYnV0IHRoYXQgaXMgYSBtdWNoIG1v cmUgYW1iaXRpb3VzIHByb2plY3QuDQoNClJlZ2FyZHMsDQpBbmRlcnMNCg0KDQpUaGFua3MsDQpC cmV0DQpQR1AgRmluZ2VycHJpbnQ6IDYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAgRjJDMCA3NEY4 IEFDQUUgNzQxNSAwMDUwDQoiV2l0aG91dCBjcnlwdG9ncmFwaHkgdmlodiB2aXZjIGNlIHhocm5y dywgaG93ZXZlciwgdGhlIG9ubHkgdGhpbmcgdGhhdCBjYW4gbm90IGJlIHVuc2NyYW1ibGVkIGlz IGFuIGVnZy4iDQpPbiBPY3QgMTIsIDIwMTgsIGF0IDEyOjM4IEFNLCBBbmRlcnMgUnVuZGdyZW4g PGFuZGVycy5ydW5kZ3Jlbi5uZXRAZ21haWwuY29tPG1haWx0bzphbmRlcnMucnVuZGdyZW4ubmV0 QGdtYWlsLmNvbT4gPG1haWx0bzphbmRlcnMucnVuZGdyZW4ubmV0QGdtYWlsLmNvbT4+IHdyb3Rl Og0KDQpPbiAyMDE4LTEwLTExIDIyOjA1LCBCcmV0IEpvcmRhbiB3cm90ZToNCkFuZGVycywNCkkg cmVhbGx5IGxpa2Ugd2hhdCB5b3UgaGF2ZSBkb25lIHdpdGggdGhpcy4gIEkgYW0gdHJ5aW5nIHRv IGZpZ3VyZSBvdXQgaWYgaXQgd2lsbCB3b3JrIDEwMCUgZm9yIG15IG5lZWRzLCBvciBpZiBpdCB3 aWxsIG5lZWQgc29tZSB0d2Vha2luZy4gIElmIGl0IGRvZXMgd29yaywgdGhlbiBJIHRoaW5rIHdl IHNob3VsZCByZWFsbHkgdHJ5IGFuZCBmaWd1cmUgb3V0IGhvdyB3ZSBnZXQgeW91ciB3b3JrIHN0 YW5kYXJkaXplZC4NCg0KVGhhbnggQnJldCENCg0KVGhlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1lcmR0bWFuLWpvc2UtY2xlYXJ0ZXh0LWp3cy0wMSBJLUQgcHJvdmlkZXMgcXVp dGUgYSBsb3Qgb2YgZmVhdHVyZXMgaW5jbHVkaW5nIGFuIGV4dGVuc2lvbiBvcHRpb24gdGhhdCBj YW4gYmUgdXNlZCBmb3IgYWRkaW5nIHBvc3NpYmx5IG1pc3NpbmcgZnVuY3Rpb25hbGl0eS4NCg0K VGhlcmUgaXMgb25lIHRoaW5nIHRoYXQgaXMgZ29vZCB0byBrbm93IGZvciBhbnlvbmUgdGhpbmtp bmcgYWJvdXQgc3RhbmRhcmRpemluZyBDYW5vbmljYWwgSlNPTiBhbmQgdGhhdCdzIHRoZSBmYWN0 IHRoYXQgY2Fub25pY2FsaXphdGlvbiBhbHNvIGNhbiBiZSBwZXJmb3JtZWQgb24gdGhlIHRleHQg bGV2ZWwgYXMgZGVzY3JpYmVkIGJ5OiBodHRwczovL2dpYnNvbjA0Mi5naXRodWIuaW8vY2Fub25p Y2FsanNvbi1zcGVjLw0KDQpUaGlzIGhhcyB0aGUgYWR2YW50YWdlIHRoYXQgaXQgaXMgdmVyeSBz aW1wbGUgYW5kIHN1cHBvcnRzIHRoZSBlbnRpcmUgSlNPTiBSRkMgd2l0aG91dCByZXN0cmljdGlv bnMuDQoNCg0KU28gd2h5IGRpZG4ndCBJIHRvb2sgdGhpcyBbc3VwZXJmaWNpYWxseSBvYnZpb3Vz XSByb3V0ZT8gVGhlcmUgYXJlIHNldmVyYWwgcmVhc29ucyBmb3IgdGhhdDoNCg0KQSBkb3duc2lk ZSBvZiBzb3VyY2UgbGV2ZWwgY2Fub25pY2FsaXphdGlvbiBpcyB0aGF0IGl0IGRvZXNuJ3QgaW50 ZWdyYXRlIHdpdGggSlNPTiBwYXJzZXJzIGFuZCBzZXJpYWxpemVycy4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXJ1bmRncmVuLWpzb24tY2Fub25pY2FsaXphdGlvbi1zY2hlbWUt MDEgd2FzIGV4cGxpY2l0bHkgZGVzaWduZWQgdG8gZXZlbnR1YWxseSBiZSBhbiBvcHRpb24gb2Yg YSBzdGFuZGFyZCBKU09OIHNlcmlhbGl6ZXIgYXMgaXQgYWxyZWFkeSBpcyBpbiBteSBKYXZhIHJl ZmVyZW5jZSBpbXBsZW1lbnRhdGlvbi4NCg0KQW5vdGhlciBpc3N1ZSBpcyB0aGF0IGl0IGlzIHVu Y2xlYXIgd2hhdCB0aGUgdmFsdWUgaXMgd2l0aCB1c2luZyB0aGUgSlNPTiAiTnVtYmVyIiBmb3Jt YXQgb3V0c2lkZSBvZiB0aGUgSUVFRSByYW5nZS4gIEluIGZhY3QsIGl0IGV4Y2x1ZGVzIHBhcnNl cnMgbGlrZSBKYXZhU2NyaXB0J3MgSlNPTi5wYXJzZSgpIHVubGVzcyBKYXZhU2NhcmlwdCB3b3Vs ZCBiZSB1cGRhdGVkIHRvIGFsd2F5cyB1c2UgYSAiQmlnTnVtYmVyIiBhcyBmdW5kYW1lbnRhbCBu dW1lcmljIHR5cGUuDQoNClJlZ2FyZHMsDQpBbmRlcnMNCg0KDQo= --_000_BL0PR02MB4276166633D32020763F97C4B7FE0BL0PR02MB4276namp_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+DQo8ZGl2IHN0eWxlPSJmb250LXNp emU6ODUlO2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2Fs YXh5IFM4LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8IS0t IG9yaWdpbmFsTWVzc2FnZSAtLT4NCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0tLTwvZGl2Pg0KPGRpdj5Gcm9tOiBCcmV0IEpvcmRhbiAmbHQ7am9yZGFuLmlldGZAZ21haWwu Y29tJmd0OyA8L2Rpdj4NCjxkaXY+RGF0ZTogMTAvMTMvMTggNjozMiBBTSAoR01UJiM0MzswOTow MCkgPC9kaXY+DQo8ZGl2PlRvOiBBbmRlcnMgUnVuZGdyZW4gJmx0O2FuZGVycy5ydW5kZ3Jlbi5u ZXRAZ21haWwuY29tJmd0OyA8L2Rpdj4NCjxkaXY+Q2M6IENhcnN0ZW4gQm9ybWFubiAmbHQ7Y2Fi b0B0emkub3JnJmd0OywgJnF1b3Q7TWFuZ2VyLCBKYW1lcyZxdW90OyAmbHQ7SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbSZndDssIEthdGhsZWVuIE1vcmlhcnR5ICZsdDtrYXRobGVlbi5t b3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSZndDssIGpvc2VAaWV0Zi5vcmcsIFBoaWwgSHVudCAmbHQ7 cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7DQo8L2Rpdj4NCjxkaXY+U3ViamVjdDogUmU6IFtqb3Nl XSBDYW5vbmljYWwgSlNPTiBmb3JtIDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0t Pg0KPGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+DQo8ZGl2PkZy b206IEJyZXQgSm9yZGFuICZsdDtqb3JkYW4uaWV0ZkBnbWFpbC5jb20mZ3Q7IDwvZGl2Pg0KPGRp dj5EYXRlOiAxMC8xMy8xOCA2OjMyIEFNIChHTVQmIzQzOzA5OjAwKSA8L2Rpdj4NCjxkaXY+VG86 IEFuZGVycyBSdW5kZ3JlbiAmbHQ7YW5kZXJzLnJ1bmRncmVuLm5ldEBnbWFpbC5jb20mZ3Q7IDwv ZGl2Pg0KPGRpdj5DYzogQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7LCAmcXVv dDtNYW5nZXIsIEphbWVzJnF1b3Q7ICZsdDtKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29t Jmd0OywgS2F0aGxlZW4gTW9yaWFydHkgJmx0O2thdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwu Y29tJmd0Oywgam9zZUBpZXRmLm9yZywgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNv bSZndDsNCjwvZGl2Pg0KPGRpdj5TdWJqZWN0OiBSZTogW2pvc2VdIENhbm9uaWNhbCBKU09OIGZv cm0gPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQpBbmRlcnMsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3cgZG8gd2UgbW92ZSBm b3J3YXJkPyAmbmJzcDtXaGF0IGNhbiB3ZSBkbyB0byBtYWtlIHRoaXMgaGFwcGVuPzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7IGZv bnQtZmFtaWx5OkhlbHZldGljYTsgZm9udC1zaXplOjE0cHg7IGZvbnQtc3R5bGU6bm9ybWFsOyBm b250LXdlaWdodDpub3JtYWw7IGxldHRlci1zcGFjaW5nOm5vcm1hbDsgb3JwaGFuczphdXRvOyB0 ZXh0LWFsaWduOnN0YXJ0OyB0ZXh0LWluZGVudDowcHg7IHRleHQtdHJhbnNmb3JtOm5vbmU7IHdo aXRlLXNwYWNlOm5vcm1hbDsgd2lkb3dzOmF1dG87IHdvcmQtc3BhY2luZzowcHg7IHRleHQtZGVj b3JhdGlvbjpub25lIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9Im9ycGhhbnM6Mjsgd2lkb3dzOjI7 IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxl PSJib3JkZXItY29sbGFwc2U6c2VwYXJhdGU7IGxpbmUtaGVpZ2h0Om5vcm1hbDsgYm9yZGVyLXNw YWNpbmc6MHB4Ij5UaGFua3MsPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0ib3Jw aGFuczoyOyB3aWRvd3M6MjsgbGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTsgbGluZS1oZWlnaHQ6 bm9ybWFsOyBib3JkZXItc3BhY2luZzowcHgiPkJyZXQ8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiIHN0eWxlPSJvcnBoYW5zOjI7IHdpZG93czoyIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUt c3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTsgYm9yZGVyLXNwYWNpbmc6MHB4 Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpz ZXBhcmF0ZTsgYm9yZGVyLXNwYWNpbmc6MHB4Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkOyBsaW5lLWJyZWFrOmFmdGVyLXdoaXRlLXNwYWNlIj48c3BhbiBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTsgYm9y ZGVyLXNwYWNpbmc6MHB4Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkOyBsaW5lLWJyZWFrOmFmdGVyLXdoaXRlLXNwYWNlIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTsgYm9yZGVyLXNwYWNpbmc6 MHB4Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkOyBsaW5lLWJy ZWFrOmFmdGVyLXdoaXRlLXNwYWNlIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5 bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTsgYm9yZGVyLXNwYWNpbmc6MHB4Ij4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY29sb3I9IiM3YzdjN2MiIGZhY2U9IkNhbGlicmUsIFZlcmRhbmEiIGNs YXNzPSIiIHN0eWxlPSJsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJm b250LXNpemU6MTFweCI+UEdQIEZpbmdlcnByaW50OiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4g Y2xhc3M9IiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB4Ij48Zm9udCBjb2xvcj0iIzdjN2M3YyIgZmFj ZT0iQ2FsaWJyZSwgVmVyZGFuYSIgY2xhc3M9IiI+NjNCNA0KIEZDNTMgNjgwQSA2QjdEIDE0NDcg Jm5ic3A7RjJDMCA3NEY4IEFDQUUgNzQxNSAwMDUwPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYg Y2xhc3M9IiIgc3R5bGU9ImxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9 ImNvbG9yOnJnYigxMjQsMTI0LDEyNCk7IGZvbnQtc2l6ZTo4cHQ7IGZvbnQtZmFtaWx5OkNhbGli cmUsVmVyZGFuYSI+JnF1b3Q7V2l0aG91dCBjcnlwdG9ncmFwaHkgdmlodiB2aXZjIGNlIHhocm5y dywgaG93ZXZlciwgdGhlIG9ubHkgdGhpbmcgdGhhdCBjYW4gbm90IGJlIHVuc2NyYW1ibGVkIGlz IGFuIGVnZy4mcXVvdDs8L3NwYW4+PC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L3NwYW4+PC9kaXY+ DQo8L3NwYW4+PC9kaXY+DQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIE9jdCAxMiwgMjAxOCwgYXQgMTA6NDcgQU0sIEFuZGVycyBSdW5kZ3JlbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFuZGVycy5ydW5kZ3Jlbi5uZXRAZ21haWwuY29tIiBjbGFzcz0i Ij5hbmRlcnMucnVuZGdyZW4ubmV0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIDIwMTgtMTAtMTIgMTc6MjAsIEJyZXQgSm9yZGFuIHdyb3RlOjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlBsZWFzZSBjb3JyZWN0IG1l IGlmIEkgYW0gd3JvbmfigKYuIFRoZSB3YXkgSSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIGlzIGFz IGZvbGxvd3M6PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSGkg QnJldCw8YnIgY2xhc3M9IiI+DQpDb21tZW50cyBpbiBsaW5lLi4uPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+MSkgSWYgeW91IHZlcmlmaWVkIHRoZSBKU09O IHN0cmluZyBhdCBjb25zdW1wdGlvbiB0aW1lLCBiZWZvcmUgaXQgaGFzIGJlZW4gdW5tYXJzaGFs LWVkLCB0aGVuIGFsbCB5b3UgbmVlZCB0byBkbyBpcyBkZWNpZGUgaG93IHRvIGhhbmRsZSB3aGl0 ZSBzcGFjZSBhbmQgY2FycmlhZ2UgcmV0dXJucy4gJm5ic3A7WW91IGNvdWxkIGJhc2ljYWxseSBy ZWdleCByZW1vdmUgYWxsIHdoaXRlIHNwYWNlIGFuZA0KIENSIC8gQ1JMRiBhbmQgaGF2ZSBhIHdv cmthYmxlIHNvbHV0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0i Ij4NCkl0IGRlcGVuZHMgb24gd2hhdCB5b3VyIGdvYWwgaXMuICZuYnNwO0Nhbm9uaWNhbGl6YXRp b24gYnVpbGRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgaXMgYSB1bmlxdWUgcmVwcmVz ZW50YXRpb24gb2YgdGhlIGRhdGEsIHByZWZlcmFibHkgZXZlbiBhZnRlciBpdCBoYXMgcGFzc2Vk IHRocm91Z2ggYSBwcm9jZXNzb3IgbGlrZSBhbiBpbnRlcm1lZGlhcnkuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+MikgV2hlcmUg dGhpcyBicmVha3MgZG93biBpcywgd2hlbiBhIHRvb2wgdW5tYXJzaGFscyB0aGUgZGF0YSBpbnRv IGEgbWFwIG9yIHN0cnVjdCwgdGhlbiB5b3UgaGF2ZSBubyBndWFyYW50ZWUgdGhhdCB5b3Ugd291 bGQgcmVjcmVhdGUgdGhlIGtleXMgaW4gdGhlIHNhbWUgb3JkZXIgKGEgc3RydWN0IG1heSBmb3Jj ZSBpdCB0byB0aGUgb3JkZXIgb2YgdGhlIHN0cnVjdCBkZWZpbml0aW9uKS4NCiBTbyB5b3UgaGF2 ZSBubyB3YXkgb2YgYmVpbmcgYWJsZSB0byB2ZXJpZnkgdGhlIGhhc2ggYWZ0ZXIgaXQgaGFzIGJl ZW4gdW5tYXJzaGFsLWVkLiAmbmJzcDtGdXJ0aGVyLCBpZiB5b3UgcmVjcmVhdGUgdGhlIEpTT04g YW5kIHNlbmQgaXQgYmFjayBvdXQsIHRoZSBuZXh0IHBlcnNvbiB0aGF0IGdldHMgdGhlIGRhdGEg bWlnaHQgaGF2ZSBhIGhhc2ggdGhhdCBjYW4gbm90IGJlIHZlcmlmaWVkIGluIG9wdGlvbiAxIGFi b3ZlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClJpZ2h0LCB0 aGVyZWZvcmUgb3B0aW9uIDEgaXMgbm90IHZlcnkgdXNlZnVsLiAmbmJzcDtTb3J0aW5nIG9mIGtl eXMgaXMgdGhlIGN1cmUgZm9yIHRoaXMgaXNzdWUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+MykgQW5v dGhlciBwcm9ibGVtIG9uY2UgeW91IGhhdmUgdW5tYXJzaGFsLWVkIHRoZSBkYXRhIGlzIHdoYXQg ZG8geW91IGRvIHdpdGggSlNPTiBudW1iZXJzLg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KUmlnaHQsIGJ1dCBldmVuIHN0cmluZyBkYXRhIG5lZWRzIGFkanVz dG1lbnRzLiAmbmJzcDsmcXVvdDtcdTAwMjAmcXVvdDsgYW5kICZxdW90OyAmcXVvdDsgYm90aCBy ZXByZXNlbnRzIGEgc3BhY2UgY2hhcmFjdGVyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlNvbWUgcHJv Z3JhbW1pbmcgbGFuZ3VhZ2VzIHN0b3JlIHRoZW0gYXMgYSBmbG9hdCwgc29tZSBhcyB3aG8ta25v d3Mtd2hhdC4gJm5ic3A7U28geW91IHdvdWxkIG5lZWQgYSB3YXkgdG8gZW5zdXJlIHRoYXQgdGhl IG51bWJlciB3YXMgYWx3YXlzIHN0b3JlZCBpbiB0aGUgc2FtZSB3YXksIGVzcGVjaWFsbHkgZm9y IHN0cm9uZ2x5IHR5cGVkIHN5c3RlbXMgKGlzIHRoaXMgYXJjaGl0ZWN0dXJlIGRlcGVuZGVudA0K IHRvbz8pLiBTbyB0aGUgb3B0aW9ucyBoZXJlIGFyZSwgaWYgdGhlIG9udG9sb2d5IC8gc2VtYW50 aWNzIG9mIHRoZSBKU09OIGRhdGEgd2VyZSB3ZWxsIGRlZmluZWQgaW4gc2NoZW1hIChhIG1lYW5p bmcgaXQgd2FzIHN0YW5kYXJkaXplZCBhbmQgZG9jdW1lbnRlZCksIHRoZW4gdGhlIGNvZGUgY291 bGQga25vdyB3aGF0IGl0IHNob3VsZCBkbyBhbmQgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cyBjb3Vs ZCBiZSBtYWRlIHRvIGVuc3VyZSB0aGF0IGl0IHdvcmtlZC48YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGlzIChJTU8pIHRoZSBvbmx5IHBhcnQgb2YgdGhl IHB1enpsZSB0aGF0IGlzIG5vbi10cml2aWFsLiAmbmJzcDtJbiBteSB0YWtlIG9uIHRoZSBtYXR0 ZXIsIEkgaGF2ZSAmcXVvdDtwcmVzY3JpYmVkJnF1b3Q7IHRoYXQgdGhlIEpTT04gTnVtYmVyIHR5 cGUgbXVzdCBiZSBjb2VyY2VkIGludG8gYW4gSUVFRSA3NTQgZG91YmxlIHByZWNpc2lvbiBudW1i ZXIgYW5kIGJlIHNlcmlhbGl6ZWQgYWNjb3JkaW5nIHRvIEVDTUFTY3JpcHQgVjYmIzQzOyBydWxl cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiB5b3VyIGFwcGxpY2F0aW9uIG5lZWRz IGhpZ2hlciBwcmVjaXNpb24gb3IgYmlnZ2VyIHJhbmdlLCB5b3UgYXJlIGZvcmNlZCB1c2luZyB0 aGUgcXVvdGVkIHN0cmluZyBub3RhdGlvbiB3aGljaCAoQUZBSUsuLi4pIGlzIHVzZWQgYnkgZXZl cnkgSUVURiBzdGFuZGFyZCBvZiBhbnkgc2lnbmlmaWNhbmNlIHRvIGRhdGUgZGVmaW5pbmcgYSBK U09OIHN0cnVjdHVyZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5XaGF0IGFtIEkgbm90IHVuZGVyc3Rh bmRpbmcgaGVyZT8gJm5ic3A7QW5kIHdoYXQgYW0gSSBtaXNzaW5nPzxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIEkgd3JvdGUgZWFy bGllciwgdGhlcmUgYXJlIChhdCBsZWFzdCkgdHdvIGVudGlyZWx5IGRpZmZlcmVudCBhbmQgZG9j dW1lbnRlZCBhcHByb2FjaGVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClVzaW5nIGEg c2NoZW1hIGJhc2VkIGNhbm9uaWNhbGl6ZXIgYXMgeW91IG1lbnRpb24gaXMgYWxzbyBhbiBvcHRp b24gYnV0IHRoYXQgaXMgYSBtdWNoIG1vcmUgYW1iaXRpb3VzIHByb2plY3QuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KUmVnYXJkcyw8YnIgY2xhc3M9IiI+DQpBbmRlcnM8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj5UaGFua3MsPGJyIGNsYXNzPSIiPg0KQnJldDxiciBjbGFzcz0iIj4NClBHUCBG aW5nZXJwcmludDogNjNCNCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICZuYnNwO0YyQzAgNzRGOCBBQ0FF IDc0MTUgMDA1MDxiciBjbGFzcz0iIj4NCiZxdW90O1dpdGhvdXQgY3J5cHRvZ3JhcGh5IHZpaHYg dml2YyBjZSB4aHJucncsIGhvd2V2ZXIsIHRoZSBvbmx5IHRoaW5nIHRoYXQgY2FuIG5vdCBiZSB1 bnNjcmFtYmxlZCBpcyBhbiBlZ2cuJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+T24gT2N0IDEyLCAyMDE4LCBhdCAxMjozOCBBTSwgQW5kZXJzIFJ1 bmRncmVuICZsdDs8YSBocmVmPSJtYWlsdG86YW5kZXJzLnJ1bmRncmVuLm5ldEBnbWFpbC5jb20i IGNsYXNzPSIiPmFuZGVycy5ydW5kZ3Jlbi5uZXRAZ21haWwuY29tPC9hPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFuZGVycy5ydW5kZ3Jlbi5uZXRAZ21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86YW5k ZXJzLnJ1bmRncmVuLm5ldEBnbWFpbC5jb208L2E+Jmd0OyZndDsNCiB3cm90ZTo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAyMDE4LTEwLTExIDIyOjA1LCBCcmV0IEpvcmRhbiB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BbmRlcnMs PGJyIGNsYXNzPSIiPg0KSSByZWFsbHkgbGlrZSB3aGF0IHlvdSBoYXZlIGRvbmUgd2l0aCB0aGlz LiAmbmJzcDtJIGFtIHRyeWluZyB0byBmaWd1cmUgb3V0IGlmIGl0IHdpbGwgd29yayAxMDAlIGZv ciBteSBuZWVkcywgb3IgaWYgaXQgd2lsbCBuZWVkIHNvbWUgdHdlYWtpbmcuICZuYnNwO0lmIGl0 IGRvZXMgd29yaywgdGhlbiBJIHRoaW5rIHdlIHNob3VsZCByZWFsbHkgdHJ5IGFuZCBmaWd1cmUg b3V0IGhvdyB3ZSBnZXQgeW91ciB3b3JrIHN0YW5kYXJkaXplZC48YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpUaGFueCBCcmV0ITxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClRoZSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZXJkdG1hbi1qb3NlLWNsZWFydGV4dC1qd3MtMDEiIGNsYXNzPSIiIHRhcmdldD0iX0JMQU5LIj4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lcmR0bWFuLWpvc2UtY2xlYXJ0ZXh0 LWp3cy0wMTwvYT4gSS1EIHByb3ZpZGVzIHF1aXRlIGEgbG90IG9mIGZlYXR1cmVzIGluY2x1ZGlu ZyBhbiBleHRlbnNpb24gb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGFkZGluZyBwb3NzaWJs eSBtaXNzaW5nIGZ1bmN0aW9uYWxpdHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhl cmUgaXMgb25lIHRoaW5nIHRoYXQgaXMgZ29vZCB0byBrbm93IGZvciBhbnlvbmUgdGhpbmtpbmcg YWJvdXQgc3RhbmRhcmRpemluZyBDYW5vbmljYWwgSlNPTiBhbmQgdGhhdCdzIHRoZSBmYWN0IHRo YXQgY2Fub25pY2FsaXphdGlvbiBhbHNvIGNhbiBiZSBwZXJmb3JtZWQgb24gdGhlIHRleHQgbGV2 ZWwgYXMgZGVzY3JpYmVkIGJ5Og0KPGEgaHJlZj0iaHR0cHM6Ly9naWJzb24wNDIuZ2l0aHViLmlv L2Nhbm9uaWNhbGpzb24tc3BlYy8iIGNsYXNzPSIiIHRhcmdldD0iX0JMQU5LIj4NCmh0dHBzOi8v Z2lic29uMDQyLmdpdGh1Yi5pby9jYW5vbmljYWxqc29uLXNwZWMvPC9hPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRoaXMgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCBpdCBpcyB2ZXJ5IHNp bXBsZSBhbmQgc3VwcG9ydHMgdGhlIGVudGlyZSBKU09OIFJGQyB3aXRob3V0IHJlc3RyaWN0aW9u cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbyB3aHkgZGlk bid0IEkgdG9vayB0aGlzIFtzdXBlcmZpY2lhbGx5IG9idmlvdXNdIHJvdXRlPyBUaGVyZSBhcmUg c2V2ZXJhbCByZWFzb25zIGZvciB0aGF0OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEg ZG93bnNpZGUgb2Ygc291cmNlIGxldmVsIGNhbm9uaWNhbGl6YXRpb24gaXMgdGhhdCBpdCBkb2Vz bid0IGludGVncmF0ZSB3aXRoIEpTT04gcGFyc2VycyBhbmQgc2VyaWFsaXplcnMuDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcnVuZGdyZW4tanNvbi1jYW5vbmlj YWxpemF0aW9uLXNjaGVtZS0wMSIgY2xhc3M9IiIgdGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJ1bmRncmVuLWpzb24tY2Fub25pY2FsaXphdGlvbi1z Y2hlbWUtMDE8L2E+IHdhcyBleHBsaWNpdGx5IGRlc2lnbmVkIHRvIGV2ZW50dWFsbHkgYmUgYW4g b3B0aW9uIG9mIGEgc3RhbmRhcmQgSlNPTiBzZXJpYWxpemVyIGFzIGl0IGFscmVhZHkgaXMgaW4g bXkgSmF2YSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQW5vdGhlciBpc3N1ZSBpcyB0aGF0IGl0IGlzIHVuY2xlYXIgd2hhdCB0aGUgdmFsdWUg aXMgd2l0aCB1c2luZyB0aGUgSlNPTiAmcXVvdDtOdW1iZXImcXVvdDsgZm9ybWF0IG91dHNpZGUg b2YgdGhlIElFRUUgcmFuZ2UuICZuYnNwO0luIGZhY3QsIGl0IGV4Y2x1ZGVzIHBhcnNlcnMgbGlr ZSBKYXZhU2NyaXB0J3MgSlNPTi5wYXJzZSgpIHVubGVzcyBKYXZhU2NhcmlwdCB3b3VsZCBiZSB1 cGRhdGVkIHRvIGFsd2F5cyB1c2UgYSAmcXVvdDtCaWdOdW1iZXImcXVvdDsgYXMgZnVuZGFtZW50 YWwNCiBudW1lcmljIHR5cGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVnYXJkcyw8 YnIgY2xhc3M9IiI+DQpBbmRlcnM8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL0PR02MB4276166633D32020763F97C4B7FE0BL0PR02MB4276namp_-- From nobody Fri Oct 19 21:55:37 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23835130E30 for ; Fri, 19 Oct 2018 21:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 Bfsf8QYJTlpe for ; Fri, 19 Oct 2018 21:55:34 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 E84B7130E28 for ; Fri, 19 Oct 2018 21:55:33 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id 61-v6so39382881wrb.6 for ; Fri, 19 Oct 2018 21:55:33 -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=zMIvBii1R1D9d1jKJwGKluNV/3Nx9XY8a8HdJ38aLAs=; b=ovkkbrVA3RLcyyT91W2McUWnk0HbyeDxpAZNmVJop6WEW+oNPeMlFBTvM3yo6xPrZF xSmP+tsp4gHYH4OMDdnYe1lNgrJohUzZ8JUKZNBKLBAaDsTtB8KNGMSqOj66sJgqkFKZ 8F3dCgkxfGUMDq5vomiACX9cLXiICsOvk+MHqxtzKsfxJo2PGfIsl4IQMW47+YiiPY31 I2Mj1blYVjrNvRHZIKZOrvhULHvm+QlH/AiTXKKpNCzrwXCbLwVBXZeifP7s82lSNK3u SpY61vKYL731ix8rhJuQAyuE1iwCLzCc8GiflBEvaEegewuyUl5rlLG0BjDV5Xhq+SWR ZVwQ== 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=zMIvBii1R1D9d1jKJwGKluNV/3Nx9XY8a8HdJ38aLAs=; b=pgtumDDH5jkyjUoL3XNVEVOAzo96qsPm1JkgxxAguifvce/M6p2T4Zz+X6kEnmjnYM fbFoy9TNGfls446zLfiPLqmgVp5l9rNFalHH9i/W40Wu7B+SfiXpCPbq5eGUHowGxY3E qZLa6HEfhc/BnmNvsofgEY1Jj48LxwGOeg9D4CvBJ2GUeMVDmkgHW7dYK91YBS+Cr7lM aI4lyU7LcTUVPTQ3DEeFfuvCRe2m8Dj/VuvGhFwhPomoOIUe4sLAqoE+16xfpnCVcOIF 7bj7ZRWfjvxPp807icx+ZdIW+M+HR59tFVsNTuZcb3aSn0NsBUVwsTiLGASFs1nijsX3 JAug== X-Gm-Message-State: ABuFfogjf0Bk7Ud5wZR1/mrwRgKj5YW3gzPioezm5iZHzMYLoxo/WPkU uk4YGE3wntlNJf4JaE8ZtTo0KD74 X-Google-Smtp-Source: ACcGV60Egx2TV2o/oogcUteECGhuaceL3S3xk4Qbmdse6+b2GRS2zbsNZwOPr0yDEKsfcjFRpdxnrg== X-Received: by 2002:adf:9e09:: with SMTP id u9-v6mr35411898wre.51.1540011331635; Fri, 19 Oct 2018 21:55:31 -0700 (PDT) Received: from [192.168.10.182] (236.204.154.77.rev.sfr.net. [77.154.204.236]) by smtp.googlemail.com with ESMTPSA id y41-v6sm6132879wrd.25.2018.10.19.21.55.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 21:55:29 -0700 (PDT) To: Bret Jordan Cc: Carsten Bormann , Phil Hunt , Kathleen Moriarty , "Manger, James" , jose@ietf.org References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> From: Anders Rundgren Message-ID: <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> Date: Sat, 20 Oct 2018 06:55:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 04:55:36 -0000 On 2018-10-12 23:31, Bret Jordan wrote: > Anders, > > How do we move forward?  What can we do to make this happen? As you can see from the responses, there is considerable resistance and skepticism against this work. I guess even fewer have bothered reading the actual I-D. Personally I don't care that much since the JSON based systems I work with have up to 5 layers of signatures which doesn't translate well to the current JOSE standards. Maybe the other editors of https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 (which builds on a flavor of Canonical JSON) have an idea? There is also a (very active) W3C community group working with a similar concept so clear-text signatures based on JSON canonicalization will probably reach the market regardless of IETF's position on the matter: https://w3c-dvcg.github.io/ld-signatures/ The 1 million of random and "edge" JSON Numbers used for testing the devised JSON canonicalization scheme, uncovered flaws in other systems as well... https://github.com/dotnet/coreclr/issues/17467 Ciao, Anders > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > >> On Oct 12, 2018, at 10:47 AM, Anders Rundgren > wrote: >> >> On 2018-10-12 17:20, Bret Jordan wrote: >>> Please correct me if I am wrong…. The way I understand the problem is as follows: >> >> Hi Bret, >> Comments in line... >>> 1) If you verified the JSON string at consumption time, before it has been unmarshal-ed, then all you need to do is decide how to handle white space and carriage returns.  You could basically regex remove all white space and CR / CRLF and have a workable solution. >> >> It depends on what your goal is.  Canonicalization builds on the assumption that there is a unique representation of the data, preferably even after it has passed through a processor like an intermediary. >> >>> 2) Where this breaks down is, when a tool unmarshals the data into a map or struct, then you have no guarantee that you would recreate the keys in the same order (a struct may force it to the order of the struct definition). So you have no way of being able to verify the hash after it has been unmarshal-ed.  Further, if you recreate the JSON and send it back out, the next person that gets the data might have a hash that can not be verified in option 1 above. >> >> Right, therefore option 1 is not very useful.  Sorting of keys is the cure for this issue. >> >> >>> 3) Another problem once you have unmarshal-ed the data is what do you do with JSON numbers. >> >> Right, but even string data needs adjustments.  "\u0020" and " " both represents a space character. >> >> >>> Some programming languages store them as a float, some as who-knows-what.  So you would need a way to ensure that the number was always stored in the same way, especially for strongly typed systems (is this architecture dependent too?). So the options here are, if the ontology / semantics of the JSON data were well defined in schema (a meaning it was standardized and documented), then the code could know what it should do and interoperability tests could be made to ensure that it worked. >> >> This is (IMO) the only part of the puzzle that is non-trivial.  In my take on the matter, I have "prescribed" that the JSON Number type must be coerced into an IEEE 754 double precision number and be serialized according to ECMAScript V6+ rules. >> >> If your application needs higher precision or bigger range, you are forced using the quoted string notation which (AFAIK...) is used by every IETF standard of any significance to date defining a JSON structure. >> >> >>> What am I not understanding here?  And what am I missing? >> >> >> As I wrote earlier, there are (at least) two entirely different and documented approaches. >> >> Using a schema based canonicalizer as you mention is also an option but that is a much more ambitious project. >> >> Regards, >> Anders >> >> >>> Thanks, >>> Bret >>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." >>>> On Oct 12, 2018, at 12:38 AM, Anders Rundgren > wrote: >>>> >>>> On 2018-10-11 22:05, Bret Jordan wrote: >>>>> Anders, >>>>> I really like what you have done with this.  I am trying to figure out if it will work 100% for my needs, or if it will need some tweaking.  If it does work, then I think we should really try and figure out how we get your work standardized. >>>> >>>> Thanx Bret! >>>> >>>> The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D provides quite a lot of features including an extension option that can be used for adding possibly missing functionality. >>>> >>>> There is one thing that is good to know for anyone thinking about standardizing Canonical JSON and that's the fact that canonicalization also can be performed on the text level as described by: https://gibson042.github.io/canonicaljson-spec/ >>>> >>>> This has the advantage that it is very simple and supports the entire JSON RFC without restrictions. >>>> >>>> >>>> So why didn't I took this [superficially obvious] route? There are several reasons for that: >>>> >>>> A downside of source level canonicalization is that it doesn't integrate with JSON parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 was explicitly designed to eventually be an option of a standard JSON serializer as it already is in my Java reference implementation. >>>> >>>> Another issue is that it is unclear what the value is with using the JSON "Number" format outside of the IEEE range.  In fact, it excludes parsers like JavaScript's JSON.parse() unless JavaScaript would be updated to always use a "BigNumber" as fundamental numeric type. >>>> >>>> Regards, >>>> Anders >> > From nobody Sun Oct 21 17:16:24 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F85130DFB for ; Sun, 21 Oct 2018 17:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 E3peAX-1Mn55 for ; Sun, 21 Oct 2018 17:16:19 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 B2F4A130DF9 for ; Sun, 21 Oct 2018 17:16:19 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id o204-v6so1443934yba.9 for ; Sun, 21 Oct 2018 17:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=QDIcZ9JCQt+PK1LifnFcxD+1VbS7J6qkzrYJuca8TW8=; b=N0nrg1yZJg32SAlqTCADPto/XZ9mVGT1EaHrHoNUqoIVmk4Fjpmgk4XgM7/EQgKGbu +EspOPkc6a8m1leutfqV5GQ90ynYIHk1RVR91/eJDebyWLPO9GSkN2qkzx89XoiZ/ci+ pbOMvfEkVXM219CQa7B8CoOLJilMoYsrc467qsSTikeNYhwkm5xC1n2MA1YRSXoex0dx Ga0kXYjJykcR9Ged9VQr4d+OYeWEZd7AUhNK1X+VDngU1eiVzEbAY60ezUS62gGwFVK9 m9R1iT1CVWhILFIjd7xfrZ9Y80Cd2bbSVbFXrk8jzx4OGxzxFHTm0GFXjBM+prm4DBu6 Bp/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=QDIcZ9JCQt+PK1LifnFcxD+1VbS7J6qkzrYJuca8TW8=; b=qEDI8wMfDEGhtLXcRkKeYtMbnAoNrYcn9YsavCO4D+3NJ9eORXO7w9DRrxd8diBV22 E1I1wj726X87fd+1au7brzt/6dpl/+CAXweQP5CFuXPuy1XgJRpOU8ASF/byPXKcMmYK US3OT/ZVq7yRX4z1Bjo+TZ+eMIJvP1pEBH/iFzfuxzVv3C8r4L3/A7R5ICqWhklzO6S2 XCtDHt7yteMH+C2rnSTmFnMwiywpDb2YUNm0URVq9ymf6DQVG7mBIdwF0sV0r6Fv/hk1 7uZ2HOwYvpm+T8gY4znhFDMTNtMuoOI6apP/0lFUzieIgxUOPRnE+PpeBlZFJsDxt+3g 8tXg== X-Gm-Message-State: ABuFfojCZLwN3R9MKo/NoEVjmVNS6wCKEY9CWOv23AUxz4LckRQSCJgs Aex344RJUZvnM1TmLespK1ttP2fU X-Google-Smtp-Source: ACcGV61Ft/316bhGr2NaUzq6v+17U3KgGkwXL0tjsYYb2ckXB4i38hf5gKXZ1+VjOTkLvE8s4Q/PJQ== X-Received: by 2002:a25:c4c5:: with SMTP id u188-v6mr30393094ybf.424.1540167378855; Sun, 21 Oct 2018 17:16:18 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:5803:ffca:df13:4192? ([2605:a601:3260:266:5803:ffca:df13:4192]) by smtp.gmail.com with ESMTPSA id i128-v6sm7835971ywe.42.2018.10.21.17.16.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Oct 2018 17:16:17 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_39BD6B90-7EAE-4082-AB24-ABE0297D5F24" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 21 Oct 2018 18:15:32 -0600 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> To: Anders Rundgren , jose@ietf.org In-Reply-To: <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 00:16:22 -0000 --Apple-Mail=_39BD6B90-7EAE-4082-AB24-ABE0297D5F24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Anders, It is sad that we have to look at doing work outside of the IETF in = order to solve the needs of the market. But I would love to work with = you on this effort, even if it means doing it outside of the IETF. Your solution that uses 5 layers of signatures, which draft / document / = write up is this based on? I have a very similar need and would like = to try and do what ever you are doing.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 19, 2018, at 10:55 PM, Anders Rundgren = wrote: >=20 > On 2018-10-12 23:31, Bret Jordan wrote: >> Anders, >> How do we move forward? What can we do to make this happen? >=20 > As you can see from the responses, there is considerable resistance = and skepticism against this work. > I guess even fewer have bothered reading the actual I-D. >=20 > Personally I don't care that much since the JSON based systems I work = with have up to 5 layers of signatures which doesn't translate well to = the current JOSE standards. >=20 > Maybe the other editors of = https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 (which = builds on a flavor of Canonical JSON) have an idea? >=20 > There is also a (very active) W3C community group working with a = similar concept so clear-text signatures based on JSON canonicalization = will probably reach the market regardless of IETF's position on the = matter: https://w3c-dvcg.github.io/ld-signatures/ >=20 > The 1 million of random and "edge" JSON Numbers used for testing the = devised JSON canonicalization scheme, uncovered flaws in other systems = as well... > https://github.com/dotnet/coreclr/issues/17467 >=20 > Ciao, > Anders >=20 >=20 >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>> On Oct 12, 2018, at 10:47 AM, Anders Rundgren = > = wrote: >>>=20 >>> On 2018-10-12 17:20, Bret Jordan wrote: >>>> Please correct me if I am wrong=E2=80=A6. The way I understand the = problem is as follows: >>>=20 >>> Hi Bret, >>> Comments in line... >>>> 1) If you verified the JSON string at consumption time, before it = has been unmarshal-ed, then all you need to do is decide how to handle = white space and carriage returns. You could basically regex remove all = white space and CR / CRLF and have a workable solution. >>>=20 >>> It depends on what your goal is. Canonicalization builds on the = assumption that there is a unique representation of the data, preferably = even after it has passed through a processor like an intermediary. >>>=20 >>>> 2) Where this breaks down is, when a tool unmarshals the data into = a map or struct, then you have no guarantee that you would recreate the = keys in the same order (a struct may force it to the order of the struct = definition). So you have no way of being able to verify the hash after = it has been unmarshal-ed. Further, if you recreate the JSON and send it = back out, the next person that gets the data might have a hash that can = not be verified in option 1 above. >>>=20 >>> Right, therefore option 1 is not very useful. Sorting of keys is = the cure for this issue. >>>=20 >>>=20 >>>> 3) Another problem once you have unmarshal-ed the data is what do = you do with JSON numbers. >>>=20 >>> Right, but even string data needs adjustments. "\u0020" and " " = both represents a space character. >>>=20 >>>=20 >>>> Some programming languages store them as a float, some as = who-knows-what. So you would need a way to ensure that the number was = always stored in the same way, especially for strongly typed systems (is = this architecture dependent too?). So the options here are, if the = ontology / semantics of the JSON data were well defined in schema (a = meaning it was standardized and documented), then the code could know = what it should do and interoperability tests could be made to ensure = that it worked. >>>=20 >>> This is (IMO) the only part of the puzzle that is non-trivial. In = my take on the matter, I have "prescribed" that the JSON Number type = must be coerced into an IEEE 754 double precision number and be = serialized according to ECMAScript V6+ rules. >>>=20 >>> If your application needs higher precision or bigger range, you are = forced using the quoted string notation which (AFAIK...) is used by = every IETF standard of any significance to date defining a JSON = structure. >>>=20 >>>=20 >>>> What am I not understanding here? And what am I missing? >>>=20 >>>=20 >>> As I wrote earlier, there are (at least) two entirely different and = documented approaches. >>>=20 >>> Using a schema based canonicalizer as you mention is also an option = but that is a much more ambitious project. >>>=20 >>> Regards, >>> Anders >>>=20 >>>=20 >>>> Thanks, >>>> Bret >>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >>>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>>>> On Oct 12, 2018, at 12:38 AM, Anders Rundgren = = > wrote: >>>>>=20 >>>>> On 2018-10-11 22:05, Bret Jordan wrote: >>>>>> Anders, >>>>>> I really like what you have done with this. I am trying to = figure out if it will work 100% for my needs, or if it will need some = tweaking. If it does work, then I think we should really try and figure = out how we get your work standardized. >>>>>=20 >>>>> Thanx Bret! >>>>>=20 >>>>> The = https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D = provides quite a lot of features including an extension option that can = be used for adding possibly missing functionality. >>>>>=20 >>>>> There is one thing that is good to know for anyone thinking about = standardizing Canonical JSON and that's the fact that canonicalization = also can be performed on the text level as described by: = https://gibson042.github.io/canonicaljson-spec/ >>>>>=20 >>>>> This has the advantage that it is very simple and supports the = entire JSON RFC without restrictions. >>>>>=20 >>>>>=20 >>>>> So why didn't I took this [superficially obvious] route? There are = several reasons for that: >>>>>=20 >>>>> A downside of source level canonicalization is that it doesn't = integrate with JSON parsers and serializers. = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01= was explicitly designed to eventually be an option of a standard JSON = serializer as it already is in my Java reference implementation. >>>>>=20 >>>>> Another issue is that it is unclear what the value is with using = the JSON "Number" format outside of the IEEE range. In fact, it = excludes parsers like JavaScript's JSON.parse() unless JavaScaript would = be updated to always use a "BigNumber" as fundamental numeric type. >>>>>=20 >>>>> Regards, >>>>> Anders >>>=20 >=20 --Apple-Mail=_39BD6B90-7EAE-4082-AB24-ABE0297D5F24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Anders,

It = is sad that we have to look at doing work outside of the IETF in order = to solve the needs of the market.  But I would love to work with = you on this effort, even if it means doing it outside of the = IETF.

Your = solution that uses 5 layers of signatures, which draft / document / = write up is this based on?   I have a very similar need and would = like to try and do what ever you are doing. 
Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 19, 2018, at 10:55 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

On = 2018-10-12 23:31, Bret Jordan wrote:
Anders,
How do we move forward? =  What can we do to make this happen?

As you can see from the responses, there is considerable = resistance and skepticism against this work.
I guess even = fewer have bothered reading the actual I-D.

Personally I don't care that much since the JSON based = systems I work with have up to 5 layers of signatures which doesn't = translate well to the current JOSE standards.

Maybe the other editors of https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01= (which builds on a flavor of Canonical JSON) have an idea?

There is also a (very active) W3C community = group working with a similar concept so clear-text signatures based on = JSON canonicalization will probably reach the market regardless of = IETF's position on the matter: https://w3c-dvcg.github.io/ld-signatures/
The 1 million of random and "edge" JSON Numbers used for = testing the devised JSON canonicalization scheme, uncovered flaws in = other systems as well...
https://github.com/dotnet/coreclr/issues/17467

Ciao,
Anders


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 =  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv = vivc ce xhrnrw, however, the only thing that can not be unscrambled is = an egg."
On Oct 12, = 2018, at 10:47 AM, Anders Rundgren <anders.rundgren.net@gmail.com = <mailto:anders.rundgren.net@gmail.com>> wrote:

On 2018-10-12 17:20, Bret Jordan wrote:
Please correct me if I = am wrong=E2=80=A6. The way I understand the problem is as follows:

Hi Bret,
Comments = in line...
1) If you = verified the JSON string at consumption time, before it has been = unmarshal-ed, then all you need to do is decide how to handle white = space and carriage returns.  You could basically regex remove all = white space and CR / CRLF and have a workable solution.

It depends on what your goal is. =  Canonicalization builds on the assumption that there is a unique = representation of the data, preferably even after it has passed through = a processor like an intermediary.

2) Where this breaks down is, when a tool = unmarshals the data into a map or struct, then you have no guarantee = that you would recreate the keys in the same order (a struct may force = it to the order of the struct definition). So you have no way of being = able to verify the hash after it has been unmarshal-ed.  Further, = if you recreate the JSON and send it back out, the next person that gets = the data might have a hash that can not be verified in option 1 = above.

Right, therefore option = 1 is not very useful.  Sorting of keys is the cure for this = issue.


3) Another problem once you have unmarshal-ed = the data is what do you do with JSON numbers.

Right, but even string data needs = adjustments.  "\u0020" and " " both represents a space = character.


Some programming languages store them as a = float, some as who-knows-what.  So you would need a way to ensure = that the number was always stored in the same way, especially for = strongly typed systems (is this architecture dependent too?). So the = options here are, if the ontology / semantics of the JSON data were well = defined in schema (a meaning it was standardized and documented), then = the code could know what it should do and interoperability tests could = be made to ensure that it worked.

This is (IMO) the only part of the puzzle that is = non-trivial.  In my take on the matter, I have "prescribed" that = the JSON Number type must be coerced into an IEEE 754 double precision = number and be serialized according to ECMAScript V6+ rules.

If your application needs higher precision or = bigger range, you are forced using the quoted string notation which = (AFAIK...) is used by every IETF standard of any significance to date = defining a JSON structure.


What am I not = understanding here?  And what am I missing?


As I wrote = earlier, there are (at least) two entirely different and documented = approaches.

Using a schema based = canonicalizer as you mention is also an option but that is a much more = ambitious project.

Regards,
Anders


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only = thing that can not be unscrambled is an egg."
On Oct 12, 2018, at 12:38 AM, Anders Rundgren = <anders.rundgren.net@gmail.com = <mailto:anders.rundgren.net@gmail.com> = <mailto:anders.rundgren.net@gmail.com>> wrote:

On 2018-10-11 22:05, Bret Jordan wrote:
Anders,
I = really like what you have done with this.  I am trying to figure = out if it will work 100% for my needs, or if it will need some tweaking. =  If it does work, then I think we should really try and figure out = how we get your work standardized.

Thanx Bret!

The = https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D = provides quite a lot of features including an extension option that can = be used for adding possibly missing functionality.

There is one thing that is good to know for anyone thinking = about standardizing Canonical JSON and that's the fact that = canonicalization also can be performed on the text level as described = by: https://gibson042.github.io/canonicaljson-spec/

This has the advantage that it is very simple and supports = the entire JSON RFC without restrictions.

So why didn't I took this [superficially obvious] route? = There are several reasons for that:

A = downside of source level canonicalization is that it doesn't integrate = with JSON parsers and serializers. = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01= was explicitly designed to eventually be an option of a standard JSON = serializer as it already is in my Java reference implementation.

Another issue is that it is unclear what the = value is with using the JSON "Number" format outside of the IEEE range. =  In fact, it excludes parsers like JavaScript's JSON.parse() unless = JavaScaript would be updated to always use a "BigNumber" as fundamental = numeric type.

Regards,
Anders



= --Apple-Mail=_39BD6B90-7EAE-4082-AB24-ABE0297D5F24-- From nobody Sun Oct 21 19:47:08 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFBA130DC3 for ; Sun, 21 Oct 2018 19:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no 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 HfwhfDcOrI8c for ; Sun, 21 Oct 2018 19:47:04 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id CCBDE12F1AC for ; Sun, 21 Oct 2018 19:47:04 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:4179:bfa3:f068:e354] (unknown [IPv6:2601:282:202:b210:4179:bfa3:f068:e354]) by alkaline-solutions.com (Postfix) with ESMTPSA id C60B8315EC; Mon, 22 Oct 2018 02:47:02 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F1BE2A4F-7738-4F90-AB91-21D42B34D033" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.43\)) Date: Sun, 21 Oct 2018 20:47:01 -0600 In-Reply-To: <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> Cc: Bret Jordan , Carsten Bormann , "Manger, James" , Kathleen Moriarty , jose@ietf.org, Phil Hunt To: Anders Rundgren References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> X-Mailer: Apple Mail (2.3445.100.43) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 02:47:06 -0000 --Apple-Mail=_F1BE2A4F-7738-4F90-AB91-21D42B34D033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 19, 2018, at 10:55 PM, Anders Rundgren = wrote: >=20 > There is also a (very active) W3C community group working with a = similar concept so clear-text signatures based on JSON canonicalization = will probably reach the market regardless of IETF's position on the = matter: https://w3c-dvcg.github.io/ld-signatures/ >=20 This document is not on a standards track. The group which published = this it is not a standards group. So this isn=E2=80=99t currently on = track to reach the market as a IETF or W3 standard. It also is based on RDF canonicalization; it canonicalized a specific = format expressed in JSON, not arbitrary JSON.=20 That isn't to say that there couldn=E2=80=99t be multiple = canonicalization formats supported, possibly built as filters so you = could combine them together, such as existed with XML-DSIG. Then you = have a compatibility matrix to deal with. This still doesn=E2=80=99t solve the problem that many internal = representations of JSON will not preserve the full data set you are = representing in your canonical form.=20 =46rom my development experience with XML-DSIG, this is most commonly = that tools will discard information they do not understand, such as = properties which aren=E2=80=99t part of the public schema. For = developers who do not understand the additional restrictions a cleartext = signature is placing on them, this causes issues that only come up late = in broad interoperability testing, that can only be resolved through = per-vendor workarounds or reimplementation to use different tools. This = actually occurred multiple times across different implementations, = sometimes when leveraging libraries that did claim to preserve the full = information set of the XML document. > The 1 million of random and "edge" JSON Numbers used for testing the = devised JSON canonicalization scheme, uncovered flaws in other systems = as well... > https://github.com/dotnet/coreclr/issues/17467 = This yet another case against canonical JSON, is it not? Or rather, how = are people expected to deal with intermittent interoperability failures = until a new language runtime release which revises the numerical print = and parse functions comes out? -DW= --Apple-Mail=_F1BE2A4F-7738-4F90-AB91-21D42B34D033 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 19, 2018, at 10:55 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

There = is also a (very active) W3C community group working with a similar = concept so clear-text signatures based on JSON canonicalization will = probably reach the market regardless of IETF's position on the matter: = https://w3c-dvcg.github.io/ld-signatures/

This = document is not on a standards track. The group which published this it = is not a standards group. So this isn=E2=80=99t currently on track to = reach the market as a IETF or W3 standard.

It also is based on RDF canonicalization; it = canonicalized a specific format expressed in JSON, not arbitrary = JSON. 

That isn't to say that = there couldn=E2=80=99t be multiple canonicalization formats supported, = possibly built as filters so you could combine them together, such as = existed with XML-DSIG. Then you have a compatibility matrix to deal = with.

This still doesn=E2=80=99t = solve the problem that many internal representations of JSON will not = preserve the full data set you are representing in your canonical = form. 

=46rom my development = experience with XML-DSIG, this is most commonly that tools will discard = information they do not understand, such as properties which aren=E2=80=99= t part of the public schema. For developers who do not understand the = additional restrictions a cleartext signature is placing on them, this = causes issues that only come up late in broad interoperability testing, = that can only be resolved through per-vendor workarounds or = reimplementation to use different tools. This actually occurred multiple = times across different implementations, sometimes when leveraging = libraries that did claim to preserve the full information set of the XML = document.

The 1 million of random and "edge" JSON = Numbers used for testing the devised JSON canonicalization scheme, = uncovered flaws in other systems as well...
https://github.com/dotnet/coreclr/issues/17467

This yet = another case against canonical JSON, is it not? Or rather, how are = people expected to deal with intermittent interoperability failures = until a new language runtime release which revises the numerical print = and parse functions comes out?

-DW
= --Apple-Mail=_F1BE2A4F-7738-4F90-AB91-21D42B34D033-- From nobody Sun Oct 21 22:04:25 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5555C130DC0 for ; Sun, 21 Oct 2018 22:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 wIhlBxWx_Wli for ; Sun, 21 Oct 2018 22:04:21 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC2112F1AC for ; Sun, 21 Oct 2018 22:04:21 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id u1-v6so7541985wrn.0 for ; Sun, 21 Oct 2018 22:04:21 -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=rUu5LMyaO35rFOUX67XvfpdujRv4ofsZzBWQrdOR9JM=; b=Z37t15Cnd7LAtgEe7pFc73jJOTowGo046g5qRY82LkFBzRfbL25KKqANuRWoWzPapD RhX7vmiX5nqQM9PeUiQSiI/FaohETZ4JLOCyg1lpzBZaj0GmVs2MEFCHR2LBlPDqHXIh bwlybLVZuSKsF6ThU8+BSeIEIsKMQWMC2qRCTLOqXITeiPIMV90ENnGy/f/qJ8N8uFF2 XmZbNmX3KlqoUz0+7dRXoYDlMcvv14AvrChZI0OpBWRprSSglkuEkDu3t90iRb6PfCIG KvyLznCzdcmyxFV9rm0fu4V0v/LpGkF7QNOHUz3+iOjb3FA3VMTjbWMVqKbVxLA9xTa/ 5JOQ== 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=rUu5LMyaO35rFOUX67XvfpdujRv4ofsZzBWQrdOR9JM=; b=TgbBaE+WCQkPjD4WiuEmo5j+qydWxvbOggGa9Pg4CN00jw9v7HmASrbxKIaocuXAMx /bCqpvdRG0m9wyJSiZ4WzyQJK5v3KdHJvw16LIsIXdmkywkWepzz1oPP7qPYrIwt2aEe RnmRk/0KxPcIvpvMWpNKQ9Mbi5rb39iGbDTN6bJvD8NbEEDOXgrksagLZOTeHizEW5ZA +UE+W2vlNHPuI7wfI36XlKuZXooHMX+aVav7+ybBiJxYcyLJxO8mVTCwxtowrcRxd6/R GS2P5fATSDTWmlbAMK+H0dQMd5G/47RJqqSGd5WzHxegVWSW2FpdMqUU1cIpHbh/+4Sl LZaA== X-Gm-Message-State: AGRZ1gJlRgrBaB0VyZRt4RAlyOVfyIOMjQrhe/q5qFzIWrfqTh5ioK5T yKoU+eZh9XVIc3/UlKvIvevRF/7y X-Google-Smtp-Source: AJdET5cVHGniaLvNj06Jqhg4yxyKCy0b7E2nxeft1jZESPhLB6NK8wELl638S/xVlRPf/F9yXg5ckA== X-Received: by 2002:adf:e74c:: with SMTP id c12-v6mr6277935wrn.182.1540184659666; Sun, 21 Oct 2018 22:04:19 -0700 (PDT) Received: from [192.168.10.182] (217.17.136.77.rev.sfr.net. [77.136.17.217]) by smtp.googlemail.com with ESMTPSA id y41-v6sm21482141wrd.25.2018.10.21.22.04.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Oct 2018 22:04:18 -0700 (PDT) To: David Waite Cc: Bret Jordan , Carsten Bormann , "Manger, James" , Kathleen Moriarty , jose@ietf.org, Phil Hunt References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> From: Anders Rundgren Message-ID: Date: Mon, 22 Oct 2018 07:04:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 05:04:24 -0000 Dear David et al, I believe we all know IETF's position on this topic by now. Anyway, there is considerable interest maintaining the core quality of text based messages (human readability) also for signed data, leading to various quests for alternative solutions. To give some kind of perspective on the complexity, my C#/.NET implementation [1] weighs in at 30 Kb of executable code. It took 3 complete revisions and five calendar years to get to this point but it was (hopefully) worth it :-) Thanks, Anders 1] https://github.com/cyberphone/json-canonicalization/tree/master/dotnet On 2018-10-22 04:47, David Waite wrote: > > >> On Oct 19, 2018, at 10:55 PM, Anders Rundgren > wrote: >> >> There is also a (very active) W3C community group working with a similar concept so clear-text signatures based on JSON canonicalization will probably reach the market regardless of IETF's position on the matter: https://w3c-dvcg.github.io/ld-signatures/ >> > > This document is not on a standards track. The group which published this it is not a standards group. So this isn’t currently on track to reach the market as a IETF or W3 standard. > > It also is based on RDF canonicalization; it canonicalized a specific format expressed in JSON, not arbitrary JSON. > > That isn't to say that there couldn’t be multiple canonicalization formats supported, possibly built as filters so you could combine them together, such as existed with XML-DSIG. Then you have a compatibility matrix to deal with. > > This still doesn’t solve the problem that many internal representations of JSON will not preserve the full data set you are representing in your canonical form. > > From my development experience with XML-DSIG, this is most commonly that tools will discard information they do not understand, such as properties which aren’t part of the public schema. For developers who do not understand the additional restrictions a cleartext signature is placing on them, this causes issues that only come up late in broad interoperability testing, that can only be resolved through per-vendor workarounds or reimplementation to use different tools. This actually occurred multiple times across different implementations, sometimes when leveraging libraries that did claim to preserve the full information set of the XML document. > >> The 1 million of random and "edge" JSON Numbers used for testing the devised JSON canonicalization scheme, uncovered flaws in other systems as well... >> https://github.com/dotnet/coreclr/issues/17467 > > This yet another case against canonical JSON, is it not? Or rather, how are people expected to deal with intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions comes out? > > -DW From nobody Sun Oct 21 23:44:34 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADC1130DC4 for ; Sun, 21 Oct 2018 23:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 fA0rEyrWs2Ok for ; Sun, 21 Oct 2018 23:44:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 DCEB6120072 for ; Sun, 21 Oct 2018 23:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9M6iEUv029812; Mon, 22 Oct 2018 08:44:19 +0200 (CEST) Received: from [192.168.217.102] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42dn721Nwvz1Bqf; Mon, 22 Oct 2018 08:44:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 22 Oct 2018 08:44:13 +0200 Cc: Anders Rundgren , Bret Jordan , Kathleen Moriarty , jose@ietf.org, "Manger, James" , Phil Hunt X-Mao-Original-Outgoing-Id: 561883451.855143-54c9ae01b155661185657008a69b208a Content-Transfer-Encoding: quoted-printable Message-Id: <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> To: David Waite X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 06:44:32 -0000 On Oct 22, 2018, at 04:47, David Waite = wrote: >=20 > intermittent interoperability failures until a new language runtime = release which revises the numerical print and parse functions Note that this is not a theoretical concern, as CVE-2010-4476 and = CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence = of the latter in = https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incor= rectly/ Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Oct 28 13:32:22 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880F1127332 for ; Sun, 28 Oct 2018 13:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 bvJiF1oTAXub for ; Sun, 28 Oct 2018 13:32:17 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 D00561277CC for ; Sun, 28 Oct 2018 13:32:17 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id o19-v6so2766394pll.12 for ; Sun, 28 Oct 2018 13:32:17 -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=jj4mjTCUJcUFJqFE7MJ9jfRy06oOab2rxaz2DxS8sI4=; b=LTRH2G2n+ytyuMcCYpOkZhze/bFcD+HlN7UrK/HxeiFXrgTc1hlXbDJJChiaNzbC4O 6wnX90WbsR0zN2LV0jPFiQSSx+9Wb2jjns1c31r/GIFNeFHzHLepR2oeluzbk5G7XD9G odl0n8fC+w39tFoxxHTlZtmwJPCS6R1xT3Da9SEv53geHwUnuh/LlloBUHAX7eYKwDZP lvCrmp+G86mccTzzuJbVtdTQ2v1J21mae2VxLszHY92P73kZ7UKneQH4gpJsD5u7OrOT 28Xa4eZL8fXYXXGerBXJShgu3DH5LReTqFIJskQxs2pQWqvtS+4jWUK71lUBKlOyyOJ0 koLA== 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=jj4mjTCUJcUFJqFE7MJ9jfRy06oOab2rxaz2DxS8sI4=; b=jMRNnayH+/XX59wpdlU+H2Dx7DUmYBtRB+0G5iNDxI7yqujAnIXT9QtL5TvF0IZCy/ Q/9TZbN90VGMSdnHn4yUOquAawSOxkw0dR1C/1HmMmbkSez6einfHW8Gq+F/vReXi+5m uTQXV8vm6tQ6vgPu1E97qIxXGAQCeXuBCMrIL2j3axV0o3PHpGmorXbLDtCF8LIgq9Bh jZEM/RmH0Dlvi4yMTu4zouYbgglWFlBuCNTNXE55b03qPTyit7VuN66DKzkUoEfZ+Eai UEPetBC67/gOtJny8CLXedJNb5B0964AbEMpKk6eowxBwcZKCUG7mXtXFi/ZPuAbTd7q Ur5A== X-Gm-Message-State: AGRZ1gJAEi8PMt/50e71ZGS2rTgMKIClnmhcd2a9JPbZ/Y/YyKHmppt0 TtrDNIV56Pp2rJVJMgJaYSvC63zapNM40GrcFUEafwJR+pvC2w== X-Google-Smtp-Source: AJdET5eMANtqoyzTgWDPRXAIp6/W3INCJ7H0mmPeaUf/TcWIWDZyHrKSreezjyVVonlKgaA2FxxQSqdueCZhHg2UQ28= X-Received: by 2002:a17:902:904a:: with SMTP id w10-v6mr11323006plz.225.1540758736956; Sun, 28 Oct 2018 13:32:16 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> In-Reply-To: <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> From: Samuel Erdtman Date: Sun, 28 Oct 2018 21:32:05 +0100 Message-ID: To: Carsten Bormann Cc: david@alkaline-solutions.com, jordan.ietf@gmail.com, Anders Rundgren , Kathleen Moriarty , jose@ietf.org, James.H.Manger@team.telstra.com, Phil Hunt Content-Type: multipart/alternative; boundary="00000000000033857305794fd919" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 20:32:21 -0000 --00000000000033857305794fd919 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my opinion we can create a good canonicalization format for JSON to be used to sign cleartext JSON. As can be seen on this list many are skeptical so my approach would be to publish easy to use open source implementations. If we do that and there is real interest then we might be able to convince people here about the need. In line with this ambition I have done the JS and Java publications. This might also show there is no actual interest and then that is also an outcome. Best regards //Samuel On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann wrote: > On Oct 22, 2018, at 04:47, David Waite > wrote: > > > > intermittent interoperability failures until a new language runtime > release which revises the numerical print and parse functions > > Note that this is not a theoretical concern, as CVE-2010-4476 and > CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence = of > the latter in > https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-inco= rrectly/ > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --00000000000033857305794fd919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my opinion we can create a good canonicalization f= ormat for JSON to be used to sign cleartext JSON.

= As can be seen on this list many are skeptical so my approach would be to p= ublish easy to use open source implementations. If we do that and there is = real interest then we might be able to convince people here about the need.= In line with this ambition I have done the JS and Java publications. This = might also show there is no actual interest and then that is also an outcom= e.

Best regards
//Samuel


On Mon, = Oct 22, 2018 at 8:44 AM Carsten Bormann <cabo@tzi.org> wrote:
On Oct= 22, 2018, at 04:47, David Waite <david@alkaline-solutions.com> wrote:
>
> intermittent interoperability failures until a new language runtime re= lease which revises the numerical print and parse functions

Note that this is not a theoretical concern, as CVE-2010-4476 and CVE-2010-= 4645 amply demonstrate, nicely underscored by the re-occurrence of the latt= er in https://www.e= xploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/
Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--00000000000033857305794fd919-- From nobody Sun Oct 28 20:04:32 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4D012F1A6 for ; Sun, 28 Oct 2018 20:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TSxRWhTtL7rV for ; Sun, 28 Oct 2018 20:04:29 -0700 (PDT) Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) (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 2DD991286D9 for ; Sun, 28 Oct 2018 20:04:29 -0700 (PDT) Received: by mail-yb1-xb42.google.com with SMTP id p144-v6so2824706yba.11 for ; Sun, 28 Oct 2018 20:04:29 -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=hUjJJbMgU5hE6UF3KALkucLinGJOFIbPAQt6QmhMyHA=; b=E6FmKAgELWVqbVk7gzDsqsrS+XVPoujOpbwXn2Gvw0KG0pnjS251E8GbX3aKlFVSSl SkIjRxvZ8ttY7Vp24yaPhD+zolh0BeM5TxUs17ijcGGkMTnxPi3Ag0splSwq1R41hwrE Pa/Cymwpi1N9jWjG3Bt43SIZpIKqeG9MVMoNBmack3IdeLhsYC1RK3gmWfHpSpblnueA ze1ywpGnBLrfPA+G5eMy/aC3R9ap3dbI3POBCWJyQWLfO+BvS2ZmFHeQi8kqHnzKiTEk NIoq0TVkKh5chljAa1ME4/H1E+2Weno4B+jW9GowzW/zEpFZn/HkRtD0O3Dm232xo1sr GHng== 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=hUjJJbMgU5hE6UF3KALkucLinGJOFIbPAQt6QmhMyHA=; b=JJEWLsDobAaYaXVDz99CrPuGPdLYJKEY5X4DvhRcrK2rWbZa/uqISCTzzgwZveEzFK iT9+YD7JQjUDjaPN37f3fIzJTt8ceOirpSVsXW1lv9AfZ3Y3mTf1lYFxRNP7JnmjhlLX 50/w840Vg6TRtQRZ7TIi2KeP812mRwCliq/d9PWiAGCLRBfY/5N+T+NgsVx2P27aDmDd B8WIdzhazxPOFuPsAt+05oCL5RaBR9wGVRJVNPA1Se1wSt4IQ7LkoZpndzhojLotGsGS cQPHT4dxbVyzrrV9aEP9VRyabBIRdj4WSv5dlQsj0otJ3J2z/6GXWECIdDJ0ghBrlX41 ZOUA== X-Gm-Message-State: AGRZ1gLVhzlH+oZ5cvMKUe951zYZEokSooITT7rfs+ynESfQ7/vUR5cB 6c1dQFePCj+48PIDmPJ/mYQ= X-Google-Smtp-Source: AJdET5c/oNa3qwPuVQAkvYoynNKk10DTY/SiAyr8HypLp25NtI2Csg29n+xRh7kBknXNW8a9HnRReg== X-Received: by 2002:a25:69cd:: with SMTP id e196-v6mr12144809ybc.439.1540782268409; Sun, 28 Oct 2018 20:04:28 -0700 (PDT) Received: from ?IPv6:2605:a601:3260:266:5108:ee4b:f209:8e5e? ([2605:a601:3260:266:5108:ee4b:f209:8e5e]) by smtp.gmail.com with ESMTPSA id 84-v6sm4508629ywp.69.2018.10.28.20.04.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Oct 2018 20:04:27 -0700 (PDT) From: Bret Jordan Message-Id: <0A81DF6A-1EF5-42EA-AE88-69E2A0383FB5@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_79A40714-EF0D-41BF-ABD0-455F33191D36" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 28 Oct 2018 21:04:20 -0600 In-Reply-To: Cc: Carsten Bormann , david@alkaline-solutions.com, Anders Rundgren , Kathleen Moriarty , jose@ietf.org, James.H.Manger@team.telstra.com, Phil Hunt To: Samuel Erdtman References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 03:04:32 -0000 --Apple-Mail=_79A40714-EF0D-41BF-ABD0-455F33191D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oh there is real need. Several standards and implementations inside the = IETF and outside the IETF in other SDOs need this. So in my view there = are a few options: 1) Try and convince a working group here in the IETF that this is a good = idea so we can actually work on it.=20 2) Work on this in another SDO outside the IETF (ETSI, OASIS, ITU, etc = etc etc) 3) Do this work as an industry standard similar to what happened between = W3C and WHATWG.=20 I would personally prefer that this work be done here in the IETF. But = there seems to be a lot of resistance here. I am willing to work on this = and help make this a reality. There is a lot of great prior work on = this. =20 Maybe we can have a meeting in Prague? Or I can setup a Telepresence = WebEx after Bangkok and all those that are interested can join and we = can discuss next steps.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Oct 28, 2018, at 2:32 PM, Samuel Erdtman wrote: >=20 > In my opinion we can create a good canonicalization format for JSON to = be used to sign cleartext JSON. >=20 > As can be seen on this list many are skeptical so my approach would be = to publish easy to use open source implementations. If we do that and = there is real interest then we might be able to convince people here = about the need. In line with this ambition I have done the JS and Java = publications. This might also show there is no actual interest and then = that is also an outcome. >=20 > Best regards > //Samuel >=20 >=20 > On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann > wrote: > On Oct 22, 2018, at 04:47, David Waite > wrote: > >=20 > > intermittent interoperability failures until a new language runtime = release which revises the numerical print and parse functions >=20 > Note that this is not a theoretical concern, as CVE-2010-4476 and = CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence = of the latter in = https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incor= rectly/ = >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = --Apple-Mail=_79A40714-EF0D-41BF-ABD0-455F33191D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oh = there is real need.  Several standards and implementations inside = the IETF and outside the IETF in other SDOs need this.  So in my = view there are a few options:

1) Try and convince a working group here in the IETF that = this is a good idea so we can actually work on it. 

2) Work on this in = another SDO outside the IETF (ETSI, OASIS, ITU, etc etc etc)

3) Do this work as an = industry standard similar to what happened between W3C and = WHATWG. 

I = would personally prefer that this work be done here in the IETF. =  But there seems to be a lot of resistance here. I am willing to = work on this and help make this a reality.  There is a lot of great = prior work on this.  

Maybe we can have a meeting in Prague?  Or I can setup a = Telepresence WebEx after Bangkok and all those that are interested can = join and we can discuss next steps. 

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Oct 28, 2018, at 2:32 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

In my opinion we can create a = good canonicalization format for JSON to be used to sign cleartext = JSON.

As can = be seen on this list many are skeptical so my approach would be to = publish easy to use open source implementations. If we do that and there = is real interest then we might be able to convince people here about the = need. In line with this ambition I have done the JS and Java = publications. This might also show there is no actual interest and then = that is also an outcome.

Best regards
//Samuel


On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann = <cabo@tzi.org> = wrote:
On Oct 22, 2018, at 04:47, David Waite <david@alkaline-solutions.com> wrote:
>
> intermittent interoperability failures until a new language runtime = release which revises the numerical print and parse functions

Note that this is not a theoretical concern, as CVE-2010-4476 and = CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence = of the latter in https://www.exploringbinary.com/php-converts-2-2250738585072012= e-308-incorrectly/

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

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_79A40714-EF0D-41BF-ABD0-455F33191D36-- From nobody Mon Oct 29 01:33:19 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929C5130DC2 for ; Mon, 29 Oct 2018 01:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gwJg9DFxUWGn for ; Mon, 29 Oct 2018 01:33:16 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 4A01B12D4EC for ; Mon, 29 Oct 2018 01:33:16 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id l26-v6so7235808wmh.3 for ; Mon, 29 Oct 2018 01:33:16 -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=H1Z6Tl4SK++WeB2+UUWGu+mfuqBT7JZziEyP6namgoI=; b=hXQY6EzOg5ZyXSnr7Tct13PZcLRTtsf6Na+uoBwvAhxi6w7YXN3x4LqQ6XhXlZEUBB HHl0WZp7n/19nMdvn1/OH6pRjle7OCsubQc2HsEFrgzQ7Tj56Pyll3A+ltsQ1LeqjQA1 vX2qGeTWc0A0i5SSmnGE9J0UReAlQaKRCVZmxIoCEAiUtesE+OBLNV4Rzzvr8/905ngn 869QZmzLDYz7VZgX4aT0kAzwHbVpkmgWEmAoleXpJIrlSFPUpJiKwMU7rSHZywQm9ltB YOGS5qiO3wJzSEqWWmFx0/4jHyWjusY/V8B8bI51TaP09FxJS5c07Za4ebj7rDpNU9Nd 7L2Q== 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=H1Z6Tl4SK++WeB2+UUWGu+mfuqBT7JZziEyP6namgoI=; b=bERPnptxtSX/+iyekKad6LBYItpKF+1vayLEi/5QSL7B5ITTcG1P9+VbViWRlwSUQ0 6X7hXw6nQnrx7n+4mWACr5YWTv7XpA1n0Fxelil+F+l8JWQEk7VZx3hkYxhv0b29RjTS rAFLhM8KLxGa6d4fxL6+zxTayWufmE/r0ROkWwWwbdB0DCiHK6f6eRygF3Ho2ogFt0TW KyDCya7YRBgH7nvfrkihNBgZ0y51KxIK4Va5VJsrEMqx1zcGAShX++3lMUUbJzGrsNXE FkOu0lt+EK4CoRJwm2oTX2M2c7RBoFOs0uRNU8ZZDyG/xFcnYCflcYSGeiIE3dY8Cs5P SApg== X-Gm-Message-State: AGRZ1gIDqvptWtthLZCL+tm3sbcjCHqTOGeoSk89Q4X1xgqdu5SS6Fzc ASAqZZ1lbSSxUnQQt83LNb0= X-Google-Smtp-Source: AJdET5eP8hUz8KUPy72quQu+TfrGDoLs7eL6XbwMw8esYG1fGnrBaLL3lIfbhiRf9Jdx5nGND2qI2Q== X-Received: by 2002:a1c:4489:: with SMTP id r131-v6mr3233358wma.121.1540801994648; Mon, 29 Oct 2018 01:33:14 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id t82-v6sm11103754wme.30.2018.10.29.01.33.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 01:33:13 -0700 (PDT) To: Samuel Erdtman , Carsten Bormann Cc: david@alkaline-solutions.com, jordan.ietf@gmail.com, Kathleen Moriarty , jose@ietf.org, James.H.Manger@team.telstra.com, Phil Hunt References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> From: Anders Rundgren Message-ID: <2c5aa692-3458-b36f-23ae-c56d41deeff1@gmail.com> Date: Mon, 29 Oct 2018 09:33:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 08:33:18 -0000 On 2018-10-28 21:32, Samuel Erdtman wrote: > In my opinion we can create a good canonicalization format for JSON to be used to sign cleartext JSON. > > As can be seen on this list many are skeptical so my approach would be to publish easy to use open source implementations. Yes, and part of that is supplying test data like: https://github.com/cyberphone/json-canonicalization/tree/master/testdata The Microsoft folks developing "Chakra" (their JS engine) already use the 100 million reference values. > If we do that and there is real interest then we might be able to convince people here about the need. In line with this ambition I have done the JS and Java publications. This might also show there is no actual interest and then that is also an outcome. Well, another part of the standards puzzle is getting early work into real products and services. FWIW, I'm personally involved in a couple of efforts using clear text JSON signatures: - Saturn, an open payment authorization scheme based on an enhanced "four corner" trust model which aims giving banks an upper hand against Apple Pay, Google Pay, PayPal, etc. - Mobile ID, an open, PKI-based, multi-issuer mobile authentication and signature solution for e-governments. Regards, Anders > Best regards > //Samuel > > > On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann > wrote: > > On Oct 22, 2018, at 04:47, David Waite > wrote: > > > > intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions > > Note that this is not a theoretical concern, as CVE-2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/ > > Grüße, Carsten > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Mon Oct 29 06:38:59 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE83130F23 for ; Mon, 29 Oct 2018 06:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 XtgdbUwAki5K for ; Mon, 29 Oct 2018 06:38:55 -0700 (PDT) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 85FF1130DBE for ; Mon, 29 Oct 2018 06:38:54 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id u12-v6so4435962eds.4 for ; Mon, 29 Oct 2018 06:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/cubA8EJjbKTSBCExKYKFgnbh3vM/mZ8DUtQ8U+9MWA=; b=qFRBtgMSOx2GbrgRuMg2DmKnVQ+NTJfdDvm1Pq55P6xu/Erkrr0IDg0Bd+k54e+9mx VEeGfYUtI7zi2+i5kGI8Jq8Ea4fkuQB8a2Q5vYWX7j7SLEnY2DLGn3zp2wMEbNcaR1sf m+g6aBemLtqu8gGd2BDHQNjl2vNWd05i3XQ6GTg8kVsNMjFxr+JVpqC3FFs8qn3nFG3r ZtDSvqCeEUC0V7LwbRH7iciiZpHoQcvbuNdVUeqbL0+suO9TWPLUbKTC/Ldje07vZRE8 0/n9QX1+3lsc3zj0jAPXO4Q/6QYV6airVZ7IpKOJyTsjEAuaRoowSmqwBP3GZrI3Q6T5 yeqQ== 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=/cubA8EJjbKTSBCExKYKFgnbh3vM/mZ8DUtQ8U+9MWA=; b=RRJ0JzT4cmgHmjb5mZfFubx2AKZa2jzyR/90uBoxcAf1lwdQzz2DcU9bi2rZxnA+Vn oDDsV88YWqEt1k2OBPF5Yy6qUhCMQ2moJ++pKKH0c/L4SvPRaZT4pOTIvTbvVbSiq/8m /ijXwZfOT0FZCzWCidiIhakokEnwKzqmLBE41B4blfHcYIb1UBkuT2p8X9btnu5dTDWY XGl0uH9fL/FU8rIuxbkSd11AobxCba8j6VqALd9g9Wz+cko/AAewyhMDurb2z0OWy8ek LGhAbkcD+0woCWKuLST/BHop7+lU1X4NuXQeRGizA96QgMHRv07f8kdyq+FBsOf9PrFD +hyw== X-Gm-Message-State: AGRZ1gJzifL92Kwt1LqvAzKHNIY7N/dMtSqaaU3GvokIJkgwJTAdmxxh A8CcKKiJUsChfx40KBowqsgDlJAiAcNF5ntnAth6nQ== X-Google-Smtp-Source: AJdET5ekr14WzkI8apbeoJheUn/ppTWyMW6UyY7eHVJfeLkM0WVKIFBRJUrL4jevOvwFF8WI7YiEestzWAqgsleSlxc= X-Received: by 2002:a17:906:1d5b:: with SMTP id o27-v6mr10567669ejh.61.1540820332887; Mon, 29 Oct 2018 06:38:52 -0700 (PDT) MIME-Version: 1.0 References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> <2c5aa692-3458-b36f-23ae-c56d41deeff1@gmail.com> In-Reply-To: <2c5aa692-3458-b36f-23ae-c56d41deeff1@gmail.com> From: Tim Bray Date: Mon, 29 Oct 2018 06:38:40 -0700 Message-ID: To: Anders Rundgren Cc: Samuel Erdtman , Carsten Bormann , jordan.ietf@gmail.com, Kathleen Moriarty , jose@ietf.org, david@alkaline-solutions.com, James.H.Manger@team.telstra.com, Phil Hunt Content-Type: multipart/alternative; boundary="0000000000009ad58f05795e300a" Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 13:38:57 -0000 --0000000000009ad58f05795e300a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like Samuel Erdtman's idea of starting with an open-source implementation. If I see one of those, with a convincing set of test cases, I'd be inclined to make the case for spinning up a working group. The argument isn't "Would it be useful?" it's "Can it be done?" So, start by proving it can. On Mon., Oct. 29, 2018, 1:33 a.m. Anders Rundgren < anders.rundgren.net@gmail.com wrote: > On 2018-10-28 21:32, Samuel Erdtman wrote: > > In my opinion we can create a good canonicalization format for JSON to > be used to sign cleartext JSON. > > > > As can be seen on this list many are skeptical so my approach would be > to publish easy to use open source implementations. > > Yes, and part of that is supplying test data like: > https://github.com/cyberphone/json-canonicalization/tree/master/testdata > The Microsoft folks developing "Chakra" (their JS engine) already use the > 100 million reference values. > > > > If we do that and there is real interest then we might be able to > convince people here about the need. In line with this ambition I have do= ne > the JS and Java publications. This might also show there is no actual > interest and then that is also an outcome. > > Well, another part of the standards puzzle is getting early work into rea= l > products and services. > > FWIW, I'm personally involved in a couple of efforts using clear text JSO= N > signatures: > - Saturn, an open payment authorization scheme based on an enhanced "four > corner" trust model which aims giving banks an upper hand against Apple > Pay, Google Pay, PayPal, etc. > - Mobile ID, an open, PKI-based, multi-issuer mobile authentication and > signature solution for e-governments. > > Regards, > Anders > > > Best regards > > //Samuel > > > > > > On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann cabo@tzi.org>> wrote: > > > > On Oct 22, 2018, at 04:47, David Waite > wrote: > > > > > > intermittent interoperability failures until a new language > runtime release which revises the numerical print and parse functions > > > > Note that this is not a theoretical concern, as CVE-2010-4476 and > CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence = of > the latter in > https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-inco= rrectly/ > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --0000000000009ad58f05795e300a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like Samuel Erdtman's idea of starting with an open= -source implementation.=C2=A0 If I see one of those, with a convincing set = of test cases, I'd be inclined to make the case for spinning up a worki= ng group.=C2=A0

The argument i= sn't "Would it be useful?" it's "Can it be done?&quo= t; So, start by proving it can.

<= div dir=3D"ltr">On Mon., Oct. 29, 2018, 1:33 a.m. Anders Rundgren <anders.rundgren.net@gmail.com wrote:
On 2018-10-28 21:32, Samu= el Erdtman wrote:
> In my opinion we can create a good canonicalization format for JSON to= be used to sign cleartext JSON.
>
> As can be seen on this list many are skeptical so my approach would be= to publish easy to use open source implementations.

Yes, and part of that is supplying test data like:
https://github.com/cyberphone/json-canoni= calization/tree/master/testdata
The Microsoft folks developing "Chakra" (their JS engine) already= use the 100 million reference values.


> If we do that and there is real interest then we might be able to conv= ince people here about the need. In line with this ambition I have done the= JS and Java publications. This might also show there is no actual interest= and then that is also an outcome.

Well, another part of the standards puzzle is getting early work into real = products and services.

FWIW, I'm personally involved in a couple of efforts using clear text J= SON signatures:
- Saturn, an open payment authorization scheme based on an enhanced "f= our corner" trust model which aims giving banks an upper hand against = Apple Pay, Google Pay, PayPal, etc.
- Mobile ID, an open, PKI-based, multi-issuer mobile authentication and sig= nature solution for e-governments.

Regards,
Anders

> Best regards
> //Samuel
>
>
> On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <cabo@tzi.org <mai= lto:ca= bo@tzi.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Oct 22, 2018, at 04:47, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-sol= utions.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > intermittent interoperability failures until = a new language runtime release which revises the numerical print and parse = functions
>
>=C2=A0 =C2=A0 =C2=A0Note that this is not a theoretical concern, as CVE= -2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by the r= e-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-225073= 8585072012e-308-incorrectly/
>
>=C2=A0 =C2=A0 =C2=A0Gr=C3=BC=C3=9Fe, Carsten
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0jose mailing list
>=C2=A0 =C2=A0 =C2=A0jose@ietf.org <mailto:jose@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/ma= ilman/listinfo/jose
>

_______________________________________________
jose mailing list
jose@= ietf.org
https://www.ietf.org/mailman/listinfo/jose<= br>
--0000000000009ad58f05795e300a-- From nobody Mon Oct 29 11:46:28 2018 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EBC131059 for ; Mon, 29 Oct 2018 11:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QOzyTozxx0FT for ; Mon, 29 Oct 2018 11:46:23 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B291C124408 for ; Mon, 29 Oct 2018 11:46:22 -0700 (PDT) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 29 Oct 2018 11:41:26 -0700 From: Jim Schaad To: 'Bret Jordan' , 'Samuel Erdtman' CC: 'Anders Rundgren' , 'Kathleen Moriarty' , , , 'Carsten Bormann' , , 'Phil Hunt' References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> <1B3A97D9-06BE-4225-BF8D-DE55C7FBF2DF@tzi.org> <0A81DF6A-1EF5-42EA-AE88-69E2A0383FB5@gmail.com> In-Reply-To: <0A81DF6A-1EF5-42EA-AE88-69E2A0383FB5@gmail.com> Date: Mon, 29 Oct 2018 11:46:06 -0700 Message-ID: <037201d46fb7$a9355510$fb9fff30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0373_01D46F7C.FCD91520" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNnP1/vuW81sZle9dbx86Tf75xU2AKidaiOAXg4vdwBstG6fgKFRrXIAVkN6LgBzAWdjwID7Z18AaJkkZwCVO0YrgES4VnfAyA/SKgB4E14ZQF6wVvjAk4krsABSXh5BAIL2re6AZkRWd0CVOgU4wLuhyqdAGL1rE0CxUFUoqDLo5rQ Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [jose] Canonical JSON form X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 18:46:27 -0000 ------=_NextPart_000_0373_01D46F7C.FCD91520 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would look at creating a new working group in the IETF rather than = using an existing one. =20 1. Get a personal draft published 2. Find a cadre of people who are interested and think it is solvable 3. Write a charter 4. Talk to the ADs about getting the WG formed by holding a BOF =20 The first three should be really easy to do. The fourth may take a bit = of work but should be doable. The trick with the IETF is to find people = who want to work on things and not to worry over much about the people = who don=E2=80=99t think it is solvable. If necessary write the charter = to say you are not going to cover some things or that you are going to = require specific environments for your solution. The tighter the = requirements the easier the solution but the less harder it might be to = get the cadre of people. =20 You should be looking at 1) one or more authors, 2) half a dozen or more = reviewers, 3) at least a couple of people who think they are going to = get this implemented. =20 Jim =20 =20 From: jose On Behalf Of Bret Jordan Sent: Sunday, October 28, 2018 8:04 PM To: Samuel Erdtman Cc: Anders Rundgren ; Kathleen Moriarty = ; jose@ietf.org; = david@alkaline-solutions.com; Carsten Bormann ; = James.H.Manger@team.telstra.com; Phil Hunt Subject: Re: [jose] Canonical JSON form =20 Oh there is real need. Several standards and implementations inside the = IETF and outside the IETF in other SDOs need this. So in my view there = are a few options: =20 1) Try and convince a working group here in the IETF that this is a good = idea so we can actually work on it.=20 =20 2) Work on this in another SDO outside the IETF (ETSI, OASIS, ITU, etc = etc etc) =20 3) Do this work as an industry standard similar to what happened between = W3C and WHATWG.=20 =20 I would personally prefer that this work be done here in the IETF. But = there seems to be a lot of resistance here. I am willing to work on this = and help make this a reality. There is a lot of great prior work on = this. =20 =20 Maybe we can have a meeting in Prague? Or I can setup a Telepresence = WebEx after Bangkok and all those that are interested can join and we = can discuss next steps.=20 =20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." On Oct 28, 2018, at 2:32 PM, Samuel Erdtman > wrote: =20 In my opinion we can create a good canonicalization format for JSON to = be used to sign cleartext JSON. =20 As can be seen on this list many are skeptical so my approach would be = to publish easy to use open source implementations. If we do that and = there is real interest then we might be able to convince people here = about the need. In line with this ambition I have done the JS and Java = publications. This might also show there is no actual interest and then = that is also an outcome. =20 Best regards //Samuel =20 =20 On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann > wrote: On Oct 22, 2018, at 04:47, David Waite > wrote: >=20 > intermittent interoperability failures until a new language runtime = release which revises the numerical print and parse functions Note that this is not a theoretical concern, as CVE-2010-4476 and = CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence = of the latter in = https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-inco= rrectly/ Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ jose mailing list jose@ietf.org =20 https://www.ietf.org/mailman/listinfo/jose =20 ------=_NextPart_000_0373_01D46F7C.FCD91520 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I would = look at creating a new working group in the IETF rather than using an = existing one.

 

  1. Get a personal draft = published
  2. Find a cadre of people = who are interested and think it is solvable
  3. Write a charter
  4. Talk to the ADs about = getting the WG formed by holding a BOF

 

The first = three should be really easy to do.=C2=A0 The fourth may take a bit of = work but should be doable.=C2=A0 The trick with the IETF is to find = people who want to work on things and not to worry over much about the = people who don=E2=80=99t think it is solvable.=C2=A0 If necessary write = the charter to say you are not going to cover some things or that you = are going to require specific environments for your solution.=C2=A0 The = tighter the requirements the easier the solution but the less harder it = might be to get the cadre of people.

 

You should = be looking at 1) one or more authors, 2) half a dozen or more reviewers, = 3) at least a couple of people who think they are going to get this = implemented.

 

Jim

 

 

From: jose = <jose-bounces@ietf.org> On Behalf Of Bret = Jordan
Sent: Sunday, October 28, 2018 8:04 PM
To: = Samuel Erdtman <samuel@erdtman.se>
Cc: Anders Rundgren = <anders.rundgren.net@gmail.com>; Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com>; jose@ietf.org; = david@alkaline-solutions.com; Carsten Bormann <cabo@tzi.org>; = James.H.Manger@team.telstra.com; Phil Hunt = <phil.hunt@oracle.com>
Subject: Re: [jose] Canonical = JSON form

 

Oh there is = real need.  Several standards and implementations inside the IETF = and outside the IETF in other SDOs need this.  So in my view there = are a few options:

 

1) Try and convince a working group here in the IETF = that this is a good idea so we can actually work on = it. 

 

2) Work on this in another SDO outside the IETF (ETSI, = OASIS, ITU, etc etc etc)

 

3) Do this work as an industry standard similar to = what happened between W3C and WHATWG. 

 

I = would personally prefer that this work be done here in the IETF. =  But there seems to be a lot of resistance here. I am willing to = work on this and help make this a reality.  There is a lot of great = prior work on this.  

 

Maybe we can have a meeting in Prague?  Or I can = setup a Telepresence WebEx after Bangkok and all those that are = interested can join and we can discuss next = steps. 

 

Thanks,

Bret

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

= "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg."



On Oct 28, 2018, at 2:32 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

 

In my opinion we can create a good canonicalization = format for JSON to be used to sign cleartext = JSON.

 

As can be seen on this list many are skeptical so my = approach would be to publish easy to use open source implementations. If = we do that and there is real interest then we might be able to convince = people here about the need. In line with this ambition I have done the = JS and Java publications. This might also show there is no actual = interest and then that is also an outcome.

 

Best regards

//Samuel

 

 

On = Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <cabo@tzi.org> = wrote:

On Oct = 22, 2018, at 04:47, David Waite <david@alkaline-solutions.com> wrote:
> =
> intermittent interoperability failures until a new language = runtime release which revises the numerical print and parse = functions

Note that this is not a theoretical concern, as = CVE-2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by = the re-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-22507385= 85072012e-308-incorrectly/

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

_______________________________________________
jose = mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

------=_NextPart_000_0373_01D46F7C.FCD91520--