Revoke signature from key

[Daniel Kahn Gillmor]

On 03/21/2011 04:51 PM, Grant Olson wrote:
> On 03/21/2011 04:18 PM, Daniel Kahn Gillmor wrote:
>> If i was going to try to indicate more than a simple identity binding
>> with an OpenPGP signature, i'd define an OpenPGP notation [0] and
>> include the relevant subpacket in my signature.
>>
>> This way, the same signing key is capable of making identity
>> certifications *and* identity+metadata certifications.
> 
> But that doesn't provide any easy way for me to only trust your
> identity+metadata certifications, if, for example, I trust you to sign
> in your role for a company, but don't trust or care about your
> personally-issued sigs.

You are free to disregard any of my certifications you like.  It would
not be unreasonable of you to say "i will disregard all certifications
by dkg that lack a department at example.com notation." if that's what
you're trying to do.

> Instead of signing your key, I need to manually
> inspect any and all keys that may have your signature.

Why is this a manual process?  You would not be inspecting the keys --
you'd be inspecting my signatures, which you have to do anyway (at least
in order to cryptographically verify them).

I grant that GnuPG doesn't have a straightforward way to filter
certifications based on notation.  I think that's a missing feature,
though -- not necessarily a reason to create entirely new keys that will
themselves need to be integrated into the web of trust, and which have
entirely different semantics for their OpenPGP certifications.

Using a separate key for this scenario creates other problems with
GnuPG's existing WoT resolution mechanism as well.

For example, consider Bob an admin of the tech support dept. at Example
Corp.  Bob has his own personal key B, and manages a department key with
alternate certification semantics, D.

If Alice works for Example Corp, she might decide to set marginal
ownertrust on D to increase her WoT into the tech support department.
But if she knows Bob personally as well, she may want to grant marginal
ownertrust to B.

If Alice's trust model says "3 certifications by marginally ownertrusted
keys -> full key+userid validity" (the gpg default), then Bob's keys now
have the ability to provide 2/3 of a full certification instead of
Alice's expected 1/3.  If Bob also happens to manage the department key
for the Billing department of Example Corp, and Alice applies marginal
ownertrust to that, then Bob can forge key+userID combinations that will
be fully accepted by Alice, despite her having never granted him more
than marginal ownertrust.

In short: if your goal is to represent something in addition to identity
information in an OpenPGP certification, i think it's a good idea to
represent that metadata explicitly.  Notations are a reasonable way to
do that.  If GnuPG doesn't provide a reasonable way to solve your use
case, let's fix GnuPG to make it better.

Note that I am *not* actually recommending putting anything other than
identity information in an OpenPGP certification in most real-world use
cases.  There are significant drawbacks (e.g. surveillance by social
graph trawling) to representing non-identity metadata in certificates,
and the tradeoffs should be weighed carefully.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110321/7e874ecf/attachment.pgp>