<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 3, 2016 at 1:54 AM, Adam Crain <span dir="ltr"><<a href="mailto:jadamcrain@automatak.com" target="_blank">jadamcrain@automatak.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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?<br></div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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!".<br><br></div><div>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?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>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.<br></div></div></div></blockquote><div><br></div><div>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@domain".<br><br></div><div>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.<br></div><br></div>Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>