putty-source/utils/nullkey.c

#include "misc.h"
#include "ssh.h"

unsigned nullkey_supported_flags(const ssh_keyalg *self)
{
    return 0;
}

const char *nullkey_alternate_ssh_id(const ssh_keyalg *self, unsigned flags)
{
    /* There are no alternate ids */
    return self->ssh_id;
}

ssh_key *nullkey_base_key(ssh_key *key)
{
    /* When a key is not certified, it is its own base */
    return key;
}
ssh_keyalg: new method 'alternate_ssh_id'. Previously, the fact that "ssh-rsa" sometimes comes with two subtypes "rsa-sha2-256" and "rsa-sha2-512" was known to three different parts of the code - two in userauth and one in transport. Now the knowledge of what those ids are, which one goes with which signing flags, and which key types have subtypes at all, is centralised into a method of the key algorithm, and all those locations just query it. This will enable the introduction of further key algorithms that have a parallel upgrade system. 2022-04-19 17:27:54 +01:00			`#include "misc.h"`
Make ssh_keyalg's supported_flags a method. It's a class method rather than an object method, so it doesn't allow keys with the same algorithm to make different choices about what flags they support. But that's not what I wanted it for: the real purpose is to allow one key algorithm to delegate supported_flags to another, by having its method implementation call the one from the delegate class. (If only C's compile/link model permitted me to initialise a field of one global const struct variable to be a copy of that of another, I wouldn't need the runtime overhead of this method! But object file formats don't let you even specify that.) Most key algorithms support no flags at all, so they all want to use the same implementation of this method. So I've started a file of stubs utils/nullkey.c to contain the common stub version. 2022-04-19 17:05:36 +01:00			`#include "ssh.h"`

			`unsigned nullkey_supported_flags(const ssh_keyalg *self)`
			`{`
			`return 0;`
			`}`
ssh_keyalg: new method 'alternate_ssh_id'. Previously, the fact that "ssh-rsa" sometimes comes with two subtypes "rsa-sha2-256" and "rsa-sha2-512" was known to three different parts of the code - two in userauth and one in transport. Now the knowledge of what those ids are, which one goes with which signing flags, and which key types have subtypes at all, is centralised into a method of the key algorithm, and all those locations just query it. This will enable the introduction of further key algorithms that have a parallel upgrade system. 2022-04-19 17:27:54 +01:00
			`const char nullkey_alternate_ssh_id(const ssh_keyalg self, unsigned flags)`
			`{`
			`/* There are no alternate ids */`
			`return self->ssh_id;`
			`}`
Certificate-specific ssh_key method suite. Certificate keys don't work the same as normal keys, so the rest of the code is going to have to pay attention to whether a key is a certificate, and if so, treat it differently and do cert-specific stuff to it. So here's a collection of methods for that purpose. With one exception, these methods of ssh_key are not expected to be implemented at all in non-certificate key types: they should only ever be called once you already know you're dealing with a certificate. So most of the new method pointers can be left out of the ssh_keyalg initialisers. The exception is the base_key method, which retrieves the base key of a certificate - the underlying one with the certificate stripped off. It's convenient for non-certificate keys to implement this too, and just return a pointer to themselves. So I've added an implementation in nullkey.c doing that. (The returned pointer doesn't transfer ownership; you have to use the new ssh_key_clone() if you want to keep the base key after freeing the certificate key.) The methods _only_ implemented in certificates: Query methods to return the public key of the CA (for looking up in a list of trusted ones), and to return the key id string (which exists to be written into log files). Obviously, we need a check_cert() method which will verify the CA's actual signature, not to mention checking all the other details like the principal and the validity period. And there's another fiddly method for dealing with the RSA upgrade system, called 'related_alg'. This is quite like alternate_ssh_id, in that its job is to upgrade one key algorithm to a related one with more modern RSA signing flags (or any other similar thing that might later reuse the same mechanism). But where alternate_ssh_id took the actual signing flags as an argument, this takes a pointer to the upgraded base algorithm. So it answers the question "What is to this key algorithm as you are to its base?" - if you call it on opensshcert_ssh_rsa and give it ssh_rsa_sha512, it'll give you back opensshcert_ssh_rsa_sha512. (It's awkward to have to have another of these fiddly methods, and in the longer term I'd like to try to clean up their proliferation a bit. But I even more dislike the alternative of just going through all_keyalgs looking for a cert algorithm with, say, ssh_rsa_sha512 as the base: that approach would work fine now but it would be a lurking time bomb for when all the -cert-v02@ methods appear one day. This way, each certificate type can upgrade itself to the appropriately related version. And at least related_alg is only needed if you _are_ a certificate key type - it's not adding yet another piece of null-method boilerplate to the rest.) 2022-04-20 13:06:08 +01:00
			`ssh_key nullkey_base_key(ssh_key key)`
			`{`
			`/* When a key is not certified, it is its own base */`
			`return key;`
			`}`