[cryptography] someone should make openssh keys expire

ianG 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 mailing list