From nobody Tue May 7 14:33:05 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEC712024D for ; Tue, 7 May 2019 14:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 bZvuJlFDdGcZ for ; Tue, 7 May 2019 14:32:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 286CD120248 for ; Tue, 7 May 2019 14:32:55 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x47LWpDl021123 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 May 2019 16:32:53 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1557264773; bh=BZbGl1JGe5hqd7ifm4GZ5BXHnGGeyA5WQ3zzduPDYj4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jmQ1qnG9s/urvueiaivj0Qz38f33cT+TK5cks9/r3giLLnHAv3ReljthWvF2dAyew FHuk6Djxy6WRJ1YU4TarpIEmc+ojO4tS/2RIqk6pcVAexxlGM95MjDIiWShwK7iNn9 ffIHBEC5iKEsi0wcQQ0loBFfEv3c2STHywJMX4V8= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A09AAC2E-11F3-43F4-A576-3315E7C5E827"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 7 May 2019 16:32:45 -0500 In-Reply-To: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> Cc: dispatch@ietf.org To: Bret Jordan References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:33:03 -0000 --Apple-Mail=_A09AAC2E-11F3-43F4-A576-3315E7C5E827 Content-Type: multipart/alternative; boundary="Apple-Mail=_4151F541-E834-4B91-A500-00F8578D47C5" --Apple-Mail=_4151F541-E834-4B91-A500-00F8578D47C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as DISPATCH chair) It would be helpful to hear some more voices here. Does anyone else have = opinions? Especially people involved in those side meetings? Bret, could you offer a very high level summary of the side discussions = from Prague? Thanks! Ben. > On Apr 29, 2019, at 1:44 PM, Bret Jordan = wrote: >=20 > Dispatch, >=20 > During IETF 104 there were several meetings and sessions about the = proposed JCS solution. This JCS solution defines a way to canonicalize = JSON data to enable hash-able JSON. After listening to and working = through most of the concerns that were raised, there seems to be some = significant interest and use-cases for moving this work forward. >=20 > We respectfully request that DISPATCH look at this work and determine = where it would best fit in the IETF. We would also like to request that = DISPATCH add this to the next interim or full meeting. >=20 > The current draft can be found here: = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05= = >=20 > Further, many successful implementations for several different = platforms as well as a public "playground" https://mobilepki.org/jws- = jcs/home have been created to show that this = not only works, but is pretty easy to implement. >=20 > Personally I know many organizations and solutions that desperately = need this for production. Thank you for your consideration. >=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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_4151F541-E834-4B91-A500-00F8578D47C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii (as = DISPATCH chair)

It = would be helpful to hear some more voices here. Does anyone else have = opinions? Especially people involved in those side meetings?

Bret, could you offer a = very high level summary of the side discussions from Prague?

Thanks!

Ben.

On Apr 29, 2019, at 1:44 PM, Bret Jordan <jordan.ietf@gmail.com> wrote:

Dispatch,

During IETF 104 there = were several meetings and sessions about the proposed JCS solution. This = JCS solution defines a way to canonicalize JSON data to enable hash-able = JSON. After listening to and working through most of the concerns that = were raised, there seems to be some significant interest and use-cases = for moving this work forward.

We respectfully request that DISPATCH = look at this work and determine where it would best fit in the IETF. =  We would also like to request that DISPATCH add this to the next = interim or full meeting.  


Further, many successful implementations for several = different platforms as well as a public "playground" https://mobilepki.org/jws-jcs/home have been created = to show that this not only works, but is pretty easy to = implement. 

Personally I know many organizations and solutions that = desperately need this for production.   Thank you for your = consideration. 


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."

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

= --Apple-Mail=_4151F541-E834-4B91-A500-00F8578D47C5-- --Apple-Mail=_A09AAC2E-11F3-43F4-A576-3315E7C5E827 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlzR+X0ACgkQgFZKbJXz 1A2T4Q/+MVKaW5PfdD6jrDczv6fiIejS0IJ14mt83k8Qibw82FUBULcyA4jDiz2p y6fBjkYg9OK67a3nXQwHnWXU6mGlBoo6mDOnCbKXl20uv4N1GbklF/HrbYBKIKaj aOOq8sKR4wiJX2f+Pc26NITCmSpzUf5UddQhc8TSOstY+n4KKS98l4BRkT0JRry4 B3u/tJq5XyG7wz61KqVT4oiaYyfmOuaG/NDTdmrYLu5WF/3NW1MudRcoJdyou1jC ZkBuLKBEnWLGXV+9FpOh4FUWmgOuoLWlCfs1yqOpgoD76WVynWmtnDcazdUWEoQY liEnAg9M7DN9hC5N+qYk2goJYt71GOAIjsN3scw6P9eHiLpTJfr4zJQ/l6qEf8x8 1kDlrPigsm16V3mwD5UvwtQrIrgBQwU7X/JEw+9qeh3z4Kv9/GYd8YpK6HPgFnMU fL1facsHacc2doCrGoY6+dthGCStZhHieKMfmnDf9F1fMRIgnkgJSEOLeEi+dh6f OF6cSTWmfcIDJNNNw3sjo4rwDaPzKlBxdWi23DmeOQYq7r+9NeNQXhhw9Di5n5wv 3/UScyv5tnE2SqfYNyA/r5N3tyon8779i64PXKK5/Dxtxafw1oLxvs6g3+0DeaxY OC7lffdbfaY8apmWmNAi8AbwMW1LVp++7ZG81CipXzz9Jk2M4BA= =1aag -----END PGP SIGNATURE----- --Apple-Mail=_A09AAC2E-11F3-43F4-A576-3315E7C5E827-- From nobody Tue May 7 14:36:49 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6520712015D for ; Tue, 7 May 2019 14:36:48 -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=rtfm-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 z__vxC_FqMDO for ; Tue, 7 May 2019 14:36:46 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 BED081200EF for ; Tue, 7 May 2019 14:36:45 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id o16so12938545lfl.7 for ; Tue, 07 May 2019 14:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CvVMLtz4S04CIYy8R9RhWSs5nbtvrlKiTOluH5XaAz4=; b=syPdZse5PX8QjhaJkPag+geWKf+3fyfMyUjN3RZz8rThzzs/a4Tkclv2AzwDL2f07C OZb5EacDUjge2YTUjSAUMW81a8QcDfsQJp0Kb1uKvYiEhs8UFYFdwfRG8QfVWaG0mPmJ YItD9FOjgcdQrCymwcsJdT2Zv3bSfb2hqi4JnfScmXkYDhv5iZ0BOPm4JCxzt7U0VoAL ZNhe82/q9i5GWyoK8CXhtrT2cLaYcBWMwB85BulAIiz7ip3xExmiMH9vOGobvh+h/0mu o8wxj2Ge9h1b7YQpStO1Qv8qOqbtKVzDfzpvcKPaPEhXSpYv6q+JEoDqk15Y4J2U8zBd m11Q== 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=CvVMLtz4S04CIYy8R9RhWSs5nbtvrlKiTOluH5XaAz4=; b=q/aE+w90E5nxGnH+rmfYKXlmck+fFVDy8viy1Ihol8Kh6yduBSb3UfAmQsHD4DC7qv zYARSQ7xD9P+FEenqsvuaD7sVayc5Y3AMgbpf0T+dLKuAMawc35vL90kPsna9Qk5JNCg wx4ae1OGLWKCfFQRsAsaD7jt0D1xrEZIbik+mjlQuPA6bj7knucBAdTsMO7L3RnoZHro O1xS1bVeYDoULWzlFH4GBBR19G8uLmzjsfKRXXrV/VaQs5+Iz/wNvuN4E9CC6tggcuZT lxQ5Gk4+HVwCwTsevJGSGWWal8FrnwRXZ2oYKP6ExPGILWNEgRVWIwSRzXnlTlAuIAOY Vtpw== X-Gm-Message-State: APjAAAVEQdpCA1mm8+lU98yNAcjtyqdK3N3Z6M9cOkaO2gF9E/HOZeIf c0IwXu4FlfqSj3+8byahG4djN3M2nDRgNi/pdIxkzQ== X-Google-Smtp-Source: APXvYqxCPKtXY5RQqzbSPU7HS5STSyus1A7cLykzwjPvpjCivWuGQdxkJ8Y3QHiu3SoYpjRifGficNKY54efoBcT818= X-Received: by 2002:ac2:4479:: with SMTP id y25mr7849722lfl.95.1557265004018; Tue, 07 May 2019 14:36:44 -0700 (PDT) MIME-Version: 1.0 References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> In-Reply-To: <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> From: Eric Rescorla Date: Tue, 7 May 2019 14:36:07 -0700 Message-ID: To: Ben Campbell Cc: Bret Jordan , DISPATCH Content-Type: multipart/alternative; boundary="00000000000062d0c80588530308" Archived-At: Subject: Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:36:48 -0000 --00000000000062d0c80588530308 Content-Type: text/plain; charset="UTF-8" On Tue, May 7, 2019 at 2:33 PM Ben Campbell wrote: > (as DISPATCH chair) > > It would be helpful to hear some more voices here. Does anyone else have > opinions? Especially people involved in those side meetings? > FWIW, none of this has really changed me opinion of this from Prague or made me more enthusiastic about this work. -Ekr > Bret, could you offer a very high level summary of the side discussions > from Prague? > > Thanks! > > Ben. > > On Apr 29, 2019, at 1:44 PM, Bret Jordan wrote: > > Dispatch, > > During IETF 104 there were several meetings and sessions about the > proposed JCS solution. This JCS solution defines a way to canonicalize JSON > data to enable hash-able JSON. After listening to and working through most > of the concerns that were raised, there seems to be some significant > interest and use-cases for moving this work forward. > > We respectfully request that DISPATCH look at this work and determine > where it would best fit in the IETF. We would also like to request that > DISPATCH add this to the next interim or full meeting. > > The current draft can be found here: > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05 > > Further, many successful implementations for several different platforms > as well as a public "playground" https://mobilepki.org/jws-jcs/home have > been created to show that this not only works, but is pretty easy to > implement. > > Personally I know many organizations and solutions that desperately need > this for production. Thank you for your consideration. > > > 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." > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000062d0c80588530308 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 7, 2019 at 2:33 PM Ben Ca= mpbell <ben@nostrum.com> wrote= :
(as DISPATCH chair)

