[noise] Proposal: certificate and private key format

[Rhys Weatherley]

On Tue, May 3, 2016 at 1:54 AM, Adam Crain <jadamcrain at automatak.com> wrote:

> I've used protobufs in the past and found them to be an excellent tool for
> exchanging data in an efficient manner.  Do protobuf compilers produce
> bindings that detect non-canonical encodings?
>

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.

I'm not sure non-canonical data is that big of a problem though.  It's a
"be conservative in what you send thing".  If a certificate creation app
wants their certificates to have the maximum chance of signature
verification, then using non-canonical forms on output is pretty silly: "I
want my certificates to be non-interoperable!".

I'm actually more concerned about the auditability of protobuf
implementations (ASN.1 has the same issue).  As I said, Google's library is
pretty massive.  Where do you even begin to audit that?

This format seems to be "x509-lite". They use ASN1 DER, but get rid of a
> lot of unnessary fields to produce more efficient representations. Is
> protobuf more compact than ASN DER in this regard? Protobuf seems to have
> MUCH better OSS compiler support than ASN1.
>

Protobufs should be slightly more compact than ASN.1 DER.  ASN.1 DER uses
(tag, size, value) for fields whereas protobufs can get away with (tag,
value) for integer fields.  Arrays are also quite compact for integer
types.  String and compound fields are about the same length.  The main
length gains for certificates are in naming: X.509 DN's are quite verbose
compared with "foo at domain".

The first signed certificate example on my site produces 388 bytes of
output as a protobuf.  Without the signature (i.e. a self-issued
certificate), it is 164 bytes.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160503/8d80c07c/attachment.html>