[noise] Proposal: certificate and private key format

Rhys Weatherley rhys.weatherley at gmail.com
Wed Apr 20 11:54:12 PDT 2016

On Thu, Apr 21, 2016 at 2:59 AM, Alex <alex at centromere.net> wrote:

> * Great work so far!
> * The roles "client" and "server" could be misleading. What if you're
>   in a P2P UDP-based environment? It seems to me that "initiator" and
>   "responder" are more appropriate choices.

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".

* If you specify the syntax in ASN.1, then you gain the advantage of
>   not tying yourself down to a particular encoding. In particular,
>   GSER[0] and XER[1] produce human-readable output which can be edited
>   by hand (one of your design principles). And with PER[2] you get a
>   compact representation (another design principle).

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 at 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!

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.

Tony's message about Ordo just popped up.  I'll give it a look.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160421/1efc4b37/attachment.html>

More information about the Noise mailing list