<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 20, 2016 at 11:54 AM, Rhys Weatherley <span dir="ltr"><<a href="mailto:rhys.weatherley@gmail.com" target="_blank">rhys.weatherley@gmail.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 class="gmail_extra"><div class="gmail_quote"><div>ASN.1 is one of the leading causes of security holes in TLS implementations.</div></div></div></div></blockquote><div><br></div><div>I'm a fan of LANGSEC and have previously made statements like "Should ASN.1 die in a fire?". That said...</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 class="gmail_extra"><div class="gmail_quote"><div>It doesn't matter which encoding you use, it's unsafe in all of them.</div></div></div></div></blockquote><div><br></div><div>If you look at the recent history of vulnerabilities (BERserk, Linux kernel BER module verification ring 0 exploits) it seems BER is definitely the stand-out problematic encoding. I also think OER addresses a lot of the problems in previous encodings like DER and BER, while still providing the same benefits BER was supposed to provide (compactness) without the complexity. And let's just forget about XER ;)</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 class="gmail_extra"><div class="gmail_quote"><div>ASN.1 also has a tendency to take over your entire design: everything ends up in service of the Holy Representation.  For example, X.500 distinguished names are the wrong way to refer to anything on the Internet (foo@domain is more natural), yet ASN.1 systems always gravitate towards X.500 naming "for consistency".  And don't get me started on object identifiers - ugh!<br></div></div></div></div></blockquote><div><br></div><div>I agree with almost everything you're saying based on previous standards, but going forward nothing in ASN.1 is actually forcing you to use OIDs for example. You could replace them with octet string labels if you desired, perhaps dolling out named prefixes (e.g. "noise-*") to standards writers who request them (in the grand scheme of things this could be an IANA function)</div><div><br></div><div>ASN.1 has a rich type system and a lot of tooling around it, along with a lot of precedent in existing Internet standards. I don't think we need to throw the baby out with the bathwater.</div><div><br></div><div>That said it's definitely not the only game in town. Protobufs, capnproto, etc provide many of the same benefits.</div></div><div><br></div><div>Human readable certificates are great but they do come at a cost in terms of compactness. Is it worth it? I'm not sure. I can definitely say I've typed openssl -x509 way more times in my life than I would have liked to.</div><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>