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

Phillip Hallam-Baker <> Thu, 29 January 2015 23:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6BAB71A1A4E for <>; Thu, 29 Jan 2015 15:18:41 -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 TWoKxcFxjiVn for <>; Thu, 29 Jan 2015 15:18:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E3271A1AB8 for <>; Thu, 29 Jan 2015 15:18:39 -0800 (PST)
Received: by with SMTP id p9so33708486lbv.4 for <>; Thu, 29 Jan 2015 15:18:37 -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=iDNw8yzQfxY9eIpfb3DVf4XnfxC4Gkw/ed8Csmlkf58=; b=LUDeJSmiSh0SiMGZLX8A836sRpdcq//RYbgKk/0wTC2wcwCvBN0sKXVXRhGLhwtq/e 8henRGPf7vjFqSchK1tpYv6V+0lqLdCGxG2TqB39vSvHPstu3wZBRXeL8RhFmOtIn/nB o9h1J7bQ4EICbgw5uWDXHwGIJ7gZxDG2ziPt62QQ3CpAtd9PmiCKu0BzfSutKl1Wf8Wf HWOYtR2pItgWM3MUDYdCMwsD7L5bR8yWn401oxGjEQxIc7CGO1+1o57HxrSW+gJ7LQjA E+5HzuJCV3/WB1Hf43km1QaCLt3j3swHHTRXLUFAZ4PQoJNZJZs+Eq1F8L9W0Nm/AwBt OxQg==
MIME-Version: 1.0
X-Received: by with SMTP id kw9mr3553442lbb.99.1422573517638; Thu, 29 Jan 2015 15:18:37 -0800 (PST)
Received: by with HTTP; Thu, 29 Jan 2015 15:18:37 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 29 Jan 2015 18:18:37 -0500
X-Google-Sender-Auth: -JiYkUevrBFjfAGRNbRsKYLP3HE
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary="047d7bae49da2f919b050dd2b5c7"
Archived-At: <>
Cc: "" <>
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 23:18:41 -0000

On Thu, Jan 29, 2015 at 2:40 PM, Daniel Kahn Gillmor <>

> On Thu 2015-01-29 08:53:58 -0500, Phillip Hallam-Baker wrote:
> > 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.
> RFC 1847 (Security Multiparts for MIME) [0] recommended this "keep the
> original sequence of bits intact" variant way back in 1995:
> >>    The entire contents of the multipart/signed container must be treated
> >>    as opaque while it is in transit from an originator to a recipient.
> But some implementations still get this wrong, and it breaks some signed
> messages today, depending on how those messages are handled in transit.
> (this is about RFC822 header canonicalization, fwiw, not JSON
> canonicalization, but the point is the same).

HTTP is defined as a 8-bit clean. If the content does not pass through with
every bit intact then abort and retry.

Now certainly, if you want to transfer huge gobs of data then you probably
want to use a different transfer encoding that divides the content into
chunks with separate error checks.

> For example, In 2004 (probably earlier), it was observed that python
> e-mail parser failed to "keep the original sequence of bits intact" [1],
> and the bug is still not fixed today, afaict.

Which is why I would only use HTTP which does not have that issue.

> We're talking about nearly 20 years of failing to do this "easy"
> approach.

Only for SMTP. HTTP has had 20 glorious years of success in that regard.

>  Taking the other approach, OpenPGP signatures of textual data use a

canonicalized document format (specifying <CR><LF> line-endings,
> ignoring whitespace at the end of lines, back in 1998) [2], and that
> seems to have actually worked out OK in terms of interop, though i've
> seen some (quickly-fixed) errors pop up over the years.

Only if you don't want to use MIME messages in which case weeping and
gnashing of teeth awaits one.

> People want to investigate and parse and display the content they're
> working with, even if there is a signature on it.  It's very tempting
> for implementors to treat the parsed form as the sole internal data, and
> not to keep around the other binary blob.  Having a well-documented
> canonicalization procedure makes that easier.

And deliberately not using a canonicalization scheme makes that misguided
approach impossible.

> i'm not saying that canonicalization is necessarily the right solution
> here, but it's not like the "just keep your bits intact" proposal is
> particularly robust either.