[noise] Proposal: certificate and private key format

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

On Thu, Apr 21, 2016 at 4:33 AM, Trevor Perrin <trevp at trevp.net> wrote:

> On Wed, Apr 20, 2016 at 4:11 AM, Rhys Weatherley
> > So, here's an idea I've been drafting for a few days:
> >
> > http://rweather.github.io/noise-c/cert_key_format.html
> I think you'll find applications vary in:
>  - preferred encoding (JSON, XML, Protobufs, etc)

Yes.  For now I'm most interested in how to store keys on disk for
configuring a Noise application.  I kept it small so it could fit in a
Noise packet, but wire encoding may be best left to a separate spec.

>  - contents needed for any certificate - e.g. if a client is just
> contacting a pinned service, your "certificate" might be nothing more
> than a single signature from some offline key.  11 fields is probably
> overkill for a lot of cases.

Id, Name, Enc-Role, and the signature blocks are all optional.  The minimal
certificate is:

Enc-Key: 25519,0bvYYwOPwdtcrove1ij37SbAhnuQ++4j2+/sELJaNUA=

With a signature, the minimum is:

Enc-Key: 25519,0bvYYwOPwdtcrove1ij37SbAhnuQ++4j2+/sELJaNUA=
Sign-Key: Ed25519,dS45RT8DNVhldxcHgsFHj6NA6pKs5dF2lUrda9lhoAb=
Nonce: Lya4LdMCDhAwVbJf8oKwFw==


And even Nonce can be left out in a pinch.

That said, it's cool to see work on infrastructure atop Noise, I would
> just keep it clear in APIs and libraries that this is a separate /
> additional layer atop the Noise framework.

Exactly.  My plan with Noise-C is to have a basic libnoiseprotocol for the
protocol and crypto necessities, with everything else in separate
libraries: libnoisekeys, libnoisetransport, etc.  If an application wants
to do everything above the protocol themselves, there's no additional cost.


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

More information about the Noise mailing list