It would= be helpful to hear some more voices here. Does anyone else have opinions? = Especially people involved in those side meetings?
=

FWIW, none of this has really changed me opinion of thi= s from Prague or made me more enthusiastic about this work.

<= /div>
-Ekr


Br= et, could you offer a very high level summary of the side discussions from = Prague?

Thanks!

Ben.

On Apr 29, 2019, at 1:44 PM, = Bret Jordan <= jordan.ietf@gmail.com> wrote:

Dispatch,

During IETF 104 there were several meet= ings and sessions about the proposed JCS solution. This JCS solution define= s a way to canonicalize JSON data to enable hash-able JSON. After listening= to and working through most of the concerns that were raised, there seems = to be some significant interest and use-cases for moving this work forward.=

We respectfully request that DISPATCH look at thi= s work and determine where it would best fit in the IETF.=C2=A0 We would al= so like to request that DISPATCH add this to the next interim or full meeti= ng. =C2=A0


Further, many= successful implementations for several different platforms as well as a pu= blic "playground"=C2=A0https://mobilepki.org/jws-jcs/home=C2=A0have been create= d to show that this not only works, but is pretty easy to implement.=C2=A0<= /div>

Personally I know many organizations and solutions= that desperately need this for production. =C2=A0 Thank you for your consi= deration.=C2=A0


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

_______________________________________________
dispatch= mailing list
dis= patch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch<= br>

