<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 21, 2016 at 2:59 AM, Alex <span dir="ltr"><<a href="mailto:alex@centromere.net" target="_blank">alex@centromere.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Great work so far!<br>
<br>
* The roles "client" and "server" could be misleading. What if you're<br>
  in a P2P UDP-based environment? It seems to me that "initiator" and<br>
  "responder" are more appropriate choices.<br></blockquote><div><br></div><div>In Noise Pipes, the initiator/responder roles get reversed half-way through the protocol for XXfallback.  But yes, "client" and "server" are not ideal.  The signing keys have an "identity" role for the user's identity.  Maybe "user", "host", "tunnel", etc are better role names?  Or leave it up to the application and don't have any pre-defined roles other than "certificate signer".<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* If you specify the syntax in ASN.1, then you gain the advantage of<br>
  not tying yourself down to a particular encoding. In particular,<br>
  GSER[0] and XER[1] produce human-readable output which can be edited<br>
  by hand (one of your design principles). And with PER[2] you get a<br>
  compact representation (another design principle).<br></blockquote><div><br></div><div>ASN.1 is one of the leading causes of security holes in TLS implementations.  It doesn't matter which encoding you use, it's unsafe in all of them.  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><br>Text parsing is a well-understood problem with support functions in every language's equivalent of libc.  There are issues such as C's strcpy(), but it's well understood how to deal with those issues.<br></div><div><br></div><div>Tony's message about Ordo just popped up.  I'll give it a look.<br></div><div><br></div></div>Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>