Sign all services public keys when connecting

[ineiti]

As the public.toml contains now more than one service public key, and these keys are used by other nodes, onet needs to make sure that all service public keys are valid, not only the node public key.

https://github.com/dedis/onet/blob/master/network/tls.go#L136 signs the node public key, but should in fact also sign all service public keys, so that the other end can be sure that its public.toml is in fact correct.

[jeffallen]

(This comment is not right, see next comment.)

FYI, the CN we use to transmit the challenge response has a "Z" on the front of it as a kind of version string, which you could use to indicate a different kind of challenge response, proving possession of the other keys. Thus version "Y" could be interpreted as "this is a proof of all service keys instead of only the server key". (see function pubFromCN)

But be careful: there is a length limit on the CN, so you might need to do something like "sign(key_server, hash(concat(sign(key_service1, nonce), sign(key_service2, nonce)))".

But see also #653 for notes on why the CN has to move to SAN now too.

[jeffallen]

Ignore my last comment; the string with the Z on the front is where the server public key is transmitted (and tunnelled inside of the CommonName, no longer allowed in Go 1.15). Changing that to "version Y" would not be helpful at all.

What you want instead is to advertise the service keys via a series of URIs (#653 will put the node key into there, you can put the service keys in as well) and then put a series of signatures of the service keys into other extensions identified by other OIDs than the one that's currently used for the node public key proof of possession (oidDedisSig). It is also not clear to me that the public keys need to be advertised in the TLS certificate at all, need to ask ourselves why we do that.

[ineiti]

It is also not clear to me that the public keys need to be advertised in the TLS certificate at all, need to ask ourselves why we do that.

True - another way to do this is to have the signatures using the (service) private keys in the public.toml. Then you could verify that the node didn't create an attack with a forged public key. That would also be verifiable without having to connect to every node to verify the service public keys...

[ineiti]

Closed in favour of #658