[cryptography] someone should make openssh keys expire
iang at iang.org
Tue Apr 9 06:57:21 EDT 2013
On 9/04/13 03:48 AM, travis+ml-rbcryptography at subspacefield.org wrote:
> Just saying...
> They have signatures now, but there's no way to effectively audit them or expire them.
The question is, why? If you can answer that effectively, then you
might be right.
Let me put these stumbling blocks in your way.
Firstly, signatures, if they are to be last over time, have to protect
or mean something. In an ephemeral protocol, they protect a secret
until it is thrown away, seconds or hours, no more explanation needed.
In the other extreme, a long term digital signing protocol, they protect
a really big public statement over years. So, your idea might have
merit. But even there, a successful signing protocol always leans on
immediate escrow of the signature and keys. Aka timestamping. No
expiry needed, then, but there is a lot of load put on revocation.
Let's look more closely at the application: SSH does ephemeral key
protection, not anything more serious. It is used by sysadms on their
own machines, generally. It's their value at risk, and they are in
control. They can audit keys by looking at them, both ends, and the
entire cycle is under their control. They can expire them by generating
new keys, and afaik, most sysadms do roll over their keys from time to
time. It's really easy, one command to create. No money, no time
required, except the scripting to promulgate.
If you look at say where they do use audit & expiry, the CA business,
you'll find other circumstances: The users' value is entirely at risk,
they are liable for everything, for which privilege they pay a fee. Yet
the CAs are entirely in control, with no value at risk, for which they
charge a fee. The jurisdictions are multiple: users, vendors, CAs,
server vendors, server users, and committees, all with particular
interests. Money and time are significant. Even the signatures mean
different things: code-signing != SSL signing != client-login !=
One thing should be clear: just because the CA business does X, doesn't
mean that anyone else should.
More information about the cryptography