[Cryptography] [FORGED] Re: Is ASN.1 still the thing?
phill at hallambaker.com
Sat Nov 25 22:53:55 EST 2017
On Fri, Nov 24, 2017 at 4:11 PM, Nico Williams <nico at cryptonector.com> wrote:
> On Fri, Nov 24, 2017 at 03:36:58PM -0500, Phillip Hallam-Baker wrote:
>> On Tue, Nov 21, 2017 at 4:05 PM, Nico Williams <nico at cryptonector.com> wrote:
>> > Sure. But again, would you rather respond to this by:
>> > a) building a new spec and tools for it,
>> > or
>> > b) building tools for the existing spec
> Please don't. Don't use BER/DER/CER -- those are lousy, as is Protocol
> Buffers, because they are all TLV encodings.
> Use PER/OER/XDR or anything like them, but don't build something brand
> new. It'll be a burden on the rest of us.
Nothing could be a tenth the burden that Asinine One has been.
>> Missing important considerations is a risk but I find JSON with very
>> minor extensions has met all my needs and the Mesh is pretty
> JSON is _horrible_, mostly because of the need to escape characters in
> strings, and the lack of a binary type. Some binary JSON encodings are
JSON-B adds the missing binary type and an unescaped string type. Job done.
> Sure, you absolutely can generate ASN.1 or whatever from equivalent
> languages, and there's a lot to say for doing that, especially if you
> use XML or SQL, as then you can write a lot of tooling in functional/
> declarative languages. I do this sort of thing (in the latest case I
> generate JSON schema descriptions from SQL schemata).
There is actually something I hate more than ASN.1 and it is SQL.
Why on earth would I want code injection heaven near my systems?
> And, of course, you can easily produce a one-to-one mapping of a subset
> of XML to/from ASN.1, so you really need not think of ASN.1 if you hate
> the notation.
I could produce ASN.1 simply by changing one switch on the synthesizer
but I won't because ASN.1 is less popular than Ebola in some parts and
I am not going to spend my time and effort on restoring its
>> > As others, and I, have been saying, XDR is a perfectly good choice in
>> Main objection I would make is 32 bit lengths are rather short for modern needs.
> Easy to work around: chunk up any data types whose values can get that
> big. It's probably worth it too. And if you have indeterminate-length
> payloads, you'll have to chunk them up anyways, a la HTTP chunked
> transfer encoding.
Or just use a modern encoding like JSON-B.
More information about the cryptography