[noise] Signatures and handshake payloads (was Re: Noise @ Highload++ in Moscow)

[Trevor Perrin]

On Tue, Nov 14, 2017 at 10:01 PM, Tony Arcieri <bascule at gmail.com> wrote:
> On Tue, Nov 14, 2017 at 12:06 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> Protobufs (v3) specifies a JSON mapping [1], so maybe taking a simple
>> subset of the protobufs language would give us something that's fairly
>> readable and easy to work with, has good language support, and has
>> good binary and string (JSON) encodings?
>
>
> "simple subset of the protobufs language" sounds fairly close to a project
> of mine which is intended for serializing credentials:
>
> https://github.com/zcred/veriform

That's cool, but I think targeted at a more complex problem.

We're just thinking about extensible language(s) for handshake
payloads (and NoiseSocket negotiation_data).

I think these would mostly carry simple data:
 * Version numbers / names
 * Noise protocol names or numbers (or hash /  DH / cipher names)
 * Names (for users, services, servers)
 * Certificates / cert chains
 * Other negotiation (e.g. payload sizes)

So we don't need a lot of features, but we do want a language that's
easy to work with, has good library support with bulletproof parsers,
and maybe the ability to "transcode" into different encodings (JSON,
XML, etc).


> However based on the rest of your comments, it sounds like you'd prefer a
> strict subset of Protobufs which can leverage the extant ecosystem/tooling,
> as opposed to a Proto-"inspired" format with breaking changes.

Yeah, exactly ("strict subset").  Maybe quite reduced, e.g. proto3
with only (uint32, uint64, bool, string, bytes), and without enums,
nested messages, oneof, etc.


> X.509 would be nice for:
>
> - institutions that already invest heavily in X.509 as their primary
> certificate/key management solution

Agreed.


> - "the devil you know" in absence of an e.g. Protobuf-based system

Of course, you can use protobufs to transmit X.509 certs/chains.

Trevor