_______________________________= ________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000062d0c80588530308-- From nobody Thu May 9 09:40:38 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3451E120141 for ; Thu, 9 May 2019 09:40:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXlyOb40BixC for ; Thu, 9 May 2019 09:40:34 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 62A9312006B for ; Thu, 9 May 2019 09:40:34 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id f22so1928026iol.11 for ; Thu, 09 May 2019 09:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YLRlcuCucy9ac+6Lyv6zj3hN6l3IGgmy6z/kDeScpjo=; b=Y/JKuctn78AjcUZjj8yBGpcv841T6Ha7Y1EBxhN9j+sVrGgWys4guKwnuKs+IzgZOb XLBmHdic35cvldjjlojvAjFnMWjEZ/0nO1FAlyErdpx+5uah8E0jmOvtFWxNZk1DnfWZ 8UPDFOT0MChNKcpN8z8XrB9QFzJW22fyCIQJJDixkIrp2tKzDYCdcqht03xUM9Vp2ACR nQTyMeLUFlHyLc8XCrkhweTLIXtT5Us1FFevNZubw1IrFgkE70ihDzKbTiYvWxwTcnAU h2/Xw9tpaPF5XgPexy6spzc5c3vOl+pz/1nEYIwXGYuydqBIcgt/JkcgPaetkfJGIsV3 up/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YLRlcuCucy9ac+6Lyv6zj3hN6l3IGgmy6z/kDeScpjo=; b=KA7NAlSBLpOkDYwpFaHdiHuJZCC01HLsvxUUQx5nBucpfA0bq3PJTxWXPLDJn86AyT RvpmJzuVwuPJK8T7CmKln7o2gFst5Hk9q5FJhiocfzvG6j8ueju5tNHtuPCfgh0yfq/D NUwqVNaDY6UF8ichVqdk1TNRmqtZwMJfFFkCFmJcCnOsgp0JlBA0DCykko5tRjiOL6Bm wbzOx7LXNk0lEPKLJUk3gaKmhCudcZuUlwBd4XlVBCdIowtF5Ha3cTshr5A0e+If29O+ 7imYeLQj54sulLgPdmNQU17Bg+47vDDyVsmi4MnIZHh0H7DLuOCMMGjuNjKaz39zG+L2 51WA== X-Gm-Message-State: APjAAAVwDB9nPgH4HZoAU0Zs1Bvz79W3v2bTDd6FU2XmayjSUAOaDNtT Qw+Grrpk07f60oxH/4Uy7dY7xwcuEtnpyA== X-Google-Smtp-Source: APXvYqxQjjkL7HvNInRueYGK2hhfukocpROr8qrrCdd3hhddJcw+3mX45jSZbKgqQZZZYm5fg8Vpig== X-Received: by 2002:a5d:8410:: with SMTP id i16mr3345965ion.249.1557420033360; Thu, 09 May 2019 09:40:33 -0700 (PDT) Received: from mmiller-44677.local ([207.126.127.114]) by smtp.gmail.com with ESMTPSA id t196sm3363214ita.4.2019.05.09.09.40.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 May 2019 09:40:32 -0700 (PDT) Sender: Matthew Miller To: dispatch@ietf.org References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBPQQTAQoAJwUCWKsJ1AIbAwUJC8ckMQULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDs 9HJOEJ4Fu1iBCADAcW06d/7GTlBjTlYuMGgjzDBoWeQ9/zxgMnSrgNb6yO7wHzE65CeFs6OI 6LQ4A34CNM3hhcWDIzlqrV25fVyy7qCh6bCNMs1pOT63+Od4kcjHtUnGGTONT5fXSGY7mCtl XJFjb3TwyLUZXQCifhCIaUdF/4SVoGk96W9ssbDKN+5xq7B7gyVkwB0WM67zxt/kC6TPcXXL 5m7jsNRpRmFQqOlIF+HrQAcSr1lKRWgetb1VHfXCgcmDaTKn1QC7s0Ml+27dc0SoIkBI8cnv inJ4oFYWrvnTlOvv+v8AFXZnPrxZ/JYvnVD/y5PX7v08Z8RFXm1AmVxIWjXPI6TySkGvuQEN BFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5tNBeQkwVrvitUjHTKKipjxB2kEkUZ oxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmVHgHj7TT8spa6A/qIccdiIRNsFVvl vFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B4K+vjbgFJAvsoLfzLZ5Bz3kb6dpu xUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4Sr8CRkpoMB25rxCPS8R+ByiHxpq+U 8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6+xlJXu5U/fqDAClTj5mfABEBAAGJ ATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4FuwUCWm+kiwUJC8tagQAKCRDs9HJO EJ4Fu40cB/9xyEnuQegivmL6OBVG5HvUAaXGUxtWiWdLm3NrduL0h7rctF060xQTekNRCjbl xZ1w/unPDBEEIMPYbF8i7IwJZoRLTG1B1MjI04AUU60G0IU6uw0ST6IsC7oYGvhDNJApbVBb j9u9x+kzaktCftl3qdpSKgRh9McIyZgevuFBdo80RDtX8niktUA3xsfJWBD1yJA33UNSzqOe 54wFRbsM2+4erREPMD659h2lACPCXjPW/6ucnv0/cdPF8V2JNMCT0yPJVCSUfFLTrtyYtiRI 6S52cI4eEOZIXCQp30TA4E27O2mMLOYzlKA5P5T+Icf4gz8e/puNUKIBDlY6KF7p Message-ID: <7e5fa6bd-2e32-51f4-d218-7537cb5a4f9e@outer-planes.net> Date: Thu, 9 May 2019 10:40:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 16:40:36 -0000 On 19/05/07 15:32, Ben Campbell wrote: > (as DISPATCH chair) > > It would be helpful to hear some more voices here. Does anyone else have > opinions? Especially people involved in those side meetings? > As expressed at various sessions at IETF 104, I think this work carries consequences. As it progresses, I think use cases need to be discussed and their consequences considered and documented. JSON is a simple format, that has and is used for representing complex things. JCS is not going to cover all those things by itself. - m&m Matthew A. Miller From nobody Thu May 9 22:40:38 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B773120169 for ; Thu, 9 May 2019 22:40:37 -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 sAr1O_p8v6WK for ; Thu, 9 May 2019 22:40:35 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 F049212015D for ; Thu, 9 May 2019 22:40:34 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id d12so6080285wrm.8 for ; Thu, 09 May 2019 22:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5VCm1yyjvlSzjfvlpN6grJArDixDC0mO13tjfhMgu40=; b=DgSmf6iuZY7M6M/f9ubaX2SOBeXS4x/2FWVQKCoo1NFvxhHomoksiyx/vrXQlavXtD TMmUDwovA9ZwlnNtOqmSVf/kTJxhbOxmrl/aCSiAIj0g6wocGOhOb070vHGySsqBN5YU 1e3OOiNO7NWhFVZtlhCql8ak2LPtqoNOIbtFdOxZsV9Zc1NgbUtIGBeaa3Y6MZg6D0Fw eaxOHAGbs+PFifYp91NxJ3w1csLTHjj65QvzXztbuRfdGi45M4veNGzKfcG63sbcXajo qqLeTKugKy2W/l2cSy6bqTSfOWSQ15SyOBWTmYBfxUSpjA31swKUQh5IiFTScljPOIWl U5oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=5VCm1yyjvlSzjfvlpN6grJArDixDC0mO13tjfhMgu40=; b=s6j1HIK314JVlhFuedbuWqG5Un9gR/iaUGfKvefdTMEKj+gJqaQ0qHbDOUJFriKjnO hbYvEBWy0b22ixNsVoS9iHDWlCxyDuGdKcuTeLXA5EtRHwOC6TqhnsuqDMiPgYnkESVq KZ8XbZBi6VzKIbo0H/Sg0KBjamCyGdkNGQ4g48XGI0JFql/LZ4VervPC5n3Wb4rpSTcb LhOqw/ag7dx5zgvqkP5qrpY5ZKHGCg7Y9HV+/3Fa2Ie+8tvf8Fg4LwbbnU/NkMWEs5NX Qh3QjMlMaFU4Ul7bFq8Seiyq/sqflOQ+RQpUtxbmBPa0tRs2ueMy3qomnoErsQDHth2Y mOfQ== X-Gm-Message-State: APjAAAWc7zd8K20rs8LBVqdK//Ye7Y3f/HHt5zHp+t+YeEUTBtwbQyJC jwZQ+AsVBDfwaorJwLMHbxvH3v7lu+4= X-Google-Smtp-Source: APXvYqyMllRKMPxNn3X9pDrEroU1on0+QXVi1XRR6htflTiqSeu9lyD6D0RccLvwgjavtIvt5VEaFA== X-Received: by 2002:a5d:4707:: with SMTP id y7mr6514397wrq.59.1557466833202; Thu, 09 May 2019 22:40:33 -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 o6sm10762925wrh.55.2019.05.09.22.40.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 May 2019 22:40:32 -0700 (PDT) To: DISPATCH From: Anders Rundgren Message-ID: Date: Fri, 10 May 2019 07:40:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [dispatch] JSON Canonicalization - IETF-104 Meeting Summary X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 05:40:37 -0000 Hi Guys, I have tried to the best of my ability to collect and comment on the issues raised during the 3 meetings held at IETF-104: https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html I have just been made aware of that IETF's maybe most ambitious effort creating signed HTTP requests[1] was shot down, making another, less known scheme[2] to some people's dismay turning into a de-facto standard for (at least) Open Banking.  Why was it shot down?  Because it wouldn't work reliable in inferior server configurations which IMO sounds like a pretty unreasonable requirement. Yes, JCS also won't work satisfactory in every possible scenario but it is clearly stated what the lower bar is: - JSON Numbers MUST conceptually be treated as IEEE-754 double precision data during parsing/serialization - JSON Strings MUST (modulo escaping) be treated as immutable during parsing/serialization The rest is close to trivial. Thanx, Anders 1] https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ 2] https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ From nobody Fri May 10 08:44:13 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB33120139 for ; Fri, 10 May 2019 08:44:11 -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, 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 (1024-bit key) header.d=pingidentity.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 uKvfu_DAJmqP for ; Fri, 10 May 2019 08:44:08 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 6CB321201D2 for ; Fri, 10 May 2019 08:44:07 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id u16so7935375itc.0 for ; Fri, 10 May 2019 08:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q0oQTeL2j2BE+Lj3SFBj1sweUSaYCavkxkqzqmCeO2w=; b=PUMIhA2EYmsWC5lDK9TUJ7p+qrLhUArf3P/DgM1WPo1GUfZIZ5eLhWoSbFUI4pj7oW gO5/+fRMhMbq3+kRrIKaYkHBfg3rSyi/8B1tdVM2VoLSfAqD3zfxaqkwe44F0QEov5h+ XbfNqIJB5waFtcvnr67YntvJAP7rQFRSVYZ7A= 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=q0oQTeL2j2BE+Lj3SFBj1sweUSaYCavkxkqzqmCeO2w=; b=nm8Wu5ZZoSC3rIUDdM9zIGjhFQZDpH05s3ly9HabYKVYsJQ3q66gM5z2EFONNrldzh ibaFa+i4DsBh/S6E9VjXZGC5ES4o1EMyG1vlEsngvCQLXFFs07hxo4PrkvoQazi7gaRA OHLqOm3sloSpXNvRa43cW2boN9vQ2cewKdDBPD2EAiZP/wWZir3sSBGwp5z2ixKNUkqj bNWn3vPTKB4BE/wb/o2ooPwqKNX0xmcbZZ9ZOQ3aoT+tr62OyEWrrnQBda0atcdwnl0Q E/YvjNYaJQJSYVpQgMcbJ/GsTWX/US3N6zNj3NcXdXgvQFt0OwVqi1RuUOcwqD2kr30E LOqA== X-Gm-Message-State: APjAAAXvEvBxNQrynH+VsL/2cnilZAM/Fa6bywDlLDbTF17NbJ93YbaO 4ojsiTwm3+3ekzaCd5cwKgvMeclt69/AT/ByBX9eq4TFOa1p6gT67UV2Hv1R0F1Mwp1Eb+8Q83y /qsvuGzJtdAMwM8QV+jF+MWI= X-Google-Smtp-Source: APXvYqzpO2opPUIaagd5Rk/yVBYjXl/No7fTdEsB7DU6+9wghfaqhyxdT0gSBEk1GHLe8P8p6cTmbXC3/wi9jTZU+Uo= X-Received: by 2002:a24:9289:: with SMTP id l131mr7934345itd.45.1557503046479; Fri, 10 May 2019 08:44:06 -0700 (PDT) MIME-Version: 1.0 References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> In-Reply-To: From: Brian Campbell Date: Fri, 10 May 2019 09:43:39 -0600 Message-ID: To: Eric Rescorla Cc: Ben Campbell , DISPATCH Content-Type: multipart/alternative; boundary="000000000000d28b8605888a6fbd" Archived-At: Subject: Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 15:44:12 -0000 --000000000000d28b8605888a6fbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Similar to Ekr, none of this has really changed my opinion of this work or made me more enthusiastic about it. https://mailarchive.ietf.org/arch/msg/dispatch/RCRQgw69-jn0IlwnH1JTA7dwOlE On Tue, May 7, 2019 at 3:36 PM Eric Rescorla wrote: > > > On Tue, May 7, 2019 at 2:33 PM Ben Campbell wrote: > >> (as DISPATCH chair) >> >> It would be helpful to hear some more voices here. Does anyone else have >> opinions? Especially people involved in those side meetings? >> > > FWIW, none of this has really changed me opinion of this from Prague or > made me more enthusiastic about this work. > > -Ekr > > >> Bret, could you offer a very high level summary of the side discussions >> from Prague? >> >> Thanks! >> >> Ben. >> >> On Apr 29, 2019, at 1:44 PM, Bret Jordan wrote: >> >> Dispatch, >> >> During IETF 104 there were several meetings and sessions about the >> proposed JCS solution. This JCS solution defines a way to canonicalize J= SON >> data to enable hash-able JSON. After listening to and working through mo= st >> of the concerns that were raised, there seems to be some significant >> interest and use-cases for moving this work forward. >> >> We respectfully request that DISPATCH look at this work and determine >> where it would best fit in the IETF. We would also like to request that >> DISPATCH add this to the next interim or full meeting. >> >> The current draft can be found here: >> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-= 05 >> >> Further, many successful implementations for several different platforms >> as well as a public "playground" https://mobilepki.org/jws-jcs/home have >> been created to show that this not only works, but is pretty easy to >> implement. >> >> Personally I know many organizations and solutions that desperately need >> this for production. Thank you for your consideration. >> >> >> 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." >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d28b8605888a6fbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Similar to Ekr, none of this has rea= lly changed my opinion of this work or made me more enthusiastic about it.= =C2=A0 https://mailarchive.ietf.org/arch/msg/dispatch/RCRQgw69-= jn0IlwnH1JTA7dwOlE


=
On Tue= , May 7, 2019 at 3:36 PM Eric Rescorla <= ekr@rtfm.com> wrote:


On Tue, May 7, 2019 at 2:= 33 PM Ben Campbell <ben@nostrum.com> wrote:
(as DISPATCH chair)

It would be hel= pful to hear some more voices here. Does anyone else have opinions? Especia= lly people involved in those side meetings?
FWIW, none of this has really changed me opinion of this from = Prague or made me more enthusiastic about this work.

-Ekr


Bret, could you offer a very high level summary= of the side discussions from Prague?

Thanks!

Ben.

On Apr 29, 2019, at 1:44 PM, Bret Jordan <jordan.ietf@gmail.com> wrote:
Dispatch,

During IETF 104 th= ere were several meetings and sessions about the proposed JCS solution. Thi= s JCS solution defines a way to canonicalize JSON data to enable hash-able = JSON. After listening to and working through most of the concerns that were= raised, there seems to be some significant interest and use-cases for movi= ng this work forward.

