[Cryptography] Is ASN.1 still the thing?

[Phillip Hallam-Baker]

On Mon, Nov 13, 2017 at 5:57 AM, Ben Laurie <ben at links.org> wrote:
> On 13 November 2017 at 03:11, James A. Donald <jamesd at echeque.com> wrote:
>> Do JSON, Yaml, or protobuff allow representing data format in ways that give
>> a unique and well defined checksum, that will not be affected by endianess
>> or compiler options?
>
> JSON is a terrible interchange format, as I've been discovering to my
> cost with objecthash: https://github.com/benlaurie/objecthash - I
> should not have used JSON as the example.
>
> Most obvious problems: different capabilities in different languages,
> can't represent ints over 2^53, no way to transmit raw bytes natively.

I found the lack of binary capabilities to be problematic and so I
defined a set of extensions. Note that unlike every other 'Binary
JSON' proposal I have seen, JSON-B is a genuine superset of JSON.
Every JSON encoding is legal JSON-B and every JSON-B document can be
converted back to JSON. Although obviously using features like int64s
which are not supported by some JSON readers will be an issue.

http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html

This works because the only valid JSON tags are in the range 0-127.
Bytes > 127 can only occur inside a text string.

I am not that bothered about the possibility of using tags that are
not supported by any other language. I have a switch in my compiler
generator that limits the tags I use to alphanumerics. That is not
necessary for my tooling but I see no reason to use others and RFCs
are only accepted in ASCII at present so why bother doing anything
else?


>> Cryptographers specify data formats are in ASN.1 because that way you can
>> get a unique hash or checksum of the data, regardless of which compiler you
>> are using, and whether your machine is big endian or little endian.
>>
>> But these days everyone seems to be using JSON to represent data in transit,
>> because that is the language of the web and of node.js, or YAML, which is
>> JSON polished up to support more kinds of data and to actually be genuinely
>> human readable, or protobuff, because people who write in C++ despise the
>> horrible inefficiency of translating data to and from ascii representation.
>>
>> ASN.1 provides canonical format so that you can hash it or checksum it,
>> ultra efficient binary format for C and C++ purists, and supposedly human
>> readable format, though its human readable format is not particularly human
>> readable.  You are a lot better off with YAML if, as in ini files, you want
>> human readability.
>
> This is precisely why I made objecthash: so you hash the parsed
> object, not its serialisation. As a result, objecthash is
> serialisation agnostic.
>
> It turns out this raises problems of its own, the most obvious being
> "what do you mean by an object?" - but still, it seems useful. I will
> be working on a new version starting ... soon.

You might want to look at this. It is designed to produce fingerprints
of any typed object. The fingerprint is over the object type and
object data so that a trusted OpenPGP key cannot be inserted into an
S/MIME application as trusted causing possible semantic substitution
attacks.

http://www.prismproof.org/Documents/draft-hallambaker-udf.html

Having developed the fingerprint, we can use it to create Strong Internet Names:

http://www.prismproof.org/Documents/draft-hallambaker-sin.html

alice at example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz

This is a name that can only be interpreted in the context of a
security policy that has the UDF fingerprint
mb2gk-6duf5-ygyyl-jny5e-rwshz.

Of course, this is a technology that is rather easier for me to
promote after we sold the CA. The security policy could be the ICANN
trust root, a local trust root, a JSON document describing more
keys...