[noise] [Noise socket] Ambiguity of keys & certs

[Alexey Ermishkin]

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

-----Original Message-----
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.


Trevor