We respectfully request that= DISPATCH look at this work and determine where it would best fit in the IE= TF.=C2=A0 We would also like to request that DISPATCH add this to the next = interim or full meeting. =C2=A0


Further, many successful implementations for several different plat= forms as well as a public "playground"=C2=A0https://mobilepki.org/jws-jcs/home= =C2=A0have been created to show that this not only works, but is pretty eas= y to implement.=C2=A0

Personally I know many organ= izations and solutions that desperately need this for production. =C2=A0 Th= ank you for your consideration.=C2=A0


Thanks,
<= span style=3D"font-size:11px">PGP Fingerprint:=C2=A063B= 4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, howe= ver, the only thing that can not be unscrambled is an egg."

_______________________________________________
dispatch= mailing list
dis= patch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch<= br>

_______________________________= ________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000d28b8605888a6fbd-- From nobody Fri May 10 09:01:03 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8C8120250; Fri, 10 May 2019 09:00:57 -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 JfKFMd1VTUWl; Fri, 10 May 2019 09:00:55 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 BFA9C1201D7; Fri, 10 May 2019 09:00:54 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id n4so5535642ljg.4; Fri, 10 May 2019 09:00:54 -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=9OtQVTX7dviGTtN8Rrf7aB3wVpyyV5ArcDX933mORVg=; b=lz4yUqUZ3qbqDex9B6HMMUn1f1rj8Z8wW2zwk2zqkSrhP2xaJnUrqdR4llw/z3IQEH 7JCUT6lgQPuAPHFwB3EavkJLMwxUXSRMni8gfNku1wGz84/ndunk8fTCxu+/QlIRYtAW BhaV/iWRQ8uyTDEK0wFHKFiYHepX+/5lrNmvity7mo2KtXzZxCbLindszJYyUid4Qb1M VBmj2v7OU3XI4hRHKpjp8jOpJTqgX/tS29+7KC5/ATdz5T0tNKk29MxwaQ6zH3S0htTT ZbYYYNtAKHn90YREToMH7wxyeH7klHgDRTBYhrJvMBBWexxR01Gb8dMdR96bn8mnN5xc hp5g== 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=9OtQVTX7dviGTtN8Rrf7aB3wVpyyV5ArcDX933mORVg=; b=Yw6nE11FYd8/jpj4jsFnpeBCGF0Nr/ofGFVdVeiSt0gUdEP6y7XxhblAf9M5TnIIJM TfioWpoXTMVEpVZodGgFdIh5mQ8kI7Roj0c/df0Njb9OR/md6sZuYn0ROy2rU2CE3Qfj 7dFQ5+q7HgEFBnZuhFY6aDe0qbqHgX+Dr0Yk15t4pUWU9sevM/8JkWU5xyl/pu0tnCmS JGXyWinFsQeMMCnKKYPLCH4OxxAUFQyXGtYBe9IYc602NhIAPAY4o5lxUJT859jvbAn1 jdKnlE2+Cw4vg5PdiNCFgl2cyt4kN6IF/GvzvXmoH94NtUcCSlI+c0bRseRYI0xZvZAX duJQ== X-Gm-Message-State: APjAAAVEhYDeoEc84FFBFHTueMOxEFOuYDPII9weQj0vRTpZrZey5cim PiKDWEW86UZ6a0khju0du3maQM9wDteGgY4CmexdW1Tc X-Google-Smtp-Source: APXvYqyhimKg7amPP2z0EibuTyCn+VMdpZ8rtBvwz88hSPYIHPdYtQgvY9cq1Q8kGWf77dSUtl1Q6nZV6chNphO0+dg= X-Received: by 2002:a2e:6c02:: with SMTP id h2mr6355449ljc.103.1557504052794; Fri, 10 May 2019 09:00:52 -0700 (PDT) MIME-Version: 1.0 References: <76708F20-14F5-4BAB-BD12-D104D3A100B5@ietf.org> In-Reply-To: <76708F20-14F5-4BAB-BD12-D104D3A100B5@ietf.org> From: Mary Barnes Date: Fri, 10 May 2019 11:00:41 -0500 Message-ID: To: DISPATCH Cc: dispatch chairs , ART ADs Content-Type: multipart/alternative; boundary="000000000000cd9b9405888aab0f" Archived-At: Subject: [dispatch] Fwd: BOF proposals due in 4 weeks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 16:01:01 -0000 --000000000000cd9b9405888aab0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Just a reminder that the first deadline for IETF-105 is coming up in 4 weeks. The remaining deadlines that need to be considered for the DISPATCH WG for IETF-105 are available on the wiki and summarized below: https://trac.ietf.org/trac/dispatch/wiki/WikiStart - June 10, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal/topic. - June 17, 2019. Cutoff for proposals (i.e., problem statement and proposed deliverables) for topics posted to the DISPATCH WG mailing list= . - June 24, 2019. Announcement of topics that have been dispatched for IETF-105. - July 8, 2019. Draft submission deadline. A complete list of deadlines for IETF-105 is available here: https://datatracker.ietf.org/meeting/important-dates/ If you have a topic that you are interested in pursuing in the ART area and are not sure the best way to get started, please contact the DISPATCH WG chairs and/or the ADs using the above aliases. Regards, Mary DISPATCH WG co-chair ---------- Forwarded message --------- From: IETF Chair Date: Fri, May 10, 2019 at 9:42 AM Subject: BOF proposals due in 4 weeks To: IETF-Announce Cc: IETF This is a friendly reminder that the deadline for submitting proposals for "Birds of a Feather=E2=80=9D (BOF) sessions at IETF 105 is in 4 weeks: = June 7 at 23:59 UTC. Instructions for submitting your proposal are available at https://ietf.org/iesg/bof-procedures.html. Please also read https://tools.ietf.org/html/rfc5434, Considerations for Having a Successful Birds-of-a-Feather Session, if you are not familiar with it. If you are working on a BOF request but you=E2=80=99re not quite ready to s= ubmit it, please tell the IESG now by sending an email to iesg@ietf.org to get advance help with the request. We have a number of ways of bringing new work into the IETF and BOFs are just one of them, so please talk to the IESG or an individual area director (https://ietf.org/iesg/members.html) about your idea if you=E2=80=99re thinking about proposing a BOF. Thanks, Alissa Cooper IETF Chair --000000000000cd9b9405888aab0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Just a reminde= r that the first deadline for IETF-105 is coming up in 4 weeks.=C2=A0=C2=A0=

The remaining deadlines that need to be considere= d for the DISPATCH WG for IETF-105 are available on the wiki and summarized= below:=C2=A0 =C2=A0https://trac.ietf.org/trac/dispatch/wi= ki/WikiStart
    June 10, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to s= ubmit a proposal/topic.
  • June 17, 2019. Cutoff f= or proposals (i.e., problem statement and proposed deliverables) for topics= posted to the DISPATCH WG mailing list.
  • June 24, 2019. Announcement of topics that have been dispatched for IETF-1= 05.
  • July 8, 2019. Draft submission deadl= ine.

A complete list of deadlines for IETF-10= 5 is available here:=C2=A0https://datatracker.ietf.org/meeting/importan= t-dates/

If you have a topic that you are inter= ested in pursuing in the ART area and are not sure the best way to get star= ted, please contact the DISPATCH WG chairs and/or the ADs using the above a= liases.

Regards,

=

Mary

DISPATCH WG co-chair


---------- Forwarded me= ssage ---------
From: IE= TF Chair <c= hair@ietf.org>
Date: Fri, May 10, 2019 at 9:42 AM
Subje= ct: BOF proposals due in 4 weeks
To: IETF-Announce <ietf-announce@ietf.org>
Cc: IETF <ietf@ietf.org>


This is a friendly reminder that the de= adline for submitting proposals for=C2=A0"Birds of a Feather=E2=80=9D = (BOF) sessions at IETF 105 is in 4 weeks: June 7 at 23:59 UTC. Instructions= for submitting your proposal are available at=C2=A0https://ietf.org/iesg/bof-= procedures.html. Please also read=C2=A0https://tools.ietf.org/html/rfc5434,= =C2=A0Considerations for Having a Successful Birds-of-a-Feather Session, if= you are not familiar with it.

