Adrian von Bidder
avbidder at fortytwo.ch
Thu Nov 27 10:22:45 CET 2003
On Thursday 27 November 2003 07:12, Atom 'Smasher' wrote:
> > It's not watertight. If I have both your secret key and your email
> > account, I can do all of this, and have in the end a trusted key to your
> > name where you don't have the secret key. Granted, I'll need coninued
> > access to your mail account, but in some circumstances this may be easy.
> if an attacker had both 1) access to person's email account and 2) that
> person's secret key, then, why would they need to raise suspicion by
> issuing a new key?
Because the owner of the old key does not have the secret key of the new key.
Depending on circumstances this might make a difference.
> another observation, is that a signed email [claiming to be] from bob
> my old key isn't good any more, here's my new key...
> (even though many of us would not trust it, at face value) really has just
> as much validity as a new sub-key (which most of us would trust, at face
> value) because both are signed by bob's signing key, which we trust (and
> may have certified to trust) belongs to bob.... social aspects aside, is
> there really a technical difference between trusting a new sub-key and
> trusting a signed email, like above? (i propose there is no difference)
There might be not a big difference between trusting a new subkey and trusting
a new key on the grounds of the above email. BUT (and it's the same argument
that came up in this thread already), it's a big difference between trusting
a new subkey for encrypting messages and *signing* a new key, which means
that other people then are going to trust that new key based on your belief.
All signatures on a key have a date - I think it is entierly plausible to
implement a trust model where older signatures have less impact on key trust.
Independently of the expiration date which is set by the signer, this would
be influenced only by the user of a public key.
featured product: the GNU Compiler Collection - http://gcc.gnu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 335 bytes
Url : /pipermail/attachments/20031127/ea433e3b/attachment.bin
More information about the Gnupg-users