Re: [Json] RFC 8785 - JSON Canonicalization Scheme

Ulysse Carion <ulysse@segment.com> Mon, 06 July 2020 01:10 UTC

Return-Path: <ulysse@segment.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CCB3A0CE9 for <json@ietfa.amsl.com>; Sun, 5 Jul 2020 18:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.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 xWbm1npr2SAR for <json@ietfa.amsl.com>; Sun, 5 Jul 2020 18:10:55 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 1B68C3A0CE6 for <json@ietf.org>; Sun, 5 Jul 2020 18:10:55 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id v8so37568221iox.2 for <json@ietf.org>; Sun, 05 Jul 2020 18:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M7j92A29fq4YY2PoB1MJumNClb6RioajxmYUEpkmUGI=; b=mto6vQq2EddOY6p1h0wqxhqO+X4Kz+aT+JCbSwJJsYAE6/3rFbOmKVxis3Ab9FV69j JBIS0TxnEZLrZPT/S1uZlGGcKQjvLTROc19zDLCnD/bqe7pELSjx4LQoDMgb8VGrh4dH Xf0BgmA9LDm8ceZhejffnndbzcDoxvGkqBIOc=
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=M7j92A29fq4YY2PoB1MJumNClb6RioajxmYUEpkmUGI=; b=HCxp52y143Y0yxjkzbXTgDR+Kna4OGhORIMMnU7XN/pZUKeETrwzpj9SfKcfd5j8wJ zK3ajLnnmv05uBEcW8Wut//gpe0mG8jQbNwpVA974VRo/mNcWs0fB2HvgZG9y7+XdLf7 damiEniTRSYBHEBYjd3KN+ArJkhmsJPMnK4uZPFFs6moPqOceuAjKK0zPDWQ65OSawKx yjpVzHT5YAAxQWek3iJNLbuv080++FtisxH6ITLSCD9G6UOwKkyOwUzZVG+R0TQMbzuY Mx1mJnDjSHEqEnKPDgZDGwZASnejpxH5DC6pH78Br4Ce56KWoFrwPyRR9vX8d5LgTdni b6BA==
X-Gm-Message-State: AOAM532syR7AkhXNoQ4yhI/Kij5fMSkWqkYFQW/FQB2oEEvLox9jj4wk v7DN1fnLKr2GyWUjDdgorcGsU8+djDfUEVoRM1Rfew==
X-Google-Smtp-Source: ABdhPJyVUSWLSKuEaMnTJ7kPBveIigVaqS3F3Ww3cg4i3sft01R0pS01/lG51hTnw6ZUyIOuQnvPD8exaq0GgGl2rio=
X-Received: by 2002:a6b:b483:: with SMTP id d125mr22989176iof.186.1593997854052; Sun, 05 Jul 2020 18:10:54 -0700 (PDT)
MIME-Version: 1.0
References: <ce98d1e6-1f39-84ca-b9b0-d11b0aa3c2f7@gmail.com> <715bce33-a744-5a97-8c6b-c7d2b27510f2@gmail.com>
In-Reply-To: <715bce33-a744-5a97-8c6b-c7d2b27510f2@gmail.com>
From: Ulysse Carion <ulysse@segment.com>
Date: Sun, 5 Jul 2020 18:10:33 -0700
Message-ID: <CAJK=1Rje7POnLVrUxPFAkAb5h8atP3n25GYyGdWob3wZRWH20g@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: "json@ietf.org" <json@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/2pZQ5eDfn_KuGup4E7CAiU6z5Qg>
Subject: Re: [Json] RFC 8785 - JSON Canonicalization Scheme
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2020 01:10:58 -0000

Hi Anders,

Nice job with JCS. I've taken a stab at implementing it here (in
Golang), because I have a possible use for something like this, and
your Golang reference implementation wasn't super usable as-is:

https://github.com/ucarion/jcs

Overall, I think this document makes sense, and -- given its
prerequisites -- is the design any one of us would have landed on
given time to meditate on the details. I usually specifically avoid
embedding signatures within the data being signed, but when that's not
an option JCS seems a quite reasonable choice.

Two notes on what you could do to help future implementers:

1. I wish you could provide some sort of script that generates
floating-point test-cases, instead of having folks download a 3.8G
file if they want to make sure they're correctly aping JavaScript's
float-to-string algorithm.

2. I don't understand why implementations MUST detect and error on
invalid surrogate pairs. For implementations that aren't implementing
their own JSON parser at the same time, doing so may not always be
possible. Can you elaborate on the reasoning, and maybe offer
implementers guidance on the relevant parts of the Unicode spec? A
prospective implementer already needs to go pretty deep into the hairy
details of floating-point numbers and character encoding, and a bit of
guidance in the developer portal would go a long way.

These are just details. Overall, I think JCS is quite nicely done.
Thanks for making this.

Best,
Ulysse


On Sat, Jul 4, 2020 at 11:27 AM Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
>
> https://www.rfc-editor.org/rfc/rfc8785
>
> In case you would like to test what you can do with JSON canonicalization, there are two public Web applications at your disposal:
> Using JWS: https://mobilepki.org/jws-jcs
> Using an "unwrapped" JWS called Java Signature Format (JSF): https://mobilepki.org/jsf-lab
>
> A real-world implementation from OWASP using JSF: https://cyclonedx.org/use-cases/#authenticity
>
> In Saturn JSF is not only a security solution, it is also used for counter-signatures to simplify state-holding in payment systems:
> https://cyberphone.github.io/doc/saturn/hybrid-payment.html#6
>
> By securely embedding related messages in each other (aka "Russian doll"), there is no need for external references to previous messages.
>
> Enjoy!
>
> Anders
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json