If you are working o= n a BOF request but you=E2=80=99re not quite ready to submit it, please tel= l the IESG now by sending an email to=C2=A0iesg@ietf.org=C2=A0to get advance help with the requ= est.=C2=A0We have a number of ways of bringing new work into the IETF and B= OFs are just one of them, so please talk to the IESG or an individual area = director (= https://ietf.org/iesg/members.html) about your idea if you=E2=80=99re t= hinking about proposing a BOF.

Thanks,
A= lissa Cooper
IETF Chair
--000000000000cd9b9405888aab0f-- From nobody Fri May 10 22:33:25 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779C0120145 for ; Fri, 10 May 2019 22:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, 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 FZ14xezffp_M for ; Fri, 10 May 2019 22:33:21 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 582081201DB for ; Fri, 10 May 2019 22:33:20 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id v11so9867530wru.5 for ; Fri, 10 May 2019 22:33:20 -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=HnaVa2mX7Nu1f6IhgjyK86sSNTJMWoG+zb/5IEwptSg=; b=oSBr2etQgZyuq484687AYaj3OSzf4VU1kl2tKuUO82uTYxpjGKYKoCbme4fnQqFrmA pjOmUJQwV/w1kSMIaRvOv5ZfaF2kImmFS0dODpXNwZdO0kOv13S8EvPgrc2pNT7D2ooN //PrqmeRmWd7cXiZOnY2hj+mwbqcMrpYDDeTvijxiILjxo0RTZ7sMMCYxETPey6QZB9Z Ez4+TQY7IHhDnBNuJhR/OhHLCORllTGJ0Dwd8LTNUbRyB61lDRMyw3AJ1/kwx13bryNZ lJcYEYJyD5Tc94uvZdzqq8HfmpjdDhRuXdLdRxFc9sPJ+2/lHmCF5vI/MZlWrhL5yB+7 Gd9w== 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=HnaVa2mX7Nu1f6IhgjyK86sSNTJMWoG+zb/5IEwptSg=; b=N+N0Q2g8Ja6raRPcylDtJzlOJiGly4/0poCvIeFu12kZxeGi3ou4xq041f7HKXGzpE DECq2otV8FnPI63sZXKebE0Y+xEgAK3NFJ5W3Ru2cl64I77V2tHyvzgyqCXc+zp8jaiq 4BZM09knjiVii1UYD2/O75rbSs004ABlbClgqmt78pIw/kW/Q3gpnMCBuEW3+RDP+W9A VOwaazNdZYFciKlLIU5EbLPPb+kuWv2YZ+JYBpUgIR0rQ4DHZi/NP8m4YGZWOuNZjsWr y63JCcGWY9ySxRjhbP+w0CzYlNZf1QSgG3yeGanMAQuV72JULnkgn/NvJMm+a8SByYkp 4hvg== X-Gm-Message-State: APjAAAVfrdE22mzc6M6yJfAkgzxt3eYTb0TDAytJ/CdyMq1tFy9jPE/k vi8Sa5zNjGmnDe1TO8zMk4sL+jvSiiA= X-Google-Smtp-Source: APXvYqwVpaOGXwSSd2V3DMDg0swOxPvIZmaMIVEKgACJHtK8PZGZ9UMRnJ6DhvWH9vcv8RLeUWID1g== X-Received: by 2002:a5d:65d1:: with SMTP id e17mr9880377wrw.65.1557552798490; Fri, 10 May 2019 22:33:18 -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 p67sm5763538wmp.22.2019.05.10.22.33.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 22:33:17 -0700 (PDT) To: Brian Campbell , Eric Rescorla Cc: Ben Campbell , DISPATCH References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> <2904F41A-539C-496B-ABF2-7D2618FC8116@nostrum.com> From: Anders Rundgren Message-ID: Date: Sat, 11 May 2019 07:33:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.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: [dispatch] JSON Canonicalization Scheme (JCS) Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 05:33:24 -0000 On 2019-05-10 17:43, Brian Campbell wrote: > Similar to Ekr, none of this has really changed my opinion of this work or made me more enthusiastic about it. https://mailarchive.ietf.org/arch/msg/dispatch/RCRQgw69-jn0IlwnH1JTA7dwOlE Brian & Ekr, If the lack of enthusiasm is due to a belief that clear text data is a no-issue [*], I have nothing to add since that is merely an opinion. If OTOH this is rather due to the technology itself a reference to the actual draft would be more than welcome. https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06 JCS is not a fullblown canonicalization scheme like XML's C14; it is a (fairly rudimentary) serialization method. The bad experiences from the XML era BTW were also due to other factors such as Namespaces, SOAP and an elaborate WS* stack which indeed took years to get fully interoperable between vendors. thanx, Anders *] None of the current Open Banking APIs encode their signed messages in Base64Url > > On Tue, May 7, 2019 at 3:36 PM Eric Rescorla > wrote: > > > > On Tue, May 7, 2019 at 2:33 PM Ben Campbell > wrote: > > (as DISPATCH chair) > > It would be helpful to hear some more voices here. Does anyone else have opinions? Especially people involved in those side meetings? > > > FWIW, none of this has really changed me opinion of this from Prague or made me more enthusiastic about this work. > > -Ekr > > > Bret, could you offer a very high level summary of the side discussions from Prague? > > Thanks! > > Ben. > >> On Apr 29, 2019, at 1:44 PM, Bret Jordan > wrote: >> >> Dispatch, >> >> During IETF 104 there were several meetings and sessions about the proposed JCS solution. This JCS solution defines a way to canonicalize JSON data to enable hash-able JSON. After listening to and working through most of the concerns that were raised, there seems to be some significant interest and use-cases for moving this work forward. >> >> We respectfully request that DISPATCH look at this work and determine where it would best fit in the IETF.  We would also like to request that DISPATCH add this to the next interim or full meeting. >> >> The current draft can be found here: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05 >> >> Further, many successful implementations for several different platforms as well as a public "playground" https://mobilepki.org/jws-jcs/home have been created to show that this not only works, but is pretty easy to implement. >> >> Personally I know many organizations and solutions that desperately need this for production.   Thank you for your consideration. >> >> >> 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." >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you./ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu May 16 06:12:02 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9CA120132 for ; Thu, 16 May 2019 06:12: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, 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 4zCT7PKbxLcz for ; Thu, 16 May 2019 06:11:58 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B961200EA for ; Thu, 16 May 2019 06:11:58 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id j187so7030248wma.1 for ; Thu, 16 May 2019 06:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=e6jFoW1tkgROnQxSoFu3KnfjcdLxqj1ufD/yU/zmUgA=; b=kJZoOZTiGdkkF1GY3G6Mh+gXr4zfRGK+yhRZq+nxUB8wP4Qyu3PUkr6ocwKxbNQ+C9 HZOE5fWxB+hIjNfZskMZkxHdcY0qIGvxlsoDIVcRh/qWNe+HFb3+3mLDW8Y7fhQOdMbU submaCunuh31Yg/dlxrw7YsLUTUcAWV2OnY6INYBX/NQHa6a1QGSzALL34HZDX7vii46 fWbweFHQqL44a2324LdO8DP5YtQYJ4xYg33Uv+xg4HmRLAmdsjgfPxrGLmGepPiU2A3t PORX4HUHToP2cBlQso3/xjuyy1Jmm5aBjVlYOlb7mj8XDvskM7aXBBzPqjpIfVQeyjh8 jOTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=e6jFoW1tkgROnQxSoFu3KnfjcdLxqj1ufD/yU/zmUgA=; b=cle8yrmne97siATxGZIoC4ieKCgHGQEOgWw6CeBfpOjKAwkxCIywe+ykaCtKHgQ8m0 SxrkdFU5IcD1UrkP5mqNn//jvLXMAhy2GvFYZSB9SxTHmMcB79SN9ooMwYQE5r6djDK4 MrA14etdroKH1lBQ1KGMUI0DfiLpgoC4QJxqXpu9nQ0Xpzs7q0EyJlIftSTqhElEynM4 34B2UwFwhc75iqYT/+MeNAy8/rC+g5J4CfTkr1UUtyMCRdsgzBC9Ar9ii5oXBkVGA/Lq oIbJeCQAI+77+IsiqWWCEGlPsh7NyfsneVYjpCGnp6rWApgUgc8vP+IpooHAU6BdcseA /xEg== X-Gm-Message-State: APjAAAUOgZeGCGyjE9Kf3Tdd7bGjMQIQ5EvZ3B9rt1I6jW4HWcbbnnma JbFdZeLX58tVcVj0LAEFdYO5O8jFOX4= X-Google-Smtp-Source: APXvYqx5SR7w4DNPDSXEnNP+gqHbjAlkfmB0U14jPrNA/rGe5Lc0/8WSzsZs70kUEhrPl+aHmvRRFg== X-Received: by 2002:a05:600c:230a:: with SMTP id 10mr13905627wmo.13.1558012316198; Thu, 16 May 2019 06:11:56 -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 7sm6551425wro.85.2019.05.16.06.11.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 06:11:55 -0700 (PDT) From: Anders Rundgren To: DISPATCH Message-ID: <2c55fd23-592a-98f0-ee6f-4308a8e43e73@gmail.com> Date: Thu, 16 May 2019 15:11:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [dispatch] Other uses of JCS (JSON Canonicalization Scheme) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 13:12:00 -0000 Since the value of clear text messaging has been unilaterally declared to be zero, maybe other and more sophisticated uses of JCS could be of some interest? In Saturn[1] JCS is used in many different ways including for signatures and encryption. However, the ability to only take a hash of JSON objects has also been put to good work.  Yes, "hashable" JSON is what JCS really is. Slightly simplified.... 1. Merchant creates a signed PaymentRequest in the form of a JSON object and sends it to the User for authorization. 2. The User (SW) creates a JSON object with various properties including a timestamp, account ID and a hash of the received PaymentRequest. 3. The User (SW) signs the new JSON object using an account- and user-specific authorization private key. 4. The User (SW) encrypts the signed JSON object (User authorization) using a bank-specific encryption public key. 5. The User(SW) returns the encrypted authorization object + URL to the User's Bank to the Merchant. 6. The Merchant puts the PaymentRequest, the encrypted User authorization object and a Merchant receive account in a new JSON object. 7. The Merchant counter-signs the new JSON object and sends it to the User's Bank for "redemption". 8. The User's Bank verifies the inner and outer Merchant signatures and decrypts the User authorization object. 9. The User's Bank verifies that the User authorization object is signed by a key matching the claimed account ID. 10. If the hash of the Merchant-supplied PaymentRequest matches that of the hash in the User authorization object the request is considered valid. Next follows the actual payment transaction... Using JWS as is, the PaymentRequest would need to be duplicated in step #2. This may not seem like a big deal but why duplicate data if not necessary? JCS is BTW used some 8 times above. Quirky, ugly and potentially error-prone signature solutions like TEEP's OTrP also isn't my cup of tea: https://mailarchive.ietf.org/arch/msg/dispatch/ULq1QoecXC0xXu6M5o6m3xPtUPQ Thanx, Anders 1] https://cyberphone.github.io/doc/saturn From nobody Fri May 17 10:01:03 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D58120144 for ; Fri, 17 May 2019 10:01: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 Z0BwzbYwYaIf for ; Fri, 17 May 2019 10:00:57 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 6825012013C for ; Fri, 17 May 2019 10:00:57 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id q65so13091108itg.2 for ; Fri, 17 May 2019 10:00:57 -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=a142rN0usmyLSUQXcisBC6JNaqBuq1fooiAhYa19EO4=; b=CSLT3sXndBPaLmWs1Wej1AiDcv/2Rw5pOSGQMXIx9rjYCW2lR0H9+ov9B9UWyIpRnG Q/DTJ54wMVuz4hiB2AYTpo0hdcmaBohtpfZw1eOT23rSLFbRGSwSn/bIqWiYiZ5vXIr7 sB84R2F08MOWpYejQoCfSixJuQqYd6Bm9NQX041apjCMa94kxSN9U9LA/voh7bQN3DCN W0S2l29gZbYv0l5Bsjb5gHWPqJm0jw3WbSrcv+uNo+KjRVdUxPP+GsdyMS/+Zs2zqWmh zhL58kSifMxntrBN3TOly3/iMIfZYlktBqJCaVnTbPt5ievD4i6MZxpKNnBwVO9bJ9RY Qhmw== 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=a142rN0usmyLSUQXcisBC6JNaqBuq1fooiAhYa19EO4=; b=f0bBarxWZgpT1TtN/iC4i9sh/fVScZgYIcp6U5UL3D7pX3xta8JIFyYG0RZ9781Xvm fXfqBkQlVkwYLTDCtsl2m/RRNiAc24PK9joZYkPBDMugqO2aqSotFfp2tFqhQ7PZZ7Um pe6M5enZKGnXNOD3fd9c/CGYspYSNbB4fohgcdPqXWTDKkhrtTt1S3t97v04Tu/PCuPn uOhNLmHkVqqbZGI33b/EEXEOwcMaRwJEHcyJuLgchtO2UmqWmp8z6AyHJ0NnnOC0g0Oi DZgenbL/HYmL5dL+2pq7MBJ+MkAa333VXLUEjlGXMvVEcgXr2QGr+0zSOir2My9l4Ob/ VbXg== X-Gm-Message-State: APjAAAXwwI8WSSx66W33a4OXRvEvdtq4JGUdRsH+8/tTUfTG4VdTwPmJ wnhfVDKxXS5UwJVkrk0zM9o= X-Google-Smtp-Source: APXvYqxfADMEqegJHdu8KWhKLOcsjRWm7JeoJ/fqjcSEgQzcPBBFD/o5RPnv0/5FZB+2PUCMiqjKIA== X-Received: by 2002:a02:5143:: with SMTP id s64mr38553787jaa.54.1558112456639; Fri, 17 May 2019 10:00:56 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:4c14:8bc4:fe81:2a1c? ([2605:a601:a990:4d00:4c14:8bc4:fe81:2a1c]) by smtp.gmail.com with ESMTPSA id m30sm434130iti.41.2019.05.17.10.00.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 May 2019 10:00:55 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_4AD61FC8-0832-47B2-830F-90352292FBF0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 17 May 2019 11:00:52 -0600 References: <2c55fd23-592a-98f0-ee6f-4308a8e43e73@gmail.com> To: Anders Rundgren , dispatch@ietf.org In-Reply-To: <2c55fd23-592a-98f0-ee6f-4308a8e43e73@gmail.com> Message-Id: <79C6CAA9-F5AF-4044-BAF4-9A2B141C12F5@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [dispatch] Other uses of JCS (JSON Canonicalization Scheme) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 17:01:01 -0000 --Apple-Mail=_4AD61FC8-0832-47B2-830F-90352292FBF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Another set of examples are: 1) In the cyber threat intelligence space, organizations, ISACs, ISAOs, = vendors, and tools share a lot of indicators of compromise and higher = level intelligence (threat actors, campaigns, intrusion sets, TTPs, etc) = that is related in a graph (nodes/vertices and edges). In the ecosystem = there can be billions of new objects created on a daily basis. Each of = these are connected to the graph. The data in the objects is acted on = and used all across the ecosystem and is used as linkage to the graph. = What is needed is the ability to have a canonical representation of JSON = so that it can be hashed and/or digitally signed by a producer so that a = consumer will know that it was not modified by a threat actor trying to = poison the data. This community is very large and very stable and needs = JCS or something very much like it ASAP. 2) In the CTI space, one often wants to do semantic equivalency checks = against nodes in the graph. This can be done by using a deterministic ID = method like UUIDv5 from RFC4122 where the =E2=80=9Cname=E2=80=9D is = canonicalized JSON. Another option is using fuzzy hash technologies to = see how different various pieces of threat intelligence actually are. In = both cases, you need a canonicalization of JSON. =20 3) The CACAO work for playbooks and collaborative courses of action will = need the ability to like CTI to hash and sign data, but it will also = need the ability to layer hashes and signatures and also hash and sign = parts of the JSON data. JCS gives us this ability. =20 Some say, well JCS does not work for every conceivable type of data that = someone might stick in to a JSON blob. These individuals would be 100% = correct. But we are not trying to boil the ocean. Nor solve corner = cases and edge cases. We are trying to solve the 98+% use case. = Further, in the CTI space and in the future CACAO documents, we will be = talking about using I-JSON to limit JSON numbers to the IEEE number = anyway. So in this case, the specs will ALREADY support any = restrictions that JCS requires. =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 May 16, 2019, at 7:11 AM, Anders Rundgren = wrote: >=20 > Since the value of clear text messaging has been unilaterally declared = to be zero, maybe other and more sophisticated uses of JCS could be of = some interest? >=20 > In Saturn[1] JCS is used in many different ways including for = signatures and encryption. > However, the ability to only take a hash of JSON objects has also been = put to good work. Yes, "hashable" JSON is what JCS really is. >=20 > Slightly simplified.... > 1. Merchant creates a signed PaymentRequest in the form of a JSON = object and sends it to the User for authorization. > 2. The User (SW) creates a JSON object with various properties = including a timestamp, account ID and a hash of the received = PaymentRequest. > 3. The User (SW) signs the new JSON object using an account- and = user-specific authorization private key. > 4. The User (SW) encrypts the signed JSON object (User authorization) = using a bank-specific encryption public key. > 5. The User(SW) returns the encrypted authorization object + URL to = the User's Bank to the Merchant. > 6. The Merchant puts the PaymentRequest, the encrypted User = authorization object and a Merchant receive account in a new JSON = object. > 7. The Merchant counter-signs the new JSON object and sends it to the = User's Bank for "redemption". > 8. The User's Bank verifies the inner and outer Merchant signatures = and decrypts the User authorization object. > 9. The User's Bank verifies that the User authorization object is = signed by a key matching the claimed account ID. > 10. If the hash of the Merchant-supplied PaymentRequest matches that = of the hash in the User authorization object the request is considered = valid. > Next follows the actual payment transaction... >=20 > Using JWS as is, the PaymentRequest would need to be duplicated in = step #2. > This may not seem like a big deal but why duplicate data if not = necessary? >=20 > JCS is BTW used some 8 times above. >=20 > Quirky, ugly and potentially error-prone signature solutions like = TEEP's OTrP also isn't my cup of tea: = https://mailarchive.ietf.org/arch/msg/dispatch/ULq1QoecXC0xXu6M5o6m3xPtUPQ= >=20 > Thanx, > Anders >=20 > 1] https://cyberphone.github.io/doc/saturn >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_4AD61FC8-0832-47B2-830F-90352292FBF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Another set of examples are:

1) In the cyber threat intelligence = space, organizations, ISACs, ISAOs, vendors, and tools share a lot of = indicators of compromise and higher level intelligence (threat actors, = campaigns, intrusion sets, TTPs, etc)  that is related in a graph = (nodes/vertices and edges). In the ecosystem there can be billions of = new objects created on a daily basis.  Each of these are connected = to the graph.  The data in the objects is acted on and used all = across the ecosystem and is used as linkage to the graph. What is needed = is the ability to have a canonical representation of JSON so that it can = be hashed and/or digitally signed by a producer so that a consumer will = know that it was not modified by a threat actor trying to poison the = data.  This community is very large and very stable and needs JCS = or something very much like it ASAP.

