And other tech rant. It was recently asked, in a forum that I read, the following: "Why is it that SSH public keys don’t have an embedded expiration date, anyway? PKI certificates have them."
My response:
Because as soon as you start adding all sorts of metadata to a key, then everyone will start adding all sorts of metadata to keys, with all sorts of obscure rules about how metadata interact with the environment and various implementations whether a key works or not.
And then the lawyers will show up and insist that you imbed 30 page PDFs of Word docs of someone’s T&Cs and their contracts of adhesion and their “don't hold anyone with money responsible for anything” disclaimers into metadata (you think I joke, I do not at all, this literally regularly happens with “standards based” PKI certs).
And then your keys are going to be huge weirdly encoded binary blobs of shit that you don’t have good tools to manipulate. And you will need to keep special indexes of them, and “bundles” of them, in multiple conflicting filesystem paths and “key stores”.
Part of why SSH took off at all in the first is because it doesn’t have this complex garbage wankery . An SSH public key is a SINGLE LINE, of printable ASCII7. You can edit and clean up your ~/.ssh/authorized_keys file with a textmode text editor.
The lack of metadata in SSH is a feature, not a problem.
SSH is structurally different from TLS in a couple of ways, and I think put together they make a more compelling case than the argument against complexity (attractive though it is).
ReplyDelete1. No CAs. (At least, in the most familiar mode of operation.) Who would certify any metadata a private key holder wanted to supply?
2. Well-informed verifiers. In the common (web) setting for TLS the clients have neither the experience nor the information to do any kind of checks on key use (beyond very basic strength checks built into the software). In SSH in contrast the verifier may well only want to permit a keyholder to execute certain commands, want to restrict tunnelling etc - and indeed in OpenSSH these restrictions may be encoded in an authorized_keys file.
authorized_keys file don't currently contain key expiration dates (at least as of OpenSSH 6.9), but it should be fairly straightforward to add the feature if someone really wanted it, and I think in the context of SSH it would be the most appropriate place for them.