[noise] signature questions

[Justin Cormack]

I have been thinking about writing up details of signatures in Noise,
and had a few questions for discussion.

1. Which signature functions to support? In terms of crypto choices,
Noise has been strict about supporting modern choices with good
properties. So supporting Ed25519 for example clearly makes sense.
However one of the use cases that I think is interesting for signing
is use cases where people want the keys to be isolated in some sort of
hardware device, and HSM, TPM etc support tends to lag modern
algorithm choices by some years; the only device I can find with
Ed25519 support is the Yubikey HSM2. The potentially interesting
signing schemes seem to be (there may be others), plus some parameters
eg hash functions:

 - RSA PKCS#1v1.5 exponent 65537 usually with SHA256 (wide support)
 - RSA PSS exponent 65537, usually with SHA256 (TPM2, some yubikey
support, Android, requires a random source)
 - ECDSA p256 with SHA256 (Apple devices, TPM2, Android)
 - ECDSA other NIST curves eg p521 (Android)

Does it seem reasonable to support the common subset of these as well?
For RSA, all devices support 2048 bit keys, and many support 4096 bit,
so it might be say six common functions plus ed25519 that would be
specified.

2. In terms of hash function choices, the message we are signing is
`h`, the state from GetHandshakeHash() at the point at which the
signature is in the protocol. Should we require that the protocol hash
function is at least the size of the hash function being used by the
signature? eg Ed25519 uses sha512, should we insist that the hash
function used is that size, or even the same hash function?

3. Should we support some sort of "wildcard" functionality initially?
I was kind of inclined to get the basic known algorithm version done
first, but obviously if you are talking to a variety of disparate
endpoints agility for signatures might be important.

4. Should deferral and noss modifiers be implicit for signature
variations or explicit? There is no choice here, so it is just a
question of which is clearer or easier to read.

5. Wondering about listing some options for the naming of these.

Trevor's example was
XKsig1i (e.g. XKsig1_25519+RSA2048) # rsa sig

which I presume in full is

Noise_XKsig1i_25519+RSA2048_AESGCM_SHA256

Another option might be that rather than using numbers, any sig or
skem options refer in order to tokens at the end eg

Noise_XKsigi_25519_AESGCM_SHA256_RSA2048 (or
Noise_XKsigi_25519+RSA2048_AESGCM_SHA256)
Noise_XKsigisigr_25519_AESGCM_SHA256_RSA2048_RSA2048

the additional algorithms would be read on order for specified sig,
skem etc. It involves specifying duplicated options twice,
but on the other hand the use of small numbers is a bit overused...