Subject: Re: Revocability semantics

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 17 Jan 2008 14:49:10 +0100

Dear WG,

I am pretty sure that my interpretation of the standard is correct, but I
would like to
a) have it confirmed and
b) make it known to other implementers

The Revoacble flag as specified by RFC4880, Section 5.2.3.12, when set to 0,
only forbids revocation by the issuer, but not by other revokers.

In particular, if a revocation key (5.2.3.15) is present in addition to the
above flag, it means that the designated revoker is allowed to revoke the
certificate, but the issuer is not.

The context is the implementation of IOU notes as self-signatures on PGP
public keys, so that the PKS infrastructure can be used for their
dissemination (and, thus, for credit reputation tracking). More on this at
the upcoming FC2008, in Cozumel. ;-)

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Fri, 18 Jan 2008 15:27:29 -0500

> certificate, but the issuer is not.

Unless I misunderstand what you are suggesting, I think my reading of
the standard says otherwise.  Specifically, if the revocable flag is
set to 'no', that means nobody (be they the issuer or designated
revoker) can revoke.

Take this scenario: Alice has a key and sets Baker and Charlie as
designated revokers.  If revokers other than the issuer were allowed
to revoke signatures marked as irrevocable, then Baker could revoke
Charlie's designated revoker status.  For that matter, Baker could
revoke his *own* designated revoker status.

David

---

From: Jon Callas <[email-masked]>
Date: Fri, 18 Jan 2008 14:44:47 -0800

> the upcoming FC2008, in Cozumel. ;-)

I think you're splitting hairs in a delightful way.

David Shaw describes the way I always considered it. Non-revocable was  
always supposed to be non-revocable. However, as I've said many times,  
OpenPGP is far more syntactic than semantic.

On the other hand, if you're building some private system where you  
implement those semantics, and genuinely don't care if (e.g.) my  
product doesn't agree with those semantics, then go right ahead.

	Jon

---

From: David Shaw <[email-masked]>
Date: Fri, 18 Jan 2008 20:28:17 -0500

> OpenPGP is far more syntactic than semantic.

Designated revokers have always seemed a bit messy to me.  The spec
allows for things like Alice revoking signatures issued by Baker on
Charlie's key (Alice being Baker's designated revoker).  In practice,
nobody has ever actually implemented that.  All implementations that I
know of allow Alice to revoke Baker's key and that's it.

If we go down that path, I'd rather see Daniel's desired semantics
implemented using notations or new subpackets, rather than add further
meaning to designated revokers and the non-revocable tag.

Actually, I'd go even further and suggest at some point in the future
(hey - a WG item!) we split the current notion of designated revokers
in pieces.  Users can grant the designated revoker exactly what powers
(or combination thereof) they choose to.  One ability is to revoke
signatures.  Another is to revoke keys.

Note that I'm not against the "designed revoker revoking signatures"
concept.  I just don't want the "you can revoke my signatures" ability
inextricably tied to the "you can revoke my key" ability.  They're
really not the same.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 19 Jan 2008 08:57:52 +0100

I did some more thinking over the issue of revocations and looked into the
source code of GPG to see what it does.

For one thing, key-uid and key-attribute binding revocations are exactly
identical to certifications, except for the signature type (0x30 instead of
0x10..0x13). It does not revoke any particular certification sig., but the
binding itself, like a negative assertion: "I certify that this
uid/attribute DOES NOT belong to the owner of this key".

David seems to be right about the fact that currently, there is no
distinction between key-revokers and certification revokers. However, since
this functionality is not it wide use yet, I would suggest to make the
following somewhat backwards-compatible change: The revocation key subpacket
authorizes revocations only for the subject of the certificate in which it
has been included. Thus, if it is a certificate directly on a key, it allows
the designated revoker to revoke the key. If it is in a key-uid binding
certificate, it allows the designated revoker to revoke that particular
key-uid binding. Alternatively, we could add a new subpacket type with this
semantics, and leave 5.2.3.15 as it is.

As for the revocability bit (as defined in 5.2.3.12), it only refers to the
author of the certification, being a committment by the signer. The standard
seems to be pretty clear about that. Its wording, however, makes one wonder 
HOW signatures can be revoked, since the rest of the standard talks only
about revocations of keys and key-attribute/key-uid bindings, but not
signatures as such. I'd think, it merits some more discussion.

As for my own itch, I am increasingly confident that I will implement IOU
notes as attributes, much like photo IDs.

Regards,

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Sat, 19 Jan 2008 11:45:07 -0500

On Jan 19, 2008, at 2:57 AM, Daniel A. Nagy wrote:

> key-uid binding.

I would be okay with this.  Putting the designated revoker subpacket  
in the certificate to indicate that it may be designated-revoked quite  
neatly gives the issuer the power to choose, which is what I was  
concerned about earlier.

> Alternatively, we could add a new subpacket type with this

Obviously, I'm okay with that as well.

A mild benefit for plan "A" is a great deal of flexibility, as the  
issuer could choose on a per-certificate basis which should be  
designated-revokable or not.  It would tend to make certificates a bit  
larger, though, as they'd have to carry a designated-revoker subpacket.

David