protecting pub-keys from unwanted signatures

[Stefan Claas]

On Sun, Aug 16, 2015 at 12:15:03PM +0100, MFPA wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi
> 
> 
> On Sunday 16 August 2015 at 9:10:28 AM, in
> <mid:20150816081028.GA26761 at zwiebelfreund.de>, Stefan Claas wrote:
> 
> 
> 
> > after seeing Facebook's public key a couple of days
> > ago, i was wondering if it's possible to enhance GnuPG
> > in a future version, so that it no longer allows
> > someone to sign a public key without approval of the
> > owner.
> 
> If GnuPG were modified in this way the key could still be signed
> using an old GnuPG version, or any other OpenPGP application.
> 
> I guess a modification would be possible that allowed a GnuPG user to
> sign acceptance or rejection over a third-party signature, but I'm not
> convinced there would be any point. Firstly, would such acceptance or
> rejection be dropped by the keyservers? Secondly, any signature on a
> key is only meaningful if you recognise (or have a trust path to) the
> key that made that signature; the rest is meaningless background noise
> that disappears if you use "keyserver-options import-clean" in your
> gpg.conf or on your command line. (My local copy of Facebook's public
> key has only self-signatures, and refreshing from a keyserver does not
> change this).
> 
> 
> 
> > As an example: Bob likes to sign Alice's pub key and
> > issues the sign key command, but instead of signing the
> > key directly GnuPG would create a "Signature Reguest
> > Certificate" which Alice reads and verifies in GnuPG,
> > thus allowing her to add Bob's signature to her key.
> > This mechanism, or a similar one would  protect Alice's
> > key from unwanted signatures.
> 
> Or Alice could simply host a "clean" copy of her key without the
> unwanted signatures on her website, Biglumber, an email
> auto-responder, etc.
> 
> 
> - --
> Best regards
> 
> MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>
> 
> The One with The Answer is seldom asked The Question
> -----BEGIN PGP SIGNATURE-----
> 
> iQF8BAEBCgBmBQJV0HDFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
> QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwP50H/1rj+rZoRbM7EIFht89O+G8t
> 4UdpvX3f8V73bJYW7CW288++QFqsLrJse2IsP6exK44ZUorR08MMSdn+5DSgiSGo
> J5W3HgMQxM/jQZ25bDp1jLExfEtgKfGpXWPONPLP/CVe+iZpu44cTbsjA5dfYXwx
> TSuyHD9t4auRzShHIDunPJWNqdt/WA5XGoGYZGIsICZG5lfHUBHUyrNXv3m/q/d0
> DjmelfMUpecNZ3coRhizP33tpet3mCSN1GEie9CPEWzk8aig1j5rhd/eBCVsvq0Y
> QVW7xJl+X7Esc0s8MeNnxbHshDco3TffRnSJFkSlKu992I61jg/O5e9d9IcS7FqI
> vgQBFgoAZgUCVdBwz18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
> cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
> MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KBkAQDbT5Wo/zN+jhL5sNYRth+4QAm6
> D7gUb7mAdvkpUqlUuAEA6D6968t1Nm6iTWgVyxcVDaXO1sH4ZkWdPy2FhTI25Ak=
> =LenD
> -----END PGP SIGNATURE-----

Thanks for your reply, all valid points.
However if my proposal would result in an enhanced OpenPGP file
format older versions could not sign such keys, while a never version
could read older or leagcy file formats. Same as with other software
applications. Current key servers would not be able to read/store
such enhanced format and needed to be updated too.

Regards
Stefan