Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mRemoteNG/PuTTYNG.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/utils
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2022-04-20 15:06:08 +0300
committerSimon Tatham <anakin@pobox.com>2022-04-25 17:09:31 +0300
commit9f583c4fa8f632c349e6b335a4ab5cd69b0a76f9 (patch)
tree8b2fae27bd675133eee6394fae37518ec61e1e38 /utils
parent34d01e1b654d8c42ebd7f8abc05f5c2693f2a6a1 (diff)
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.)
Diffstat (limited to 'utils')
-rw-r--r--utils/nullkey.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/utils/nullkey.c b/utils/nullkey.c
index d4f2a691..1b01c891 100644
--- a/utils/nullkey.c
+++ b/utils/nullkey.c
@@ -11,3 +11,9 @@ 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;
+}