Robot CA at

Per Tunedal
Fri Dec 6 12:55:02 2002

At 16:25 2002-12-05 -0500, you wrote:
 >On Thu, Dec 05, 2002 at 03:00:07PM -0600, Kyle Hasselbacher wrote:
 >> >You know, now that I think about this some more, whether the key or
 >> >the sigs expire, people are going to have to get re-signed
 >> >periodically.  (Let's say 1 year for the sake of argument).  Given
 >> >that, it's not clear which is better:
 >> >
 >> >1) Expire the robot's key every year.
 >> >
 >> >2) Expire each signature the robot makes every year.
 >> >
 >> >3) Both (if you're planning on doing #1, there is no harm expiring the
 >> >   sigs at the same time).  No real benefit either though.
 >> >
 >> >#1 helps with the problem that the robot's key lives on a box
 >> >publically available on the net.  If that box gets cracked, then the
 >> >robot's key can be abused.  This helps put a limit on the amount of
 >> >abuse possible (though you should still keep a revocation certificate
 >> >and revoke the key if necessary).  The drawback is that everyone using
 >> >the system would need to get the new robot key each year.
 >> >
 >> >#2 is good since it simplifies what the end user needs to do -
 >> >specifically, they don't need to fetch a new key each key to verify
 >> >these signatures.
 >> >
 >> >Given that there must be a way to revoke and re-issue a robot's key
 >> >(for example, you've already had to do this once), I'm leaning towards
 >> >#1 or #3 now.  Of course, I pulled the "1 year" time period out of
 >> >thin air.
 >> I prefer #2, myself, maybe #3.  If the robot's key expires, suddenly all
 >> its users want to get resigned on the same day.  I'd rather they get their
 >> new sigs over a longer time period (i.e., the time it took them all to get
 >> them in the first place).  The robot's load continually increases as it
 >> handles old users as well as new, but it won't have a big "flag day" spike
 >> where the one key expired.
 >> If I were doing #3, I'd make the robot's key expire after a longer time.
 >> That is, sigs expire every four months (say), but the main key doesn't
 >> expire for two years.
 >That's an excellent idea.  If (for example) the 2002 key expired in
 >2004, and the 2003 key expired in 2005, then you can spread out the
 >load for user recertification.  It does mean that users will need more
 >than one robot key at a given time in their keyring though.  No real
 >harm, since this can eventually be handled automatically.

I agree.
Per Tunedal