2 noob problems

Neil Williams linux at codehelp.co.uk
Sat May 21 21:32:34 CEST 2005

On Saturday 21 May 2005 4:53 pm, Alex L. Mauer wrote:
> Yep, I understand the purposes of key signatures.  But (unlike with your
>   bag/tie analogy), two signatures from the same key don't make a key
> twice as valid.

If the signature expired, the new signature is needed. However, the *expired* 
signature is still useful too as it tells others that the key was also valid 
at the earlier date. Often, an expired signature only exists because the key 
originally had an expiry date.

Self-signatures are the only ones that are repeated on a key without an 

> If only the most recent one is kept, that should be 
> sufficient.  If you add a new uid, only that uid needs to be signed,
> there's no need to add another signature to all of them.

That leaves the new UID dangling - it's not "tied" into the rest of the key in 
the same way as all the other UID's.

> > If you're thinking of the other signatures, consider that people spend a
> > lot of time and travel large distances to gain signatures on their keys -
> > why should that be wiped out arbitrarily?
> Because it's redundant.  If I have two signatures on my key from
> someone, either one of them is equally valid.  No need to keep two.

I don't see how you would get two signatures from someone else on any one key, 
except because of an expiry. If I try to sign any key that I've already 
signed, I get an error.

> > Even if the key that made the signature is out of use, the signature
> > itself is still valid - it testifies that the owner of the key was
> > verified on the date shown by the person named in the signing key.
> Yep, and I'm not proposing discarding arbitrary signatures.  But if
> there's two signatures from a key, regardless of whether it's out of
> use, you don't need to keep them both.  Does it testify that the owner
> of the key was verified once, and then again on another date?  If so,
> what reason is there to keep both signatures?  If I sign a contract,
> does signing it twice make it more valid/enforcable/something?

No, but signing it one year and then signing it the next year does indicate 
that the contract runs over both years. It's a bad analogy because a key 
signature is a single point in time, a contract is generally intended to run 
over a period of time.

> On the other hand, if the signature has expired, since it becomes
> meaningless there's no reason to keep it.

It's not meaningless - it still means that the key in question was verified by 
the signer on that date. The expiry of that signature is separate. It is a 
snapshot - a single point in time.

> Look at the PGP Global 
> Directory key for an example of where this could become a problem.

Simple answer there is that the GD is a bad design and nobody is forced to use 
it. That argument was played out on this list when GD was launched. 

> It 
> re-signs the keys every two weeks, with a signature that is valid for
> two weeks.  This builds up pretty quickly.

Then don't allow your keys onto the GD. Simple.

It also means that the GD will ultimately fail to be global - it's 
subkeys.pgp.net that is most likely to be termed a global keyserver as it 
handles all keys without breaking them, like the older ones, and without 
allowing / encouraging other keys *not* to use it, like the GD.

> > Why is a new signature (of either type) more important than an old one?
> It's not, but defining a specific behaviour is generally a good idea
> when talking about how computers should behave.

Of course, I'm well used to writing and rationalising API's / ABI's.

> Defining this would 
> tell the keyservers what to do when syncronising, which I've heard as
> the reason it retains all keys+sigs forever.

I don't see that this is actually much of a problem. So it adds a few bytes to 
a public key - is that REALLY such a problem? 


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050521/2b3955d9/attachment.pgp

More information about the Gnupg-users mailing list