Re: [Acme] ACME or EST?

Christian Huitema <> Thu, 27 November 2014 22:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A2421A0141 for <>; Thu, 27 Nov 2014 14:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wroWAjRXk2wP for <>; Thu, 27 Nov 2014 14:43:04 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::1:716]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D79FB1A00D8 for <>; Thu, 27 Nov 2014 14:43:03 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 27 Nov 2014 22:42:40 +0000
Received: from ([]) by ([]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 22:42:40 +0000
From: Christian Huitema <>
To: Phillip Hallam-Baker <>
Thread-Topic: [Acme] ACME or EST?
Thread-Index: AQHQCPjbhOyJTn6r2k6eMGuP4A40fpxx4zaAgAAGHwCAAn3HR4AATagAgABcknA=
Date: Thu, 27 Nov 2014 22:42:39 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654;
x-forefront-prvs: 040866B734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(33656002)(110136001)(101416001)(92566001)(86362001)(92726001)(20776003)(66066001)(97736003)(77156002)(77096003)(86612001)(2656002)(87936001)(106356001)(106116001)(99286002)(105586002)(107046002)(95666004)(62966003)(64706001)(54606007)(76176999)(50986999)(54356999)(31966008)(122556002)(40100003)(99396003)(46102003)(120916001)(74316001)(54206007)(21056001)(4396001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Acme] ACME or EST?
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, 27 Nov 2014 22:43:06 -0000

> One of the many reasons to drop ASN.1, particularly the Deranged Encoding Rules.
> The type of coding error that comes up is as follows:
> Tag Length[ Tag Length [Value]]
> Lets say each atom has a length of 1 byte, this would be coded
> xx 03 xx 01 xx
> Now what happens if the coder is wrong and instead gives:
> xx 99 xx 01 xx
> Buffer overrun error time!

On the other hand, there is enough information in the BER/DER encoding to perform run time verifications and avoid these overruns. It falls in the general category of "never trust input received from the network."

You can find this kind of errors with pretty much any "variable length" format. If you have explicit length coding, then you must check the consistency of the stated length with the message buffer. If you have implicit coding, e.g. using some kind of delimiter, you must checks that delimiters happen before the end of the message.

Then, there is all the fun related to integer overflow, especially when the syntax uses element counts rather than element length. Or stack overflow if the decoder uses recursion. Remember the attacks using "specially crafted JPEG images?"

I am not sure that the message description language matters very much, the quality of the implementation matters much more. And, as far as protocol go, better keep the syntax as simple as possible. But you are right about the level of "exotic complexity" in ASN.1. It does not help.

-- Christian Huitema