jerome at jeromebaum
Jan 3, 2012, 5:10 AM
Post #4 of 9
(194 views)
Permalink
|
|
Re: Question regarding unknown certificates
[In reply to]
|
|
On 2012-01-03 10:59, Werner Koch wrote:
> I will keep them in the file because these certificates are useful in
> the "chain" validation model. Usually we use the "shell" model where
> expiration dates have an obvious meaning. For German qualified
> signatures the "chain" model is required. Basically, it compares the
> expiration date to the date given in the signatures.
I lack the experience to understand how the chain model makes any sense
at all. Would anyone care to elaborate?
In my understanding, a signing key can be set to expire to help prevent
unauthorized use. AFAIK there is no other use in expiring a signing key.
The situation is different with an encryption key but let's focus on
signing keys because that's what CA keys are. So we need only worry
about abuse.
Now say I'm a CA and my key is set to expire in 4 weeks. I now make a
certification on another key that is set to expire in a year. Now look 5
weeks into the future, my key is stolen. At this point, in the shell
model, the key is useless to an attacker -- the point in expiring my key
in the first place. But in the chain model, the attacker can just
back-date any certification.
To protect against this in the chain model, we need qualified
timestamps. To protect against this in the shell model, we only need
common sense -- I'm pretty sure nobody here emailed a reply to this very
message a few weeks ago. Time only moves forward.
I do see that we can use qualified timestamps for this. But then the
timestamp either needs to be renewed on a regular basis, or the key that
signs the timestamp needs to have a long expiration date. If I renew the
timestamp regularly, why not just renew the certification directly? If
the timestamping key has a long expiration date, all else being equal,
it is more vulnerable than the CA key.
So we need to make up for that by protecting the timestamping key more
carefully. But we need at least as many timestamps as we need CA
certifications. Therefore the timestamping key must be as readily
available as the CA keys. To make it more well-protected, we therefore
need a higher investment, resulting in higher fees. These higher fees,
at least by proxy, now apply to CA certifications as well. We might as
well have directly protected the CA keys more carefully.
What have we gained compared to the shell model? What did I miss?
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
--
nameserver 217.79.186.148
nameserver 178.63.26.172
http://opennicproject.org/
--
No situation is so dire that panic cannot make it worse.
|
signature.asc
