Robot CA at toehold.com
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.