[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Before you go putting words in my mouth...
There are two opposing forces here. On the one had I want to be able
to continue using my key indefinitely (re-keying is a PitA). On the
other hand, if it gets compromised I want to kill it (and make sure
the attacker cannot un-kill it). The third case is where the user
loses their private key.
To make all three of these work, I agree with Jon that you need to
separate out the "this key is alive" from "this key is dead". The
"Keepalives" are self-signatures with limited lifetimes. I don't mind
re-signing my own key every year (or whatever period I want to
re-assert myself). Note that this time period should not affect the
time period with which Alice asserts my key -- Alice should decide how
often they want to re-verify my key, I shouldn't dictate that to
The "this key is dead" is necessarily a revocation. If you go under
the assumption that data can only be added to a key and never removed,
then once you see a revocation anything else doesn't matter. If the
attacker controls the keyserver and can remove revocations then
obviously this doesn't work, but I don't think an attacker can control
that many data points.
All I except from the system is that an attacker who gains access to
your private key cannot make it live longer than YOU want it to.
Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> As I pointed out, you can use *self-signature* expiration (subpacket
> type 3) for many purposes, and use *key* expiration (subpacket type 9)
> for cases where you really want the key to expire in the sense that
> Derek and others expect key expiration to work (namely such that the
> bad guy cannot unexpire the key). What speaks against this?
> For version 3 keys, key expiration carries over into certifications,
> and many users expect similar security properties for version 4 keys.
> Notably, even Derek expected this, and still you refuse to even
> mention this bug/feature/misunderstanding in the Security
> Considerations of the specification.
> > Lastly, I claim that if you want to kill a key,
> > there is a mechanism for that -- revocation. [...]
> > Expiration is not revocation. Do not expect it to solve the problem of
> > revocation. Likewise, revocation is not expiration. Revocation is
> > irrevocable. Expiration can be undone. This is the design of the language of
> > the system. The present behavior is in my opinion the correct and desirable
> > one.
> I already commented on this:
> < Compared with key expiry (and I mean final expiry that cannot simply
> < be undone by anyone who has gotten hold of the secret key), revocation
> < is somewhat of a kludge. In some situations it is the best you can
> < do, but the problem is that the semantics is not monotonous. This may
> < be fun for AI people, but security folks should be worried about the
> < ramifications of denial of service attacks (nothing guarantees that
> < the revocation reaches everyone who should know about it).
> If it's not clear what I mean with this I should probably formalize
> the concepts and write a paper about the issue unless someone has
> already done something like that. Some keywords: formal proof
> systems, default logic.
> You say "revocation is irrevocable". This is true in a sense, but
> revocation is not as reliable as expiration that cannot be undone.
> You say "expiration can be undone", but we also need some kind of
> expiration that cannot be undone. OpenPGP distinguishes between key
> expiration and signature expiration, so we can use key expiration if
> we want expiration that cannot be undone, and self-signature
> expiration if we want expiration that can be undone.
> A signing key has become invalid in the fullest sense only if you can
> publish the corresponding secret key without causing any problems.
> PKIs should offer entities a way to state that their keys are to be
> considered invalid after some specific point of time. Revocation does
> not do this job very well because revocation packets may be
> suppressed, so the invalidity date must be covered by the
> certifications instead.
> Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
> * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
> * Tel. +49-6151-16-6628, Fax +49-6151-16-6036
Computer and Internet Security Consultant