[Cryptography] [FORGED] Re: Is ASN.1 still the thing?

[Nico Williams]

On Wed, Nov 15, 2017 at 09:27:04AM +0800, Chu Ka-cheong wrote:
> When protobuf first released, it's main feature is the
> interoperability between different iterations of the same protocol.
> 
> Consider you have a message like this at the beginning?
> 
> struct People {
>   name: String
>   address: String
> }
> 
> With ASN.1 you would probably encode it as a SEQUENCE. However, how
> would you specify it if you know you will likely add new fields to it
> in a V2 release maybe a week later?

By using extensibility markers.  Which Protocol Buffers.. does not have.

  People ::= SEQUENCE {
    name UTF8String,
    address UTF8String,
    ...
  }

That ... says "expect extensions, which will be added here".  The ITU-T
thought a lot about extensibility.

You're saying Protocol Buffers exists because ASN.1 types are not
extensible?!  I hope you're wrong, because otherwise that's a lot of egg
to wipe off one's face.  You really do want to look at what came before
before you dispose of it.

> struct People {
>   name: String
>   address: String
>   first_name: String
>   last_name: String
> }

  People ::= SEQUENCE {
    name UTF8String,
    address UTF8String,
    ...,
    firstName UTF8String,
    lastName UTF8String
  }

> You just need to new fields to the message with unique id. V2 will
> still be able to read message from V1 without manual conversion.

Hah!  Protocol Buffers *needs* tags.  ASN.1 *doesn't*.  Sure,
BER/DER/CER use tags, but you can use the automatic tags feature and
never write them down in actual ASN.1 modules.  And PER does NOT even
use tags on the wire.

So, to recap: ASN.1 got you covered and gives you choices of encodings.

You could even make JSON Encoding Rules (then apply CBOR when you
realize that JSON kinda sucks, and you're back to a binary encoding).

Heck, today I learned of a textual encoding rules for ASN.1: GSER.
Surprise!, it's a bit JSON-ish.

And you could even make a PBER -- Protocol Buffers Encoding Rules for
ASN.1.

> Some may say the protocol should be well designed and it shouldn't be
> changed arbitrarily. It may be true for a internet protocol, but it is
> not the case for the communications between different systems within
> the same company, which is the primary use case for protobuf and those
> newer encoding schemes.

Some may think about X and then think that other people haven't thought
about X before.  Some may be wrong.

Some may not research the literature before they start coding.  Some may
needlessly reinvent wheels.  Some may even reinvent wheels badly.  Do
not expect this to end though -- it seems to be human nature.  But you
could do your part today: learn, then teach, this lesson, that you
should look before you go.

Nico
--