[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: persistent identities
David & Angelos,
I'm replying to the full list...
- Carl
At 09:59 AM 2/27/97 -0500, David P. Kemp wrote:
>> Howdy.
>> I'm curious about why there was no reply on my first reply; anyway, if
>> i want to rekey (for key hygiene as you mentioned), i can always
>> delegate authority to my new key. When i first use the new
>> certificate, the server will give me back an autoCert and i can then
>> forget the old key. Something wrong that i don't see with this
>> approach ?
>> - -Angelos
>
>The purpose of key hygiene is to protect against unknown risk. If you
>know someone has stolen your key, you treat it as a compromise. But
>if you have been carrying it around on a laptop for a year, you may
>want to replace it even if there is no reason to believe it has been
>compromised. But to get the full benefit of replacing the key, you must
>assume that it *has* been compromised. Therefore you can't use it to
>bootstrap a new key, through delegation or any other mechanism.
Taking your argument to extreme, you could never certify one key with
another because the issuer's key might have been compromised.
In the real world, I have to assume that each key has a probability of
having been compromised. These probabilities are monotonically
non-decreasing with age. The rate of increase depends on how the key is
protected.
Assuming we knew these rates, we would still have to assign a probability
threshold at which we declare a key no longer secure enough for its purpose
(different threshold for different purposes).
The object is to issue a key delegation from a key which is still valid.
One can do that by specially protecting one key (the master key for me) and
generating ephemeral (exposed) keys from that one. You make the special key
very long in order to keep the insecurity rate from factoring small. You
keep the special key in a very secure place to keep the rate from theft small.
On the other hand, if you have a secure time service, you don't need a
protected master key. Instead, you can generate two keys at once, A and
B. Immediately generate the
<A,B,Inf,Member,V>
and include a time stamp on it (so that people know it was generated when A
was still good), then keep B in cold storage, protected from theft or
cryptanalysis (because the public key hasn't been revealed). When B and its
cert are removed from cold storage, you can generate key C and
<B,C,Inf,Member,V> and put C into cold storage before releasing B to the world.
To make that work, you'd need time-stamped records of important events in a
key's life: birth, generation of successor, initial release of public key,
placement of private key in environment X (whose physical protection is
described), .... We haven't bothered defining a format for such records.
- Carl