2) In the CTI space, one often wants to = do semantic equivalency checks against nodes in the graph. This can be = done by using a deterministic ID method like UUIDv5 from RFC4122 where = the =E2=80=9Cname=E2=80=9D is canonicalized JSON.  Another option = is using fuzzy hash technologies to see how different various pieces of = threat intelligence actually are. In both cases, you need a = canonicalization of JSON.  

3) The CACAO work for playbooks and = collaborative courses of action will need the ability to like CTI to = hash and sign data, but it will also need the ability to layer hashes = and signatures and also hash and sign parts of the JSON data.  JCS = gives us this ability.  

Some say, well JCS does not work for = every conceivable type of data that someone might stick in to a JSON = blob.  These individuals would be 100% correct.  But we are = not trying to boil the ocean.  Nor solve corner cases and edge = cases.  We are trying to solve the 98+% use case.  Further, in = the CTI space and in the future CACAO documents, we will be talking = about using I-JSON to limit JSON numbers to the IEEE number anyway. =  So in this case, the specs will ALREADY support any restrictions = that JCS requires.  



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 May 16, 2019, at 7:11 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Since = the value of clear text messaging has been unilaterally declared to be = zero, maybe other and more sophisticated uses of JCS could be of some = interest?

In Saturn[1] JCS is used in many = different ways including for signatures and encryption.
However, the ability to only take a hash of JSON objects has = also been put to good work.  Yes, "hashable" JSON is what JCS = really is.

