Re: [Acme] ACME or EST?

[Nico Williams <[e-mail]>]

On Thu, Nov 27, 2014 at 09:30:03PM -0500, Phillip Hallam-Baker wrote:
> On Thu, Nov 27, 2014 at 5:42 PM, Christian Huitema
> <[e-mail]> wrote:
> > [...]
>
> 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 find this very strange, whether said about ASN.1 or anything else.
Sure, often there's no better choice than open-coding whatever you need,
but do you write everything in assembly?  Probably not.

My advice: find the most hackable ASN.1 open source tooling, and use
that.  My preference is Heimdal's ASN.1 compiler, which is damn near
standalone, produces C code as well as bytecode (--template option), and
is easy to hack on to output other code.
https://github.com/heimdal/heimdal/tree/master/lib/asn1

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

The base languages, x.680, is not exotic at all.  Compared to XDR, for
example, it has a few features that XDR doesn't have (e.g., default-able
struct fields, SETs), and somewhat different syntax, but otherwise the
two are roughly very similar.  It's *just* syntax, after all.  It's the
encoding rules that are cause problems, and even there, ASN.1's rules
cover all the bases: don't use the TLV encodings.

The various additions like x.681 and x.683 are quite complex, but not
needed for Internet protocols.

Nico
--