[noise] Proposal: certificate and private key format

[Tony Arcieri]

On Sat, Apr 30, 2016 at 7:11 PM, Rhys Weatherley <rhys.weatherley at gmail.com>
wrote:

> Since no one seemed to be a fan of my text-based certificate format, I
> have reworked the proposal using protobufs instead:
>
> http://rweather.github.io/noise-c/cert_key_format.html
> https://github.com/rweather/noise-c/blob/master/doc/noise-certificate.proto
>
> Feedback is appreciated.
>

The move to protobufs seems like a positive step to me.

However, when I see things like this:


The signature covers the contents of the "subject" and "extra_signed_info"
fields, represented in the standard Protocol Buffers Encoding
<https://developers.google.com/protocol-buffers/docs/encoding>. The
encoding MUST be "canonical" in that all integer values, field tag numbers,
and field lengths are represented using the minimum number of bytes for the
value, and the fields are listed strictly in order of field tag number.


The "clippy" inside my head starts asking questions like. "It looks like
you're trying to invent your own protobufs canonicalization format. Are you
sure you want to do this?" Especially when I see statements like this:

Not that I've seen.  A quick scan of Google's protobuf and protobuf-c
didn't reveal any checks for non-canonical varints that I could see
(Google's library is pretty massive though so I could have missed it).
Since I'm writing my own minimalistic security-hardened protobuf
infrastructure for use inside Noise-C, I can solve that problem as I go.

Granted this is generally less of a problem with Protobufs than other
formats, but it seems like one with solving with some standard method than
an ad hoc format-specific invention...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160502/f01ec915/attachment.html>