[noise] [Noise socket] Ambiguity of keys & certs
scratch.net at gmail.com
Thu Mar 16 04:19:28 PDT 2017
A detached cert public key is definitely an interesting one to think about, but it complicates the process of calculating cert signature which is now just a "take a hash of that byte array and sign". Will need to specify additional data concatenation/hash concatenation rules for that to work.
Ok, no problem, comparison will do the job for now
From: Trevor Perrin [mailto:trevp at trevp.net]
Sent: Thursday, March 16, 2017 3:06 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] [Noise socket] Ambiguity of keys & certs
On Thu, Mar 16, 2017 at 2:43 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> For now, while using curve 25519 & 448 we can just take a cert (we
> actually have a kind of ed25519 certs which public keys can be
> converted to
> curve25519) and compare "rs" to the one, supplied in cert. Will work
> ok for the version 1.
> But in future it's obvious that sending static key twice & its
> comparison with cert's internals is not what we are supposed to do.
> Especially when using other classic curves with different point
> encoding techniques and PQC with their huge public keys.
You could omit the static public key from the certificate encoding.
I think it's a better design to have all the crypto handled in a simple Noise layer, with certificates pushed to the application layer.
If the static public keys had to be dug out of certificates then we have to define variable-length handling and callbacks for cert-parsing, which seems ugly.
Conceptually I don't like the X.509 assumption that entities should have 1 cert containing their key. Maybe you have 0 certs, maybe you have several, so I prefer thinking of a cert as evidence "about" some public key, rather than a container for the public key.
More information about the Noise