Slightly simplified....
1. Merchant creates a signed PaymentRequest in the form of a = JSON object and sends it to the User for authorization.
2. = The User (SW) creates a JSON object with various properties including a = timestamp, account ID and a hash of the received PaymentRequest.
3. The User (SW) signs the new JSON object using an account- = and user-specific authorization private key.
4. The User = (SW) encrypts the signed JSON object (User authorization) using a = bank-specific encryption public key.
5. The User(SW) = returns the encrypted authorization object + URL to the User's Bank to = the Merchant.
6. The Merchant puts the PaymentRequest, the = encrypted User authorization object and a Merchant receive account in a = new JSON object.
7. The Merchant counter-signs the new = JSON object and sends it to the User's Bank for "redemption".
8. The User's Bank verifies the inner and outer Merchant = signatures and decrypts the User authorization object.
9. = The User's Bank verifies that the User authorization object is signed by = a key matching the claimed account ID.
10. If the hash of = the Merchant-supplied PaymentRequest matches that of the hash in the = User authorization object the request is considered valid.
Next follows the actual payment transaction...

Using JWS as is, the PaymentRequest would need = to be duplicated in step #2.
This may not seem like a big = deal but why duplicate data if not necessary?

JCS is BTW used some 8 times above.

Quirky, ugly and potentially error-prone signature solutions = like TEEP's OTrP also isn't my cup of tea: https://mailarchive.ietf.org/arch/msg/dispatch/ULq1QoecXC0xXu6M= 5o6m3xPtUPQ

Thanx,
Anders

1] https://cyberphone.github.io/doc/saturn


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

