Re: [Acme] [jose] [Json] Signed JSON document / Json Content Metaheader / JSON Container

Phillip Hallam-Baker <> Thu, 29 January 2015 13:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 83F2F1A0B00; Thu, 29 Jan 2015 05:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zeHFw1ny6hlD; Thu, 29 Jan 2015 05:54:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8D261A0687; Thu, 29 Jan 2015 05:54:00 -0800 (PST)
Received: by with SMTP id u10so28239382lbd.12; Thu, 29 Jan 2015 05:53:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t/mdFXacjFz1BdHg0lzpYmRbLgW0JgIh65XA3Ylr/7I=; b=mQ/0o6vs0WeOr56WZawrz2aWPzJAyvS2zQSliJSpJM7n3IcAqodW3z5wiP9mszIOrV lWjI8ccrKWj3mQFIfI4gkEnwft83iFWPpdq6upuXxtstKMSGNyFe17v1yiQuQPT5Gxte iPnO1aSO65CnCZrLQIGDVs8ExT2g4Ezm7LlU8sykVMX0SDoexc3QbZ5PECMgW0ROzNZu lTb8vKJ+/cdYKm9Jerp8Yu/h602gBxfdgSq94JGTssd/21wHZE/ASmGhcOs2MiLHpPqn EAq/OlDflqqFZw8hdYv1nTwWb+uWoGVxvAv1eV4eG/XcjDbBcUzJ0nJ/cBIhi9xzCC3p K7iw==
MIME-Version: 1.0
X-Received: by with SMTP id oi1mr954551lbb.2.1422539639121; Thu, 29 Jan 2015 05:53:59 -0800 (PST)
Received: by with HTTP; Thu, 29 Jan 2015 05:53:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 29 Jan 2015 08:53:58 -0500
X-Google-Sender-Auth: Qp_Ffgb9ZpDRLYvKmLleHPX6nOc
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="047d7b343106de6e62050dcad1c3"
Archived-At: <>
Cc: "" <>, Anders Rundgren <>, Nat Sakimura <>, "" <>, "Manger, James" <>, Fraser Tweedale <>
Subject: Re: [Acme] [jose] [Json] Signed JSON document / Json Content Metaheader / JSON Container
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jan 2015 13:54:02 -0000

On Thu, Jan 29, 2015 at 8:14 AM, Justin Richer <> wrote:

> Relying on side-effects of a handful of contemporary implementations is
> dangerous at best and absolutely foolhardy at worst, especially when it
> comes to security systems. You *need* to have a formal canonicalization,
> normalization, or serialization in order for these things to work in
> practice.
> Otherwise, you're betting on luck, and that's just daft.


Canonicalization is the stupidest idea in computer security. It is never
ever necessary and never ever implemented reliably.

A digital signature signs a sequence of bits. So if you ever want to check
a signature again, make sure you keep hold of your original sequence of
bits. Simple!

I see people say that canonicalization is 'essential' in every discussion
of signatures. What I have never seen is an example of something that is a
reasonable thing to do that goes wrong if you don't have C15N.

And by reasonable, I do not mean 'take a cert, store it in X.500 directory,
reassemble'. DER encoding is the stupidest stupid of all the steaming piles
of stupid in ASN.1. BER meets the needs of X.509 just as well, as was
proved by the fact that the Web ran quite happily on BER encoded certs
until some spoilsport let on what we had been doing.

The reason I am proposing JSON Container is precisely to avoid the need for
canonicalization. That does not work in XML Dig sig and it won't work for

My proposal has three parts:

1) A blob of data where the only requirement is that it must be a valid
JSON encoding. Changing this is permitted. Want to add another signature,
go ahead! So not only are syntactic differences allowed, semantic changes
are allowed as well.

2) A separator marker to unambiguously define the end of (1) and the start
of (3)

3) The sequence of bits that was signed.

A signature in (1) cannot refer to any part of (1), it can only reference
(3) and is by default the whole of (3) but could be a well defined range
inside (3) instead.

That is it, no JSON canonicalization or unique serialization required. This
is a proposal for wrapping arbitrary content data with a wrapper that
contains JSON metadata which might include signatures. There is no reason
for either the signature or the data to be in a canonical form.

If you want to have signed metadata, you would need to first wrap the
content with a JSON Container with the metadata and then wrap that with a
second container with the signature.