[noise] Signatures and handshake payloads (was Re: Noise @ Highload++ in Moscow)
trevp at trevp.net
Tue Nov 14 15:50:16 PST 2017
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 , 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:
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,
> 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
> - "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.
More information about the Noise