Subject: 5.2.3.16. Key server preferences

From: "L. Sassaman" <[email-masked]>
Date: Tue, 4 Apr 2000 23:02:51 -0700 (PDT)

Hi folks,

While reading over the description of the Key server preferences signature
subpacket (5.2.3.17 in the current draft), a possible abuse of this option
occurred to me. I would like to suggest that the wording in the draft be
modified to say:

"When valid revocations of signatures made on a key are submitted to a key
server, implementations that honor subpacket 23 MUST allow the signature to
be revoked, regardless of the value of this packet"

Or something to that effect... the reasons here are obvious.

- --Len.

__

L. Sassaman

System Administrator                |  "All of the chaos
Technology Consultant               |   Makes perfect sense..."
icq.. 10735603                      |
pgp.. finger://ns.quickie.net/rabbi |              --Joe Diffie

---

From: Jon Callas <[email-masked]>
Date: Wed, 5 Apr 2000 00:07:17 -0700

>Or something to that effect... the reasons here are obvious.

What are the obvious reasons? And what's the obvious abuse?

The purpose of this packet is so that a key can say, "Here's where you can
get the most up-to-date version of me." Or perhaps if you prefer, the key's
owner is saying "here's where you can get the most up-to-date version of
this key." There are other reasonable uses, like including it in a
signature so you can find the key that signed it. Like all signed
statements, you shouldn't automatically treat them like gospel -- remember,
any idiot can sign anything. But that's the abuse?

	Jon

---

From: "L. Sassaman" <[email-masked]>
Date: Wed, 5 Apr 2000 00:43:51 -0700 (PDT)

> get the most up-to-date version of me." Or perhaps if you prefer, the key's

No, that's what "5.2.3.18.Preferred key server" (in the current
draft; 5.2.3.17 in the RFC) is for.

What I am talking about is subpacket 23:

5.2.3.17. Key server preferences

   (N octets of flags)

   This is a list of flags that indicate preferences that the key
   holder has about how the key is handled on a key server. All
   undefined flags MUST be zero.

   First octet: 0x80 = No-modify
       the key holder requests that this key only be modified or
       updated by the key holder or an administrator of the key server.

   This is found only on a self-signature.

- --

If I wish to revoke a signature on a key, I am doing so because I no
longer trust that key. There could be cases where the owner of the key
does not wish me to revoke said signature. I should still be able to
revoke it; in this case the wishes of the signer outweigh the wishes of
the key owner, in my opinion. If someone has set me as a trusted
introducer, I would not want them to treat keys on which I have revoked my
signature as valid. That would defeat the point of the revocation (since
the revocation would not be present without consent of the key owner, in
the current draft).

- --Len.

__

L. Sassaman

---

From: Werner Koch <[email-masked]>
Date: Wed, 5 Apr 2000 16:45:21 +0200

> revoke it; in this case the wishes of the signer outweigh the wishes of

Good point.  We should allow for this but I don't see a reason to
change the specs.  The keyserver admin can do this (using automated
tools of course).

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel   +49 211 465357
Birkenstr. 12                           email [email-masked]
D-40233 Düsseldorf                      http://www.openit.de

---

From: "L. Sassaman" <[email-masked]>
Date: Wed, 5 Apr 2000 15:41:49 -0700 (PDT)

> change the specs.  The keyserver admin can do this (using automated

Actually, Werner, that thought occured to me about 20 minutes after I sent
in the post. Technically any automated action by the keyserver would be an
action performed by the keyserver admin, so retaining signature
revocations would not violate the RFC.

- --Len.

__

L. Sassaman