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.ga26...@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-gro...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users