Re: [Acme] ACME or EST?

Phillip Hallam-Baker <> Fri, 28 November 2014 02:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0ABAF1A066B for <>; Thu, 27 Nov 2014 18:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MLLn3vUFy6CL for <>; Thu, 27 Nov 2014 18:30:05 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC9B91A047A for <>; Thu, 27 Nov 2014 18:30:04 -0800 (PST)
Received: by with SMTP id hz20so5037583lab.34 for <>; Thu, 27 Nov 2014 18:30:03 -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:content-transfer-encoding; bh=nv44sx+8e1tiMik29MtWDFM+mwMUnBNX51bY+9DyFhA=; b=05w0+i976tx29+i//gu2EJNe2dZZKxGKdhKgt+Xa6cMJO3D9VREupb0WGuS5/QKrx8 GQwg5x0nrLLwMG63+Q7cWqlljiNbonADAB/L7xeaZJM3H9Cr7iIQEc1TQxkKnIhvS0AG 09Um7Wusf0pFqh0pTd72JXAuz1rw5vVI4lnWAaPC7qGM9agU44l/pTZ21iEhpmDB1iyi 93mLliINn1vl7+1aERDCfN2/UuTCytth2SUEa1OEKYPOywQ5Yn4fIfxNBmEu1oR8l0Dj 9pdBFcGC2sC3Dvs07ZeK2kKQbfJ74Emo/6eZE3AfHBSyzCy0UjMU7rlaOlh0jRR6fx7/ xlEA==
MIME-Version: 1.0
X-Received: by with SMTP id v3mr39538299laz.97.1417141803267; Thu, 27 Nov 2014 18:30:03 -0800 (PST)
Received: by with HTTP; Thu, 27 Nov 2014 18:30:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 27 Nov 2014 21:30:03 -0500
X-Google-Sender-Auth: vcXHWyCYn1mJDt3kB4bm-Y5tq5E
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Christian Huitema <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Fri, 28 Nov 2014 02:30:06 -0000

On Thu, Nov 27, 2014 at 5:42 PM, Christian Huitema
<> wrote:
>> 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."

But as a programer responsible for the security of the code, that
means I can't just take an off the shelf ASN.1 library and use it. I
have to roll my own to be sure the checks are made. Which in fact is
what I do.

So the existence of ASN.1 tools does nothing to reduce the impact of
the needless complexity.

> 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.

That is why I would like us to stick to one data model and at most two
encodings of that data model going forward. Those being text and