Subject: [dispatch] Reminder: IETF-104 deadlines

From: Mary Barnes <[email-masked]>
Date: Mon, 11 Feb 2019 11:44:29 -0600

Hi all,

Just a reminder of the IETF-104 deadlines:
https://trac.ietf.org/trac/dispatch/wiki/WikiStart

These are a bit later than the estimate presented at IETF-103.  But, the
deadline for topic proposals is this week - Feb 15th.  At this point, we've
seen the RUM proposal. So, please let the chairs know ASAP if you have a
topic and please bring it to the list for discussion.

   - February 8, 2019. Cutoff date for IETF BoF submissions.

   - February 15, 2019. Cutoff date to notify the chairs/DISPATCH WG of
   plans to submit a proposal/topic for discussion.

   - February 22, 2019. Cutoff for proposals (i.e., problem statement and
   proposed deliverables) for topics posted to the DISPATCH WG mailing list.

   - March 1, 2019. Announcement of topics that have been dispatched for
   IETF-104.

   - March 11, 2019. Draft submission deadline.

Regards,
Mary
DISPATCH WG tri-chair

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 13 Feb 2019 18:26:31 +0100

Dear DISPATCH,
The authors of https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-04
have already applied for a BoF session but in case this doesn't go through we would be happy to work with DISPATCH as well.

Abstract

    Cryptographic operations like hashing and signing requires that the
    original data does not change during serialization or parsing.  By
    applying the rules defined by the JSON Canonicalization Scheme (JCS),
    data provided in JSON [RFC8259] format can be exchanged "as is",
    while still being usable by secure cryptographic operations.  JCS
    achieves this by building on the serialization formats for JSON
    primitives as defined by ECMAScript [ES6], constraining JSON data to
    the I-JSON [RFC7493] subset, and through a platform independent
    property sorting scheme.

In an earlier attempt there was a discussion whether this work belonged to the Application or Security area.

With the recent revision this is clearer: "Hashable" JSON is a scheme for Security constructs.

This work *might* also eventually lead to the creation of a standard for signed REST requests.

Regards,
Anders Rundgren for the JCS team