= --Apple-Mail=_4AD61FC8-0832-47B2-830F-90352292FBF0-- From nobody Sun May 19 11:57:17 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762C712010C for ; Sun, 19 May 2019 11:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 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, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 yO0zhsABa42C for ; Sun, 19 May 2019 11:57:11 -0700 (PDT) Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E601212011B for ; Sun, 19 May 2019 11:57:10 -0700 (PDT) Received: from mxback15j.mail.yandex.net (mxback15j.mail.yandex.net [IPv6:2a02:6b8:0:1619::91]) by forward104j.mail.yandex.net (Yandex) with ESMTP id 34A854A1267; Sun, 19 May 2019 21:57:06 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback15j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id NtOHa7wzs1-v5OqqNWg; Sun, 19 May 2019 21:57:05 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1558292225; bh=6hxxqRsW5ZFxeQYIc+Bpcx2RE1XOQfequf4cTwhtVCk=; h=Message-Id:Date:Cc:Subject:To:From; b=WlkaY4QBc32G8ZDJEY2HK2QvM11u78IS+HqDUfW62+IpfL8ncSuP2XgzWkWzI9XT8 3TUCCzQvsGMkhP3mqnwJw3FQw2IveHyx6CxzE94PymQri7BNdlMkFSpBUCmGZ5dK2o cgGv5mhNzjH680+wFmWD6yJF/lPmwG9FMxbJIfFg= Authentication-Results: mxback15j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt1-bc8ef50fb490.qloud-c.yandex.net with HTTP; Sun, 19 May 2019 21:57:05 +0300 From: Anton Tveretin To: Anders Rundgren Cc: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 19 May 2019 23:57:05 +0500 Message-Id: <5926571558292225@myt1-bc8ef50fb490.qloud-c.yandex.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] Other uses of JCS (JSON Canonicalization Scheme) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2019 18:57:16 -0000 This does not explain why anyone needs to inflate plain text documents of NGMTP-C9 [http://antontveretin.000webhostapp.com/ngmtp/] into JSON. And why does the data exchange bypass the (implied) payment system? As a payee, I need money and not "authorization". Of course, there is nothing wrong with JCS and its usage. Maybe I will incorporate it into the next version of the NGMTP-C9, or conversely. From nobody Sun May 19 23:30:36 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217391200C4 for ; Sun, 19 May 2019 23:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 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, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, 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 B7yi5wGf7i6k for ; Sun, 19 May 2019 23:30:33 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 7EFDE120041 for ; Sun, 19 May 2019 23:30:33 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id s17so13146351wru.3 for ; Sun, 19 May 2019 23:30: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=NbtT6Ui0lzSQkFKnZpfbA/hl474DMX7Ytf6FrVvkeCQ=; b=b5SfgkiVCCMfOZ9OOz5EMKcYv/T9t9jPlgzul2W8rXzd79pfOo9y6992za2KGc9ECO 32Bk9wyuZrQrpJ6ABjlXhiTyT7DioQQJ8LBbyzoKP/j2aZ9GrYqbPfQKJbgW40gDVWJ9 QEvDv7dZLz3+ZnWpm2satwW9IIypxpe7xL/bDOKseSIOxvEfTV0KJH42pz/kGfPsOqfa j5CI3MT3HsuJmS8lA2X0mOqUTTlGA78iFrwkarnHq6+KR4K5vEISOlXl1WvAf0fAINgC sz54XOJiixfOtqnnlYhV+2rXRpwxShI7L1A+gejG0dcM+0P2q62zayyZG1bDTTTUnb1I QdqA== 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=NbtT6Ui0lzSQkFKnZpfbA/hl474DMX7Ytf6FrVvkeCQ=; b=KxVIZC4wSZy0sZoNYVjIJnARhszrtE8EupPjDJXnCd2NBasNwCoBCqPbkoy8IEMicz DZxG3DVrLkJmbmeIhx68KgcQ8pGtBAqTRhbz8Ym8pC9f48Ls3Zjnf+c+Uc1JiXhEZJci 05Uh2V1nikVL1KJPqyehB07bG6Amsyakv11KLn1swVlg/tFxZ8taJBBG+xqrhEwl0Cem 0sAef0BWYxpDVUmkdJgZ+q2CgC2/vh9JJYC1Mnfcd1qVomcKqgBj3+KBKf33Az5PgJtq PNDZityuPN7IOBA1jirk18iSFJmpex9BuaRag9asXhJFrnJmzN8WPe9Kr1bzFKrv04gw c8uA== X-Gm-Message-State: APjAAAXCq78b6si5lBIJX9medI2N6HGUHGWGOAoNHWkua/el5VWtlPW9 yO+mrxhsbpK4PJM2BIdhw1M= X-Google-Smtp-Source: APXvYqxAiX96Xc72LN8xY3SWELeqKaLDCtFcR3fDQTG6CC+Ff4a15QMXXWKAaUkrJf7c5puOGeJCzw== X-Received: by 2002:a5d:6b03:: with SMTP id v3mr14208854wrw.309.1558333831879; Sun, 19 May 2019 23:30:31 -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 k184sm36556116wmk.0.2019.05.19.23.30.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 May 2019 23:30:30 -0700 (PDT) To: Anton Tveretin Cc: DISPATCH list References: <5926571558292225@myt1-bc8ef50fb490.qloud-c.yandex.net> From: Anders Rundgren Message-ID: Date: Mon, 20 May 2019 08:30:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <5926571558292225@myt1-bc8ef50fb490.qloud-c.yandex.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Other uses of JCS (JSON Canonicalization Scheme) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 06:30:35 -0000 On 2019-05-19 20:57, Anton Tveretin wrote: Hi Anton, > This does not explain why anyone needs to inflate plain text documents of NGMTP-C9 [http://antontveretin.000webhostapp.com/ngmtp/] into JSON. If this http://antontveretin.000webhostapp.com/ngmtp/ngmtp_c9_cfdt.pdf is what you refer to I believe we are in different parts of the payment landscape. Saturn is exclusively dealing with the authorization of payments including acquiring the information needed to get the actual payment system (backend) to perform its task. These solutions are heavy into crypto and not particularly dense [1]. If you consider the four-corner model (Payee, Payee's Bank, Payer, Payer's Bank) all these entities must be be identified and secured in some way and that piece of the pudding is completely on fire these day, particularly with respect to the Payer and Payee. > And why does the data exchange bypass the (implied) payment system? As a payee, I need money and not "authorization". Right, but before that can happen authorization must happen in some way. This one-page "blueprint" illustrates the steps in my original posting: https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf > Of course, there is nothing wrong with JCS and its usage. Maybe I will incorporate it into the next version of the NGMTP-C9, or conversely. This year the EU PSD2 directive gets into power which is intended to open the payment market. Since the directive was written by lawyers will minimal knowledge of what is technically and commercially possible, it seems like an excellent opportunity putting new things to work including JCS. A bunch of IETFers are "retrofitting" OAuth for this market and purpose while I'm rather "upgrading" the card concept [2]. If you or anybody else want to discuss payment [authorization] systems, please contact me privately. thanx, Anders 1] Authentic sample of step #3 in the "blueprint". It features a JCS-enhanced version of JWE providing encryption metadata in clear. { "@context": "https://webpki.github.io/saturn/v3", "@qualifier": "PayerAuthorization", "providerAuthorityUrl": "https://mobilepki.org/webpay-payerbank/authority", "paymentMethod": "https://bankdirect.net", "encryptedAuthorization": { "algorithm": "A256GCM", "encryptedKey": { "algorithm": "ECDH-ES", "publicKey": { "kty": "EC", "crv": "P-256", "x": "TfCrhFwZRU_ea7lUWwRi3HkuyT2yF9IxN5xKh2khjlk", "y": "nZFwxLP0TvFXD2xPKzRTIGevgLjpiMw2BP86hszj5x4" }, "ephemeralKey": { "kty": "EC", "crv": "P-256", "x": "KZX-u1p40KGQpWreSdLRa8qUfa8jV6FNXe9AAhxE7MI", "y": "NOPuK5tgM8BPZB5xHAGzK7R609RnLHYA-le_3vrKdmE" } }, "iv": "5cU6d7DgjRKQy87h", "tag": "daSM2zkSuXvk5sD2_fB5TQ", "cipherText": "LHJabqaB0ZCHOmnxuWiEHNZDNCabMg4Zkw8X7Uy4xvFYmV80Z7NtNg9auiX8dzRGYxdtXmzQXJZeMMen5jmn6jcw6v0p9uaGoGkIxMT3Clwp2elnJYHgz0iJU5aKfxHm6ArF77Jn45YrAF0ur9MbD3a-sZL6OG5w91rS4xOVvjXkqhtuxBTygkHgXovhHWfMqiW2f6C0-nBbwWvdyZ7FCNM7acaPRlrUsvkkZe8KNviJpn7Rh8LXDR8TV-ycH05kET4pnGFvvM4qAs9qyqNyQa4ppz7V0dWFs8OSKbNqliPSaehIhcgKH4m1fD58IU2xMAmjTLAOAHpNRIwdeYic_P9Lx1FYrIEj-5snaqwyrXIxiOEHUPa_K0VzyE2LyP_lFecw0e3dzsivT59Oi6aE9RdNuKw09TtRqYE6ljYlxRTtfuZw8ySpfMxhN1syEA34r0U7utb9ToDhjaRsoSqF_DE1ExFFaFu0OMLOmlq947nc11zNRaPyuALRpe4Qb1niGE5Y-FQAluz0KMCP5CXBLC6zM0VfgodImH536PZifJ_aHvYsn-GEVyC9AamG_LkUgR4b8Zm3bLsTfcWUngNiirZgQErsrfK2VIT54VKkB9LOlC-uDtiaPstYRyL31IPCAp6uIgiDUYzGZNUltLIlSsUNJkzM9DNSiO9SpLoLBT94BHz66r4ebcIPfzeCC1Lt-7YyW9vTF5aBQqIZrD9eh6hhl2vs8rXqJqnEcNUv8X_Xce3t8H5H73XVpgYAiMQ98_imPozrSpIVp0R8TPBtIY93fy1BvEQXzIYKxx0HLv-JfmJ-KQLNggVd3LvuDrJE-t2PfPWDCwXDk-ukIPNaWQWwk5seMURfBVqZKmp3" } } 2] Web UI emulator: https://cyberphone.github.io/doc/saturn/ui-demo From nobody Mon May 20 04:01:45 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427D2120170 for ; Mon, 20 May 2019 04:01:43 -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, 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 wxGQ2esVrsjw for ; Mon, 20 May 2019 04:01:41 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 48C7712016F for ; Mon, 20 May 2019 04:01:41 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id g9so6557115plm.6 for ; Mon, 20 May 2019 04:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=kBzuPRNCiCzLxL6AnlUaUq5NCDyqPvXnlx3EkN1mLgI=; b=vTZpk92xacWJVc9iETQaBEmqOqn6+x1MzKRTJgCfEYMihNGcfOHeGIdqcm08Q0KFKJ 8PlVE6wt0VW0bTDiNKLpwUZHwFqSZNS4cVYCwZ4J0VtREfFGnYMqf2w31YBw0xIKHCYB y3qDjs0XIl3JRQX7dasGWGYQyOUoUDE5zPAQdCeqvu7+Dhfp0dfO6EUhyNmVYsXrwK3u Y5QVXEiXJnToYu/GxoY9SAYZVQ25mICiJ5Panvwk6jslVaSz5ymqz4gqsdEe4ncKKt48 pyjG5CknsVtwwXSGwtUi380y/K5zUhFmgy4aT+Giu2OIomPqFVvfEenVzaooMHwRxJWP 1A+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:from:date:message-id:subject:to; bh=kBzuPRNCiCzLxL6AnlUaUq5NCDyqPvXnlx3EkN1mLgI=; b=hbdox/J+Zyo1c5ijXZcFLMV8oXwsl5G2YlZVM8auyIYc9IzOjTY4dWZzSIAYUJOTnj G9SEUVx4eGqsxVEcgz+xMCxYuVFl0KxWEnDeTuhu6/O4YznIcUhSe63SBuXLmbej9Dhj p7uk6zin/ltrI8eiogSQJPZf8KgVIiqZm4eQVWrG+fi6hYB2ZK29yN3ktVXhISXwVjKq Y35JC6VB67LI89EA2Zt01bZZ5Xe5Fa6BNYhqbYDMCnpkEOS6Y7HjgC/DvPJrJF4/Qbgk MLyuErjGWtFUHWHRTk8Sm/e8qH6WRwvPLJWLWnvXl5AyLsHGIW3TGjm58gkyD7Y7EH1s n8Tw== X-Gm-Message-State: APjAAAVF9shdha1Op1tIN0M4t2VRl9sd8FE+saJN9mPpPLrP38BUKbRv Ixp77LWrJhzeULpjS3cxNApY+usFe6J1Tebfl8vqOkJ2weIdgQ== X-Google-Smtp-Source: APXvYqx8VgKUxBaW3pjz51B9B3qwqeHvET2UISOPf/pxvgQ2/6nZCtpY29QTVN/rJMM4SzG9C5ByntzNCx0+rd2urYU= X-Received: by 2002:a17:902:3383:: with SMTP id b3mr29417465plc.193.1558350100196; Mon, 20 May 2019 04:01:40 -0700 (PDT) MIME-Version: 1.0 From: Samuel Erdtman Date: Mon, 20 May 2019 13:01:28 +0200 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000002881e405894fa8b9" Archived-At: Subject: Re: [dispatch] JSON Canonicalization Scheme (JCS) Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 11:01:43 -0000 --0000000000002881e405894fa8b9 Content-Type: text/plain; charset="UTF-8" I support this work I think the use cases that has been mentioned before (documentation, logging, debug, embedding, countersigningetc.) are valuable but would like to add another to the list. My use case if about interaction with legacy systems. In a distributed environment where systems can publish and subscribe to messages it is hard or even impossible to do significant changes to the format (XML, JOSN, base64url) of messages because it will break existing clients subscribing to the messages. With the solution of cleartext JSON signing adding end-to-end security by signing the JSON would be very non intrusive (adding a new attribute) and existing clients could continue to read the JSON values that they know of while new and updated clients can also verify the signature of a message when needed. You could partly solve this with a translation layer but it would be hard/impossible to get ensure end-to-end security of messages. I hope this adds to the support of this work Best regards //Samuel --0000000000002881e405894fa8b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support this work I think the use c= ases that has been mentioned before (documentation, logging, debug, embeddi= ng, countersigningetc.) are valuable but would like to add another to the l= ist.

My use case if about interaction with legacy systems. In a dist= ributed environment where systems can publish and subscribe to messages it = is hard or even impossible to do significant changes to the format (XML, JO= SN, base64url) of messages because it will break existing clients subscribi= ng to the messages. With the solution of cleartext JSON signing adding end-= to-end security by signing the JSON would be very non intrusive (adding a n= ew attribute) and existing clients could continue to read the JSON values t= hat they know of while new and updated clients can also verify the signatur= e of a message when needed.

You could partly solve this with a trans= lation layer but it would be hard/impossible to get ensure end-to-end secur= ity of messages.

I hope this adds to the support of this work

Best regards
//Samuel



--0000000000002881e405894fa8b9--