Re: draft-ietf-openpgp-rfc2440bis-06.txt

[Derek Atkins <[e-mail]>]

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
Alice.

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.

-derek

Bodo Moeller <[e-mail]> 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 <[e-mail]>
> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
> * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
> * Tel. [phone], Fax [phone]

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com