From nobody Wed Apr 17 06:02:01 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 801B612034A for ; Wed, 17 Apr 2019 06:02:00 -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, 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=g001.emailsrvr.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 6aFAMKRRoiBJ for ; Wed, 17 Apr 2019 06:01:57 -0700 (PDT) Received: from smtp80.iad3a.emailsrvr.com (smtp80.iad3a.emailsrvr.com [173.203.187.80]) (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 97C11120345 for ; Wed, 17 Apr 2019 06:01:57 -0700 (PDT) Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 94E8759FB; Wed, 17 Apr 2019 09:01:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1555506116; bh=C97lRf207U3eOD3uATpbX3cyZgOXBN4yXyDwfGw3hZI=; h=Subject:From:Date:To:From; b=TlboLRnvKsLvbH4jzqo2m2eQV0c7yMnQY7OT7BocqRZGg9gOuL7N3PPhOsmF+EpVB xdIzEX1osxLPQO0gh3Ay68phIKyWByqvniv+zNDxeGgPxpZE1x0cUgZ2hWK03jiuxB +IVy5pTxb+KHygM/8kyV3aQtkky4u11LIUdvlyw4= X-Auth-ID: fluffy@iii.ca Received: by smtp35.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id EB5E65741; Wed, 17 Apr 2019 09:01:55 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 17 Apr 2019 09:01:56 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4A73FE31-6FC3-498A-811F-D63073EA6153" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Cullen Jennings In-Reply-To: Date: Wed, 17 Apr 2019 07:01:54 -0600 Cc: DISPATCH Message-Id: References: <3c9085a4-3348-489b-8a42-545f686c017a@www.fastmail.com> <892FDB9A-DC09-44BB-A540-61727F581C71@iii.ca> To: Mary Barnes X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [dispatch] DISPATCH agenda @ IETF-104 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: Wed, 17 Apr 2019 13:02:01 -0000 --Apple-Mail=_4A73FE31-6FC3-498A-811F-D63073EA6153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My view is the mailing list archives tend to survive pretty well as an = archive and other things less so. So if when an agenda gets done in Wiki = it also gets cut and pasted to an email to the list, that=E2=80=99s = great. I will point out the email also works way better for people in = low bandwidth universities in Africa.=20 On the topic of drafts older than 6 months - absolutely they are = critical for prior art but clearly they easy to find on internet. I have = no idea what IETF even means by they expire in 6 months. I can not think = of *any* way in which you say they expire - people read them, quote = them, implement them etc long after 6 months.=20 > On Mar 21, 2019, at 9:18 AM, Mary Barnes = wrote: >=20 > So, where do you propose we store all this information for archival? >=20 > This really comes down to an earlier discussion on one of the other = general lists that a lot of history is lost. That wiki is the history = of what happened to all the work items since we started DISPATCH. Yes, = we have minutes, etc. but that doesn't give you the complete picture as = a lot of things happen actually NOT on public lists - e.g., the AD = sponsored documents go off and discussions are between AD and authors, = when WGs are chartered, there's a lot of out of band discussion, etc. = Do you propose that all those discussions happen on the mailing list for = archival?=20 >=20 > Can we add a page to the datatracker for each WG so that we can store = information like this? The only other thing I can think of is that we = just post it periodically on the mailing list if you want guaranteed = archival. =20 >=20 > Regards, > Mary. >=20 > On Thu, Mar 21, 2019 at 10:00 AM Cullen Jennings > wrote: >=20 > I=E2=80=99m reading this on a plane and don=E2=80=99t have access to = the WIKI, and 10 years from now when I am trying to find prior are for a = patent trial, all the content of the Wiki will not be archived.=20 >=20 >=20 > > On Mar 19, 2019, at 4:35 PM, Martin Thomson > wrote: > >=20 > > I agree with Martin. I don't know how to find these documents. Where = is the wiki? > >=20 > > The URL is the answer. > >=20 > > On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote: > >> Hello everybody, > >>=20 > >> On 2019/03/14 02:13, Mary Barnes wrote: > >>> Hi all, > >>>=20 > >>> We have uploaded a preliminary agenda for DISPATCH: > >>=20 > >> Thanks for putting this together. > >>=20 > >>> https://datatracker.ietf.org/meeting/materials/ = > >>=20 > >> This may be just an oversight, but in general, I very much prefer = to=20 > >> have the agenda (and other, similarly short stuff) inline in my = inbox.=20 > >> That saves me (and everybody else) a click (or two, plus some = on-page=20 > >> search time, this time). Of course it can change later, but we all = know=20 > >> that. > >>=20 > >> The actual agenda is at > >> = https://datatracker.ietf.org/meeting/104/materials/agenda-104-dispatch-00 = .=20 > >> In the future, precise links would be appreciated. > >>=20 > >> The agenda currently reads as follows: > >>=20 > >> # Draft Agenda Dispatch @IETF-104 - v1 > >>=20 > >> DISPATCH Meeting > >> ------------------- > >>=20 > >> # Status and agenda bash - Chairs (10 min) > >>=20 > >> # Relay User Machine (RUM) - Brian Rosen (20 min) > >>=20 > >> # JSON Contact - Bron Gondwana (20 min) > >>=20 > >> # Web Packaging - Jeffrey Yasskin (20 min) > >>=20 > >> Note: see DISPATCH wiki for additional links to materials > >>=20 > >>=20 > >> ART AREA Meeting > >> ------------------- > >>=20 > >> # Bofs and meetings of interest - ADs (5 min) > >>=20 > >> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20) > >> Document: draft-rundgren-json-canonicalization-scheme > >>=20 > >> # AOB > >>=20 > >>=20 > >>> Regards, > >>> Mary. > >>> DISPATCH WG co-chair > >>>=20 > >>> ---------- Forwarded message --------- > >>> From: Mary Barnes > > >>> Date: Thu, Mar 7, 2019 at 9:59 AM > >>> Subject: Topics for DISPATCH @ IETF-104 > >>> To: DISPATCH > > >>> Cc: ART ADs >, dispatch = chairs > > >>>=20 > >>>=20 > >>> Hi all, > >>>=20 > >>> The wiki has been updated with the topics that have been agreed to = be > >>> discussed at IETF-104: = https://trac.ietf.org/trac/dispatch/wiki/WikiStart = > >>>=20 > >>> The proposal for moving forward draft-dold-payto is still being = discussed > >>> amongst ADS/chairs as is the JSON Canonicalization that had been = proposed > >>> as a BoF in the SEC Area, but was not approved. > >>>=20 > >>> We will post any updates to the wiki and will post an agenda = shortly. > >>>=20 > >>> As a reminder, if you are submitting drafts for discussion in the = dispatch > >>> working group following the standard convention of including the = WG name in > >>> the draft name (i.e., draft--dispatch-blah-blah) makes it = *much* > >>> easier for me as chair to make sure I have the right documents = identified > >>> on the wiki and on the agenda. The tool will allow you to = indicate that > >>> the document with the new name replaces the document with the old = name if > >>> that's a concern. > >>>=20 > >>> Regards, > >>> Mary > >>> DISPATCH WG co-chair > >>>=20 > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch = > >>=20 > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch = >=20 > _______________________________________________ > 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 --Apple-Mail=_4A73FE31-6FC3-498A-811F-D63073EA6153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

My view is the mailing list archives = tend to survive pretty well as an archive and other things less so. So = if when an agenda gets done in Wiki it also gets cut and pasted to an = email to the list, that=E2=80=99s great. I will point out the email also = works way better for people in low bandwidth universities in = Africa. 

On the = topic of drafts older than 6 months - absolutely they are critical for = prior art but clearly they easy to find on internet. I have no idea what = IETF even means by they expire in 6 months. I can not think of *any* way = in which you say they expire - people read them, quote them, implement = them etc long after 6 months. 


On Mar 21, 2019, at 9:18 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

So, where do you propose we store all this information for = archival?

This = really comes down to an earlier discussion on one of the other general = lists that a lot of history is lost.  That wiki is the history of = what happened to all the work items since we started DISPATCH.  = Yes, we have minutes, etc. but that doesn't give you the complete = picture as a lot of things happen actually NOT on public lists - e.g., = the AD sponsored documents go off and discussions are between AD and = authors, when WGs are chartered, there's a lot of out of band = discussion, etc.   Do you propose that all those discussions = happen on the mailing list for archival? 

Can we add a page to the datatracker = for each WG so that we can store information like this?   The = only other thing I can think of is that we just post it periodically on = the mailing list if you want guaranteed archival.  

Regards,
Mary.

On Thu, Mar 21, 2019 at 10:00 AM = Cullen Jennings <fluffy@iii.ca> wrote:

I=E2=80=99m reading this on a plane and don=E2=80=99t have access to the = WIKI, and 10 years from now when I am trying to find prior are for a = patent trial, all the content of the Wiki will not be archived.


> On Mar 19, 2019, at 4:35 PM, Martin Thomson <mt@lowentropy.net> wrote:
>
> I agree with Martin. I don't know how to find these documents. = Where is the wiki?
>
> The URL is the answer.
>
> On Thu, Mar 14, 2019, at 16:16, Martin J. D=C3=BCrst wrote:
>> Hello everybody,
>>
>> On 2019/03/14 02:13, Mary Barnes wrote:
>>> Hi all,
>>>
>>> We have uploaded a preliminary agenda for DISPATCH:
>>
>> Thanks for putting this together.
>>
>>> https://datatracker.ietf.org/meeting/materials/
>>
>> This may be just an oversight, but in general, I very much = prefer to
>> have the agenda (and other, similarly short stuff) inline in my = inbox.
>> That saves me (and everybody else) a click (or two, plus some = on-page
>> search time, this time). Of course it can change later, but we = all know
>> that.
>>
>> The actual agenda is at
>> https://datatracker.ietf.org/meeting/104/materials/agenda-104-d= ispatch-00.
>> In the future, precise links would be appreciated.
= >>
>> The agenda currently reads as follows:
>>
>> # Draft Agenda Dispatch @IETF-104 - v1
>>
>> DISPATCH Meeting
>> -------------------
>>
>> # Status and agenda bash - Chairs (10 min)
>>
>> # Relay User Machine (RUM) - Brian Rosen (20 min)
>>
>> # JSON Contact - Bron Gondwana (20 min)
>>
>> # Web Packaging - Jeffrey Yasskin (20 min)
>>
>> Note: see DISPATCH wiki for additional links to materials
>>
>>
>> ART AREA Meeting
>> -------------------
>>
>> # Bofs and meetings of interest - ADs (5 min)
>>
>> # JSON Canonicalization Scheme (JCS) - Anders Rundgren (20)
>>   Document: = draft-rundgren-json-canonicalization-scheme
>>
>> # AOB
>>
>>
>>> Regards,
>>> Mary.
>>> DISPATCH WG co-chair
>>>
>>> ---------- Forwarded message ---------
>>> From: Mary Barnes <mary.ietf.barnes@gmail.com>
>>> Date: Thu, Mar 7, 2019 at 9:59 AM
>>> Subject: Topics for DISPATCH @ IETF-104
>>> To: DISPATCH <dispatch@ietf.org>
>>> Cc: ART ADs <art-ads@ietf.org>, dispatch chairs = <dispatch-chairs@ietf.org>
>>>
>>>
>>> Hi all,
>>>
>>> The wiki has been updated with the topics that have been = agreed to be
>>> discussed at IETF-104:  https://trac.ietf.org/trac/dispatch/wiki/WikiStart
>>>
>>> The proposal for moving forward draft-dold-payto is still = being discussed
>>> amongst ADS/chairs as is the JSON Canonicalization that had = been proposed
>>> as a BoF in the SEC Area, but was not approved.
>>>
>>> We will post any updates to the wiki and will post an = agenda shortly.
>>>
>>> As a reminder, if you are submitting drafts for discussion = in the dispatch
>>> working group following the standard convention of = including the WG name in
>>> the draft name (i.e., = draft-<name>-dispatch-blah-blah)  makes it *much*
>>> easier for me as chair to make sure I have the right = documents identified
>>> on the wiki and on the agenda.   The tool will = allow you to indicate that
>>> the document with the new name replaces the document with = the old name if
>>> that's a concern.
>>>
>>> Regards,
>>> Mary
>>> DISPATCH WG co-chair
>>>
>> _______________________________________________
>> 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
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_4A73FE31-6FC3-498A-811F-D63073EA6153-- From nobody Wed Apr 24 05:24:27 2019 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBA112021F; Wed, 24 Apr 2019 05:24:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, mary.ietf.barnes@gmail.com, dispatch@ietf.org, dispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155610866546.32055.15425904953144771060.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2019 05:24:25 -0700 Archived-At: Subject: [dispatch] dispatch - New Meeting Session Request for IETF 105 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 12:24:26 -0000 A new meeting session request has just been submitted by Mary Barnes, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: secdispatch cfrg extra doh core clue bfcpbis avtcore ecrit mmusic netvc payload rmcat rtcweb sipcore stir xrblock dmarc uta jmap Second Priority: tram tsvwg tsvarea opsarea People who must be present: Barry Leiba Alexey Melnikov Mary Barnes Adam Roach Ben Campbell Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Mon Apr 29 11:44: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 9BE87120129 for ; Mon, 29 Apr 2019 11:44: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 b3b81AgUNL9w for ; Mon, 29 Apr 2019 11:44:14 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 7FD9D1200D5 for ; Mon, 29 Apr 2019 11:44:14 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id t200so651843itf.4 for ; Mon, 29 Apr 2019 11:44:14 -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=9EqQaob0OIrrq6YZI81vbfp1B+Mt1EG5Ut/AxIP4WZ0=; b=EqU1EaZYB1WgsEipyRzXiKRqQzEHwfda7e4nzckKZxTKT2HGKdp6fbuI/95rwbJmMS i234xmsVrxJaLPLH9FwKkzi7SCzQ1AznuqGtyO1wuluDOLnG0VfGGHMxHcUf4Xxx5GeR FyOkHxRh1R6BXFk3EcBP7SmfwHcWxwg+tuvW17MWDcDuZ8GuDdfoHx1TZew8oZa9oNp8 qNUIB1RHIiHi4mIrqZmj6dBPe6wpkjlMYIEyUAkXDXNmpjBnXE6isZpSkXazdeZ4TFit Y/goKd+axNm5nOd5Bin1o8FKXMCwUGCQG+bzPufW+2ltsEm+V9Lxyt6A0bmjwBmnvb7w bHwQ== 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=9EqQaob0OIrrq6YZI81vbfp1B+Mt1EG5Ut/AxIP4WZ0=; b=cAs9WbwQ1/H1UzUP7xrz/URxgQhnc92eb9rBynua/p304DU0voVTu2O/zqZ1O9edYB VcOIdyXqAPJJDrQF1adWVdfj6jXWu9ksfl6LeaDXxIuJP/ItjcmYF/JhN7lBKgO1rQL7 PHqFgVE+TPVYtsi5xpM0nnr6l4b4plLd9YKbPB2NQ5JsLOHkD0A57KRqIIuCP2q5ZYyp 9xP618wePkrtJTo6Xsxxe8Iyj0tXup2UOguJrpdoGhRkjMib+6xEgdfIyAry7f6Q8zYr rEt/Y46DqongbHI6xjbcF9bWosePzDJt8QVLcLGO7bEnr/EAnl/Twkoz6zVdwQbW9vV/ s/jw== X-Gm-Message-State: APjAAAXOzy+cFzMsmCYrVBRqBzicu5N+nnoN36DhKDtv+Jdci0mPAfYh ZkMLbUoQRNSHskSYoIVF4lI9aIUF X-Google-Smtp-Source: APXvYqzWBiQ43D76hWqFoWPLOaF41+PrPCig8fWNKDzLU9kOYi7MnHDRtinUM3hpThpz2PEomOM4kw== X-Received: by 2002:a24:1986:: with SMTP id b128mr370115itb.41.1556563453357; Mon, 29 Apr 2019 11:44:13 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:610f:9db3:cdfc:74b3? ([2605:a601:a990:4d00:610f:9db3:cdfc:74b3]) by smtp.gmail.com with ESMTPSA id n199sm13757339iod.54.2019.04.29.11.44.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 11:44:12 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_D65F8294-4755-4D9D-B1DD-ADB55056FDAC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> Date: Mon, 29 Apr 2019 12:44:09 -0600 To: dispatch@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [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, 29 Apr 2019 18:44:17 -0000 --Apple-Mail=_D65F8294-4755-4D9D-B1DD-ADB55056FDAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. =20 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.=20 Personally I know many organizations and solutions that desperately need = this for production. Thank you for your consideration.=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=_D65F8294-4755-4D9D-B1DD-ADB55056FDAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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-canonicalizatio= n-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."

= --Apple-Mail=_D65F8294-4755-4D9D-B1DD-ADB55056FDAC-- From nobody Mon Apr 29 12:17:20 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 E715D1206B2 for ; Mon, 29 Apr 2019 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqo3HnTYKzbl for ; Mon, 29 Apr 2019 12:17:16 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 05E251206B3 for ; Mon, 29 Apr 2019 12:17:16 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id m137so6672627qke.3 for ; Mon, 29 Apr 2019 12:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ce3UBUbDLG09UROugn2stcMEch0FB9qc+b5rFPif7JE=; b=txZytIsiQKWvCN2DOuQduLh6D4Ya/l+TURlgAJK6aY0ogAYYESVBPMSYVNt9GR3FkS 0IcB3BiA+qd/az0GAC6UHDnPiPtopYm/PR+lfECMitCZBJD/iqO8JoQs2ysp8eNZmdcO 5bE1OirTlfyCbnD8AolbFNCJeUc8VicIVS+vXMDjeF4gyNnhKJxjfHrnmC4JxhqOmmrB bU3JbDdvT3wyPauhQaUiiWs5S6NMGKqiuNcEWS9iBURg8c4nGuvBtKSyHt/vIunBBLzp xsPeSBI+wVoaDMvOzL9AT9R0BwoJPrzqZetIFIGIX4t8wII6c9FFQKNih8ywbPrdHyPl xnCA== 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=Ce3UBUbDLG09UROugn2stcMEch0FB9qc+b5rFPif7JE=; b=kheK3YErYIrFB+PVuZXyz3LNS3qrBUfZjjtrvm9NZoT3cDh92k8gYlXa86Jv5IKmNF sSYXPbfn4BSLqxXli4blSUY6QqYtyTf/FGRPB4x+MDYAl/763EWI/89Uxzuq1w7otzLl LD1k7roimUU+pzg+lWiNenSbP+gdEykmx/Hu65uC4gZZVqSGx9v9Khq/48eM3/6RN3sn n6HVFNUP7wSb6DpyQf3fmzctVeogYc02AJKZHK+HCPfllI4G/s1lNMZmqbZXWhctiAvZ fbXh4AU7P1IN8oUB5vAzyOnuSNzm+9azpYZBR6BwNFsCU0/znk5wq77PQusrvPib5GS5 aXtg== X-Gm-Message-State: APjAAAXpXIsB5/CVEvxZMVuTe/8DIkEryzDqMGBkj63rbpwgPFcKw9B8 6WebTaRBfrdXqf0PYLiZ3gPclA== X-Google-Smtp-Source: APXvYqx2DGvgOb0SZf1rrsGe+yb4X1OpZcZu/byuunnrkBJEQR6uWrxIEIsofA5MpJF3CH2CUy/tlA== X-Received: by 2002:a37:c245:: with SMTP id j5mr39855325qkm.70.1556565434934; Mon, 29 Apr 2019 12:17:14 -0700 (PDT) Received: from brians-mbp-6.lan ([24.129.255.66]) by smtp.gmail.com with ESMTPSA id g185sm14693860qkc.48.2019.04.29.12.17.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 12:17:14 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A4547121-2852-4A4B-AF34-55CCBD19D519" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 29 Apr 2019 15:17:13 -0400 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: Mon, 29 Apr 2019 19:17:19 -0000 --Apple-Mail=_A4547121-2852-4A4B-AF34-55CCBD19D519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I like this work and would like it to move forward. A use case I have = is the recording system for emergency calls. Everything is recorded and = the recorded data is used real time as history of an incident, rather = than retaining it both in some temporary system and in the main = recording system. That means that the recording system is frequently = consulted real time as the incident progresses. Signatures are used = throughout, primarily for non-repudiation. You only validate the = signature months after the event, when lawyers want to make sure = transcripts are accurate. Having to do more work to get the data is not = desirable.=20 I will review, comment and participate actively in this effort. Brian > On Apr 29, 2019, at 2: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 >=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 >=20 > Personally I know many organizations and solutions that desperately = need this for production. Thank you for your consideration.=20 >=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=_A4547121-2852-4A4B-AF34-55CCBD19D519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = like this work and would like it to move forward.  A use case I = have is the recording system for emergency calls.  Everything is = recorded and the recorded data is used real time as history of an = incident, rather than retaining it both in some temporary system and in = the main recording system.  That means that the recording system is = frequently consulted real time as the incident progresses. =  Signatures are used throughout, primarily for non-repudiation. =  You only validate the signature months after the event, when = lawyers want to make sure transcripts are accurate.  Having to do = more work to get the data is not desirable. 

I will review, comment and participate = actively in this effort.

Brian


On Apr = 29, 2019, at 2: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.  

The current draft can be found = here: https://tools.ietf.org/html/draft-rundgren-json-canonicalizatio= n-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

= --Apple-Mail=_A4547121-2852-4A4B-AF34-55CCBD19D519-- From nobody Mon Apr 29 23:39:18 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 74AF1120171 for ; Mon, 29 Apr 2019 23:39:17 -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 ypXo7jQAZcTX for ; Mon, 29 Apr 2019 23:39:15 -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 043DB120098 for ; Mon, 29 Apr 2019 23:39:14 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id c5so19551106wrs.11 for ; Mon, 29 Apr 2019 23:39:14 -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; bh=wvAZlLsdfzewNCjkafRzY9dE8nAyjVKfTntL2FhJ+HI=; b=pQU75udzC0ODo2OOaVEKop0PYOGDjeJNNzcGde06Rd4egjUd+P9bXqVvqzVSEsO4Pq 2UNfin+sq4DuEXfPIPPqBmMMSm9nE3PTfpHFhJOwM/1mHpe828CGJWjDS0KytJDVWZGS 4eunOdz9RkbzWCbWA2drUhv8SzGo5Fiu9meaUS0JeOTpwfxjdlEiGTxrQDrneR+Ql+zF V22PpS0VxDqP6x5us84zNRjgbNWCs3wAciW7oYU2q1JNaGq+q7CIs54oAl4Gr7ihi0RO KvuaNCcbsvE4HmgX0KZITloeeUocSECXwKIAn+r+QnbJSK3Ke6UVQ5NHsGOOHQzJl+H3 2f/A== 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; bh=wvAZlLsdfzewNCjkafRzY9dE8nAyjVKfTntL2FhJ+HI=; b=hb83xiBVaYEULzEcZSE57AicgmOED6AP2m9Ei3g94/oe/sO5xm74RVk9gDsX6pYjUp GGExnHUEE0CRKPINXOcXjf19dZ9/d5L9WTJ9qckOBgKAV9nx0e2RZgMRJAQzwsQDuJre o+JtPnqlO5QtIqWLEgZtanxPMHhQvJOrRYKBs/YFuwiQxYqsew4YG6sxj9pckZS+CJun ElbxWrNcb3NOawKoXkaycCUdLkv/1PHKsX80kiuKj8ZY93NeKUSoy/tsMFiIoiCmyzNP 6YN8eN0XKFnrLNqeesJzXyTYINljoB+LEaGtr/P11cX4bqa//CPTqgjcnxPtZv4d+WKQ TQpQ== X-Gm-Message-State: APjAAAVBAp2KKSWTIzGv+IBtDNBRf5zY0QbSgAP/uYl2njkaLSrFFaB4 DeVpesmZYoOxHm69dSjhSWg= X-Google-Smtp-Source: APXvYqxtKJIgX+CHh2cZrPpipxoNlBvZDfDLXpcmTrx8w5wd4i9HGTbWWS7aawPOq7oFhzDHEI52zA== X-Received: by 2002:adf:c6c3:: with SMTP id c3mr1785410wrh.267.1556606353451; Mon, 29 Apr 2019 23:39:13 -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 s124sm1431175wmf.42.2019.04.29.23.39.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 23:39:12 -0700 (PDT) To: Brian Rosen , Bret Jordan Cc: dispatch@ietf.org References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> From: Anders Rundgren Message-ID: <6abdad31-5914-3fea-cb5b-a9400d2fccff@gmail.com> Date: Tue, 30 Apr 2019 08:39:09 +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: multipart/alternative; boundary="------------079594233528F3B6B4AB7685" Content-Language: en-US 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, 30 Apr 2019 06:39:17 -0000 This is a multi-part message in MIME format. --------------079594233528F3B6B4AB7685 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanx Bret and Brian, The core motive behind this scheme can in short be described as "keeping JSON as JSON, also when signed". It turns out that even hard-core security folks like the TEEP WG (who use the current and rather intrusive JWS/Base64Url scheme), in order to maintain a reasonable message structure were forced putting every message in unsigned outer JSON "holder" objects which does not only look weird but also creates additional issues: https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02      "The top element "[Signed][Request|Response]" cannot be fully        trusted to match the content because it doesn't participate in the        signature generation.  However, a recipient can always match it with        the value associated with the property "payload".  It purely serves        to provide a quick reference for reading and method invocation" Using JCS with JWS the need for artificial holder objects and associated matching requirements disappear, while message content is provided in clear. Although not a part of this particular effort, you can also apply JCS to the signature container itself making algorithms, public key values, etc. fully readable.  An example of such a solution can be found at: https://mobilepki.org/webpay-payeebank/payees/86344 thanx, Anders On 2019-04-29 21:17, Brian Rosen wrote: > I like this work and would like it to move forward.  A use case I have is the recording system for emergency calls.  Everything is recorded and the recorded data is used real time as history of an incident, rather than retaining it both in some temporary system and in the main recording system.  That means that the recording system is frequently consulted real time as the incident progresses.  Signatures are used throughout, primarily for non-repudiation.  You only validate the signature months after the event, when lawyers want to make sure transcripts are accurate.  Having to do more work to get the data is not desirable. > > I will review, comment and participate actively in this effort. > > Brian > > >> On Apr 29, 2019, at 2: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 --------------079594233528F3B6B4AB7685 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanx Bret and Brian,

The core motive behind this scheme can in short be described as "keeping JSON as JSON, also when signed".

It turns out that even hard-core security folks like the TEEP WG (who use the current and rather intrusive JWS/Base64Url scheme), in order to maintain a reasonable message structure were forced putting every message in unsigned outer JSON "holder" objects which does not only look weird but also creates additional issues:

https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02

     "The top element "<name>[Signed][Request|Response]" cannot be fully
       trusted to match the content because it doesn't participate in the
       signature generation.  However, a recipient can always match it with
       the value associated with the property "payload".  It purely serves
       to provide a quick reference for reading and method invocation"

Using JCS with JWS the need for artificial holder objects and associated matching requirements disappear, while message content is provided in clear.

Although not a part of this particular effort, you can also apply JCS to the signature container itself making algorithms, public key values, etc. fully readable.  An example of such a solution can be found at: https://mobilepki.org/webpay-payeebank/payees/86344

thanx,
Anders


On 2019-04-29 21:17, Brian Rosen wrote:
I like this work and would like it to move forward.  A use case I have is the recording system for emergency calls.  Everything is recorded and the recorded data is used real time as history of an incident, rather than retaining it both in some temporary system and in the main recording system.  That means that the recording system is frequently consulted real time as the incident progresses.  Signatures are used throughout, primarily for non-repudiation.  You only validate the signature months after the event, when lawyers want to make sure transcripts are accurate.  Having to do more work to get the data is not desirable. 

I will review, comment and participate actively in this effort.

Brian


On Apr 29, 2019, at 2: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


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

--------------079594233528F3B6B4AB7685-- From nobody Tue Apr 30 07:42:57 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 78A8512011A for ; Tue, 30 Apr 2019 07:42:55 -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 jRDMvCcXgEAK for ; Tue, 30 Apr 2019 07:42:52 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 602A8120114 for ; Tue, 30 Apr 2019 07:42:52 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id h26so12447594ioj.1 for ; Tue, 30 Apr 2019 07:42:52 -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=51TI/ZkLTbi91Catuvbu2o/o+i5RuwurofAZMSf0vqY=; b=X07PJCIltpNgrwrYL3zKnEgQlU5nGfVaUUYxxsXYqM8QP867fg/7+ec8svjpoQPfC3 UJeDUEkNE7kWaf1zburCmJHDIuRwzf93ccMmSKgw97twdABkF7/lBWW+6N7X4XaAH4o9 K5HZYyurlC3fengHl4OHYohp8mS03pYnPhmzvVX2xZYYLTldV35mYmjBoSWAQbdmV3QT 2WLh83nJ61gEL+FWDkRgvQZhejxYUJqQTMbhqMwab4hj+NCZJ+AE0u6lliqF5ZpHm0UY 5Ym8SbzUcRM9H8kZgtf+vXtC4mzO1zRsHyKU8a+Mam39HFdNYIY5paVayv5pONgeWIS1 XQ8Q== 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=51TI/ZkLTbi91Catuvbu2o/o+i5RuwurofAZMSf0vqY=; b=tF6Q+qsbgqf/c8FAzJstTjyZniW0JjE43vsJONb8DlGvsGqQyxXPt5tPoyYQ1B00gP iiYwdPZhlQMSxN73pCxwdjXBCB7qmFzgXto0ECMPdqviov9gru1Tq3MsMRArmUkKSy28 /Onvp7hKq6pDsTdboUGL0huLu1YYpUFphqC0xd3Mn5lBQzJw2eKiT6LDv67c4w4nKX5C aD2cGDd+5O9egq5blBnU4lFxFGpJlT1m6nxGdOci2e7tYgjRufn+OCp3Rksu9ltvDslx kn76N0+49slSaPpxmmHy47lQRVE3fovMwPxAPtRGQEgZJCOFptzF2KDxNUV2a7Uv/A1a ctBA== X-Gm-Message-State: APjAAAVeh0UbSlwpnsPATGHh3KYmBc81oppWZ2Tspo+MeIvKhxdjwQps FJ5lYUgSxKv0KsUM7QautVk= X-Google-Smtp-Source: APXvYqxhfK2KeifFsiYXjjSog8QQvsGhTMclmXUPDC7iAQG/undYB+xw6uhaVy2iYBghE/M01qcZsA== X-Received: by 2002:a5d:898a:: with SMTP id m10mr43221177iol.296.1556635369513; Tue, 30 Apr 2019 07:42:49 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:68cf:8cf2:5c20:c8a8? ([2605:a601:a990:4d00:68cf:8cf2:5c20:c8a8]) by smtp.gmail.com with ESMTPSA id n4sm12962695ioh.52.2019.04.30.07.42.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 07:42:48 -0700 (PDT) From: Bret Jordan Message-Id: <584CCA10-3337-4015-84A6-BB8A8FD1BE30@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1266082-5883-440E-B23C-66B94493496E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 30 Apr 2019 08:42:45 -0600 In-Reply-To: <6abdad31-5914-3fea-cb5b-a9400d2fccff@gmail.com> Cc: Brian Rosen , dispatch@ietf.org To: Anders Rundgren References: <6445089C-CC1A-4405-85CB-A7561D9B25BA@gmail.com> <6abdad31-5914-3fea-cb5b-a9400d2fccff@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, 30 Apr 2019 14:42:56 -0000 --Apple-Mail=_A1266082-5883-440E-B23C-66B94493496E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes Anders. There is a lot of need to keep the jSON as JSON and still = have signatures and even have nested signatures. The data needs to stay = as JSON so that it can be actioned on and addressed in a graph. I am = really excited about this work moving forward.=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 Apr 30, 2019, at 12:39 AM, Anders Rundgren = wrote: >=20 > Thanx Bret and Brian, >=20 > The core motive behind this scheme can in short be described as = "keeping JSON as JSON, also when signed". >=20 > It turns out that even hard-core security folks like the TEEP WG (who = use the current and rather intrusive JWS/Base64Url scheme), in order to = maintain a reasonable message structure were forced putting every = message in unsigned outer JSON "holder" objects which does not only look = weird but also creates additional issues: >=20 > https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02 = >=20 > "The top element "[Signed][Request|Response]" cannot be = fully > trusted to match the content because it doesn't participate in = the > signature generation. However, a recipient can always match it = with > the value associated with the property "payload". It purely = serves > to provide a quick reference for reading and method invocation" >=20 > Using JCS with JWS the need for artificial holder objects and = associated matching requirements disappear, while message content is = provided in clear. >=20 > Although not a part of this particular effort, you can also apply JCS = to the signature container itself making algorithms, public key values, = etc. fully readable. An example of such a solution can be found at: = https://mobilepki.org/webpay-payeebank/payees/86344 = >=20 > thanx, > Anders >=20 >=20 > On 2019-04-29 21:17, Brian Rosen wrote: >> I like this work and would like it to move forward. A use case I = have is the recording system for emergency calls. Everything is = recorded and the recorded data is used real time as history of an = incident, rather than retaining it both in some temporary system and in = the main recording system. That means that the recording system is = frequently consulted real time as the incident progresses. Signatures = are used throughout, primarily for non-repudiation. You only validate = the signature months after the event, when lawyers want to make sure = transcripts are accurate. Having to do more work to get the data is not = desirable.=20 >>=20 >> I will review, comment and participate actively in this effort. >>=20 >> Brian >>=20 >>=20 >>> On Apr 29, 2019, at 2: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 >>>=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 >>>=20 >>> Personally I know many organizations and solutions that desperately = need this for production. Thank you for your consideration.=20 >>>=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 = >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >=20 --Apple-Mail=_A1266082-5883-440E-B23C-66B94493496E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes = Anders.  There is a lot of need to keep the jSON as JSON and still = have signatures and even have nested signatures.  The data needs to = stay as JSON so that it can be actioned on and addressed in a graph. =  I am really excited about this work moving forward. 


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 Apr 30, 2019, at 12:39 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

=20 =20
Thanx Bret and Brian,

The core motive behind this scheme can in short be described as "keeping JSON as JSON, also when signed".

It turns out that even hard-core security folks like the TEEP WG (who use the current and rather intrusive JWS/Base64Url scheme), in order to maintain a reasonable message structure were forced putting every message in unsigned outer JSON "holder" objects which does not only look weird but also creates additional = issues:

= https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-02

     "The top element = "<name>[Signed][Request|Response]" cannot be fully
       trusted to match the content because it = doesn't participate in the
       signature generation.  However, a = recipient can always match it with
       the value associated with the property = "payload".  It purely serves
       to provide a quick reference for = reading and method invocation"

Using JCS with JWS the need for artificial holder objects and associated matching requirements disappear, while message content is provided in clear.

Although not a part of this particular effort, you can also apply JCS to the signature container itself making algorithms, public key values, etc. fully readable.  An example of such a = solution can be found at: https://mobil= epki.org/webpay-payeebank/payees/86344

thanx,
Anders


On 2019-04-29 21:17, Brian Rosen wrote:
I like this work and would like it to move forward.  A use = case I have is the recording system for emergency calls.  Everything = is recorded and the recorded data is used real time as history of an incident, rather than retaining it both in some temporary system and in the main recording system.  That means that the = recording system is frequently consulted real time as the incident progresses.  Signatures are used throughout, primarily for non-repudiation.  You only validate the signature months = after the event, when lawyers want to make sure transcripts are accurate.  Having to do more work to get the data is not = desirable. 

I will review, comment and participate actively in this effort.

Brian


On Apr 29, 2019, at 2: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. =  

The current draft can be found = here: https://tools.ietf.org/html/draft-rundgren-json-c= anonicalization-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.o= rg/mailman/listinfo/dispatch


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


= --Apple-Mail=_A1266082-5883-440E-B23C-66B94493496E--