Subject: rfc2440bis-02 comments

From: Marc Horowitz <[email-masked]>
Date: 08 Dec 2000 00:51:19 -0500

Many of these comments come from notes I took on rfc2440, so I may
have some section numbers wrong.  I did compare these notes to the
I-D, and I believe all of them are still relevant.

1. Section 5.2 is vague about how to compute signature types 0x30 and
   0x40.  The document should specify over what data to compute the
   hash to be signed.  There was also a comment in the list archives
   about the description of signature type 0x18, which says

	This signature is calculated directly on the subkey itself,
	not on any User ID or other packets.

   This is tremendously misleading, since the signature is actually
   computed on a hash over a prefix, the key packet, the subkey
   packet, and a trailer.  Section 5.2.4 gives a more detailed
   description of how to compute a subkey binding signature.

2. Section 5.2.4 contains another error.  It states

	Key revocation signatures (types 0x20 and 0x28) hash only the
	key being revoked.

   However, analysis of existing implementations indicates that this
   is incorrect for subkey revocation signatures (type 0x28); like
   type 0x18, both the primary key and the subkey are included in the
   hash.

3. Subpacket 23 (key server preferences) is specified to be "found
   only on a self-signature".  It should say if that means a direct
   key signature (which makes the most sense to me), or something
   else.

4. The document is vague on what constitures "advisory information" in
   a signature subpacket (section 5.2.3).  I believe that unhashed
   signature subpackets were a mistake (I can expound on this if
   people want).  If existing implementations did not include unsigned
   subpackets, I would suggest removing them from the spec entirely.
   However, current implementations usually include the issuer key id
   subpacket (type 16) in the unhashed subpackets.

   Therefore, I suggest that implementations MUST NOT generate any
   unhashed subpackets, SHOULD accept type 16 unsigned subpackets in
   order to process existing signatures, and MUST NOT accept any other
   subpacket types in the unhashed subpackets.

5. There should be a note that the critical bit MUST be ignored on
   unhashed signature subpackets.  Otherwise, an attacker can easily
   cause any signature to fail to verify.

6. The terms used in 11.1 are inconsistent with the rest of the
   document, and in some places, the rest of the document is also
   inconsistent.  Where 11.1 uses "revocation self signature", the
   rest of the document uses "key revocation signature".  Where 11.1
   uses "direct key self signature", the rest of the document uses
   "direct key signature", "direct-key signature", and "Signature
   directly on a key".  Where 11.1 uses
   "binding-signature-revocation", the rest of the document uses
   "subkey revocation signature".  Where 11.1 uses
   primary-key-binding-signature", the rest of the document uses
   "subkey binding signature".

                Marc

---

From: Werner Koch <[email-masked]>
Date: Fri, 8 Dec 2000 13:04:27 +0100

>    key signature (which makes the most sense to me), or something

As with many other subpackets there is no clear definition on what
to do and it is left to the implementor to decide this.  From my
understanding it does make sense to handle such things this way:

  * If it is on any direct key signature, use this one (or exactly
    the one on the latest direct key signure.

  * Otherwise take it from the latest self-signature.  

(I have worked out some more rules and checked them with Hal.
Currently I can't access them - please ask me next week, if you are
interested)

>    signature subpackets were a mistake (I can expound on this if

No, they make sense.  It may happen that you need to store some meta
information about a signature which you have to calculate after
signature creation. 

However, a big warning about unhashed stuff should be present.

>    cause any signature to fail to verify.

Does not make sense.  An attacker can make _any_ signature fail but
just flipping one bit.

  Werner

---

From: "L. Sassaman" <[email-masked]>
Date: Fri, 15 Dec 2000 03:11:03 -0800 (PST)

Marc mentioned 5.2.3.17 (Key server preferences) and that reminded me of a
suggestion I wanted to make.

One of the major complaints I hear about PGP key servers is the inability
to delete keys once they are sent to the server. I'd like to request the
addition of two new flags for subpacket 23:

    0x40 = Disabled
    the key holder requests that this key not be returned upon
    a search of the key server.

    0x60 = Enabled
    the key holder requests that this key be returned upon a
    search of the key server.

Keys bearing the disabled flag would either reside on the key server and
never be returned in a search (except perhaps to the administrator), or
they would be immediately deleted upon receipt by the key server.

(The reason for the enabled flag is to reverse the effects of the disabled
flag at a later date. And of course, if neither the disabled not the
enabled flags are set, keys are implicitly enabled.)

__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting

---

From: Dave Del Torto <[email-masked]>
Date: Fri, 15 Dec 2000 14:22:43 -0800

>they would be immediately deleted upon receipt by the key server.

Len,

I'm intrigued by your idea of "disabling" keys as a solution to this
problem. I think it could be a useful addition, even with the
questions it raises.

If the intent is to allow a Alice to effectively Remove her public
key -- even if the keyserver's policy/software doesn't allow her to
Delete it -- then I think this is useful. Of course, this presumes
that Alice still retains her ability to modify the public key.

However, if the intent is to "mask" the presence of Bob's key on the
keyserver in lieu of Deleting it, it's hard to see what sort of
keyserver response behaviour would prevent Eve from trying to
determine the presence of Bob's key on the server -- by deducing that
information using the very 0x40 flag you describe in conjunction with
the keyserver behaviour. This simply shifts the policy focus from the
pksd's delete policy to its search policy.

All Eve would need to do is upload the public component to the
keyserver in order to determine the status of the subpacket 23
enable/disable flags: if the key is present but disabled, it will
"vanish," confirming that it's disabled. If not present, it will be
returned by a subsequent search. A rudimentary traffic analysis
technique.

The big question of course, is "who can set these flags?" IMHO, they
musn't be outside the hashed subpackets: they need to be set by the
key-owner, lest they contribute to a DoS attack on any given public
key. This means that Alice or Bob could just as easily Revoke (or,
pksd policy permitting, Delete) their keypairs. If the keyserver
admmin is to be allowed to set the flag, this raises a serious key
management policy question, again just shifting the problem
elsewhere, but not solving it entirely.

    dave

---

From: "L. Sassaman" <[email-masked]>
Date: Fri, 15 Dec 2000 14:46:48 -0800 (PST)

> that Alice still retains her ability to modify the public key.

Of course.

> returned by a subsequent search. A rudimentary traffic analysis

Where is the threat here? The reason I prefer a "disable" approach to a
"delete" approach is that deleted keys can always reappear. The behavior
you describe seems to me to be the appropriate one.

> elsewhere, but not solving it entirely.

Right, no one, not even the key server admin, would be able to set these
flags besides the key owner. I didn't feel that needed stating, since
these flags are an addition to an existing subpacket which is already only
found in self-signatures.

They MUST NOT be placed outside the hashed area.

- --Len.

__

L. Sassaman

---

From: Dave Del Torto <[email-masked]>
Date: Fri, 15 Dec 2000 15:48:57 -0800

At 2:46 pm -0800 2000-12-15, L. Sassaman wrote:
>>However, if the intent is to "mask" the presence of Bob's key on
>>the keyserver in lieu of Deleting it, it's hard to see what sort of
>>determine the presence of Bob's key on the server -- by deducing
>>that information using the very 0x40 flag you describe in
>>conjunction with the keyserver behaviour. This simply shifts the
>>policy focus from the pksd's delete policy to its search policy.
>>
>Where is the threat here?

The threat, perhaps a theoretical one at this point in time, is
that if you're trying to mask the very existence of your key on
one or more keyservers (for example to thwart an improperly coercive
demand for keying material from rogue officials), you will not be able
to do so with these flags. You would only be able to do this by 
deleting them via an LDAPS (or similarly secure) keyserver connection.

BTW, the trail of evidence that Deletion would involve, reminds me of
another thread I wanted to raise (wearing my CryptoRights hat) with
the keyserver managers, regarding the need for standardized
mechanisms permitting secure, UNauthenticated, UNlogged connections
to keyservers. Deleting a key would still require a passphrase, but
it would permit one to clear a key if one was under threat.

>The reason I prefer a "disable" approach to a "delete" approach is
>that deleted keys can always reappear. The behavior you describe
>seems to me to be the appropriate one.

We can agree on that much. I guess I'm just applying a more stringent
threat model -- speculating that regimes like RIPA may someday soon
negatively impact the human rights of crypto users. I still like your
key-disable flag idea, Len.

    dave

---

From: "L. Sassaman" <[email-masked]>
Date: Fri, 15 Dec 2000 16:53:55 -0800 (PST)

> deleting them via an LDAPS (or similarly secure) keyserver connection.

Sure. That isn't the threat these flags were intended to solve. In fact, I
am not sure this threat you mention isn't an intractable problem; once a
key is deleted from the server, it can always be re-added by a third
party.

(Unless, of course, the no-modify flag is set. Then the owner of the key
would be required to authenticate himself prior to adding the key to the
server.)

> it would permit one to clear a key if one was under threat.

Hrmm. guaranteeing that connections are unlogged isn't really possible, I
don't think. Though if this became a really important issue, I suspect you
could set up some sort of key request system using the anonymous remailer
network... but that seems a bit extreme.

Rodney Thayer and I are working on an Internet Draft for key server
behavior. We'll try to cover all these issues in there, and will welcome
any comments on it when we publish.

(Key server issues are really beyond the scope of 2440. The only reason
I've brought this up now is that I would like to see these flags added so
we can utilize them in the key servers.)

Thanks for your comments,

- --Len.

__

L. Sassaman

---

From: Derek Atkins <[email-masked]>
Date: 17 Dec 2000 12:21:05 -0500

Unfortunately this particular approach will not solve what I believe
to be the bigger problem: "I reinstalled my machine and lost my secret
key; can you remove it from the keyserver, please?" or "I forgot my
passphrase, can you please delete my key from the keyservers?"  If I
had a dollar for every time I received one of these messages, I'd be a
very rich man right now ;)

The additional packets really don't help much more than being able to
revoke one's key.  If one could 'disable' a key themselves, they could
also revoke that same key.  The problem is that most of the requests
come from people who cannot modify their key (due to circumstances
that may or may not be out of their control).

If we're going to solve the "key disable" problem, we need to do so in
a manner that helps the user who lost their own key.  Otherwise the
solution really doesn't solve the real problems that exist today.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: [email-masked]
Date: Mon, 18 Dec 2000 14:42:52 +0900 (JST)

From: Derek Atkins <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Date: 17 Dec 2000 12:21:05 -0500

> very rich man right now ;)

is it possible to address this issue w/o the keyservers doing any sort
of authentication?  i had thought that there was a fairly strong
feeling that the keyservers should not do any sort of authentication.

has this changed?

one authentication-less way that occurred to me is to have keys have
life times on servers (default being 1 year perhaps?).  then, though
you might have to wait a while, at least your old keys could disappear
from servers after a certain period of time.  

your client software can remind you that you need to upload your key
when it gets close to the "expiration" date/time.

[ of course the "expire-from-server" date needs to be in the hashed area. ]

---

From: Dave Del Torto <[email-masked]>
Date: Mon, 18 Dec 2000 05:54:56 -0800

>from servers after a certain period of time.

I agree that the default should be one year. I've been calling for
this for a very long time, and I'm definitely not alone. There are so
many confused users out there on these key management points: I'm
beginning to wonder if the development community is really paying
attention to usability issues. PGP 7's Key Reconstruction is a very
nice idea, but I've tried to get some newbies to use it and their
reaction to being confronted by a dialog asking them to come up with
five questions in case they forgot their passphrase was "are you
kidding me?!"

Also consider the idea of keyservers employing "flushing routines"
for potentially "dead" keys. In one possible scenario, a key has
languished on a server (e.g. hasn't been accessed for n ticks) for
two years, has no expiration and is about to disappear as described
above. The keyserver could email it to all of the email addresses on
the key (this would encourage people to keep their userids current,
yet another extremely common key hygiene problem). If the key wasn't
updated by anyone within another time period (set by the admin), the
key would be dropped.

Storing your key on a public keyserver is a privilege, not a right.
If you can't do the most basic things to maintain it, you're not
doing anyone any good, least of all yourself if you want people to
use it.

>when it gets close to the "expiration" date/time.

It would make sense if *all* OpenPGP-compliant implementations had
some basic HCI features like this: a warning when one's key is about
to expire seems extremely obvious -- or even when signatures made by
one's key on others' keys (stored on one's local keyring) are about
to expire.

Jon, perhaps expiration packets can be mentioned in 2440bis as being
potential triggers for this mechanism. Implementors could also be
encouraged to consider providing expiration warning mechanisms.

    dave

---

From: Hironobu SUZUKI <[email-masked]>
Date: Wed, 27 Dec 2000 13:33:38 +0900

Hi, Marc.

> - I don't want my key on the keyservers at all.
>    
>   Your proposal solves this problem, but in my experience, this almost
>   never happens. 

2 years ago, I got a complain e-mail about adding public key by a
third party.  Then I thought multi-phase commit for keyserver.  But my
idea looks crypto-over-kill for our public keyserver.

 Step 1: User submit their public key to keyserver.

 Step 2: Keyserver save this public key in queue database.

 Step 3: keyserver returns "ticket (challenge random number)"
	 which is encrypted by user's public key.

 Step 4: After User decrypt received "ticket", user sign "ticket" by
	their secret key and send "signed ticket" to keyserver.
 
 Step 5: Keyserver check "signed ticket" by user's queued public
	 key. 

	 Ture -> move it to public-open database.

	 False -> delete from queue database.

  Note: When keyserver use this scheme, Sync data must be signed
	or something against forge sync data. 
	(Also adding MAC looks good).

This solution is not simple and powerful CPU is required for
keyserver. But I'm not sure that it is too much cost for keyserver.

Please note that this is only idea and I don't recommend it.

					--hironobu

---

From: Marc Horowitz <[email-masked]>
Date: 26 Dec 2000 22:36:38 -0500

Len, exactly what problem is you proposal intended to solve?  You
said:

Why do these people want to delete their keys?

- They lost the private key or forgot the passphrase.

  Like Derek, this is by far the most common reason I get email from
  people who want their keys deleted.  Your proposal doesn't solve
  this problem, since they can't modify the key to change the
  keyserver preferences.

- They don't want anybody to know they have a key.

  It doesn't solve this problem, either, as others have pointed out.

- The key is compromised.

  In this case, they should revoke it.

or is there another problem I've missed?

                Marc

---

From: [email-masked]
Date: Wed, 27 Dec 2000 14:02:58 +0900 (JST)

hello all,

From: Hironobu SUZUKI <[email-masked]>
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 13:33:38 +0900

> idea looks crypto-over-kill for our public keyserver.

[ detailed description of pk-based challenge-response scheme snipped ]

> Please note that this is only idea and I don't recommend it.

to add more hypothetical information to the situation...

if keyservers are going to do authentication-like things (a big "if"),
why not do the following:

  -before adding a key from the queue to a database, use an email confirmation
   system to solicit confirming email (don't need to use pk-based
   challenge-response for this) -- just use what many mailing list
   systems use.  if confirmation is obtained, add the key to the database.

  -in order to remove a key from the database, use a challenge-response 
   system like Hironobu described.

  -keys expire from servers by default.  perhaps 6 months or 1 year.

points to observe:

  -if deletions are relatively scarce events, you don't need much cpu
   power.  keyservers can even decide to only service delete requests
   periodically in bulk.

  -in the case that the confirmation by email process is "spoofed" and
   a third party adds someone's key, the holder of the secret key can remove
   the key using the above method.  i'm assuming the spoofing shouldn't
   be something that should continue to happen to a particular individual -- 
   if it does, imo, that person has other problems that need to deal with 
   first.

  -an "expire-from-server" time field (only allowed in the hashed area)
   could be defined in rfc 2440, support for this in keyservers and
   openpgp client implementations seems like one way to accomplish the
   expiration idea.

  -unused keys will be removed from servers over time.  less garbage is
   collected and people who lose their secret keys can relax after a while.
   new users can be encouraged to choose short "expire-from-server" times.
   i think it's important to be able to update one's "expire-from-server"
   time -- i don't understand how key information on keyservers gets
   updated (which key information takes priority?  always what gets submitted
   later in time?  if so, may be something like a "timestamp" field is 
   necessary in the hashed area so that a keyserver can decide which key info
   is more recent).

  -it's not required that keys have email address info associated w/ them.
   it's not clear to me whether one would bother w/ confirmation for these.

thoughts?

---

From: [email-masked]
Date: Wed, 27 Dec 2000 15:02:15 +0900 (JST)

From: Hironobu SUZUKI <[email-masked]>
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 14:41:13 +0900

> Removing from keyserver is bad idea. After public key was issued,
> there are two status for public keys which are "Valid" or "Not-Valid"
> (removked).

[ example snipped ]

i don't think the example in question should dictate everyone's
policy.

if it really is the case that in step 1 alice distributes her public
key to the world for verifying her signed text by everyone, that is
her policy decision and she has to figure out a way to make that work
-- assuming that the mechanisms exist, she can express that in her key
info by setting an expire time significantly in the future and perhaps
some other field that expresses the idea that she cannot go back on
her word.

other people may not want that kind of policy.  i know i don't for
every key i make.

---

From: Hironobu SUZUKI <[email-masked]>
Date: Wed, 27 Dec 2000 14:41:13 +0900

Alice, Bob and Olive story.

 Step 1: Alice distribute her public key to the world for verifying
	her signed text by everyone.

 Step 2: Alice sign text and distribute signed text to the world.

 Step 3: Bob get Alice's public key and verify Alice's signed text.
         Bob is certain that this text was written by Alice.

 Step 4: Alice remove her public key from all of the world.

 Step 5: Olive get Alice's signed text. But she can't get Alice's 
	 public key and can't verify Alice's signed text.
	 Olive is not certain that this text was written by Alice.

 Step 6: Bob says "this is Alice's text", Olive says "I'm not sure 
	 this is Alice's text".

This is a kind of chaos. 
					--hironobu

---

From: Hironobu SUZUKI <[email-masked]>
Date: Wed, 27 Dec 2000 15:50:44 +0900

> i don't think the example in question should dictate everyone's

Alice, Bob and Olive story may be vulnerability of public key
distribution and verification, is not sort of policy.

If you mention about privacy, I mean hiding personal information,
PGP's (simple) digital signature scheme is not enough to solve it.
You might need blind signature, undeniable signature, non-transitive
or other digital signature scheme.
						--hironobu

---

From: [email-masked]
Date: Thu, 28 Dec 2000 11:21:56 +0900 (JST)

From: Hironobu SUZUKI <[email-masked]>
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 15:50:44 +0900

...

> distribution and verification, is not sort of policy.

i'm sorry, but i wasn't able to understand what you meant.

my guess is that you are saying that addressing the example scenario
you gave is a design goal of public key distribution and verification.

is that what you meant?  if not, please elaborate.

i don't think the current keyserver structure alone addresses the
scenario you gave.  you also need to establish that a particular key
belongs to a particular entity -- this is not possible using only the
keyservers -- you need to perform at least one key fingerprint
verification and depending on the situation, you may also need a trail
of appropriate signatures to the entity's key.  

in your example scenario:

  in step 3, bob is not certain that the text was written by alice
  until he verifies that the key is hers.  he can do that via
  contacting alice, or if an appropriate chain of signatures exist,
  he can do it via that method (it depends on his policy).  once bob
  has verified the relationship between alice and the key he downloaded,
  then he can be certain (actually he can be certain w/o this, but he 
  will be foolish for being certain ;-) )

  in step 5, it is true that olive can't verify alice's text because
  she doesn't have alice's public key.  but having a key from the
  keyserver that might be alice's key is not enough.  olive must also
  establish that the key is alice's.

so to summarize, verifying signed text is going to require verifying
entity-key associations.  that's going to require communication
between entities.  imo, this communication should clear up
difficulties in most cases.

i think there will be pathological cases where verification of
signatures will not be possible.  

in fact, the current situation does provide examples of such
situations -- for example, there are already keys on the keyservers
for which no one can establish relationships to owning entities:

  any key that no one has done a fingerprint verification for and the 
  secret key material is lost

if there is some text signed w/ such a key floating out there, no one
will be able to verify the signature.  even if one person has
performed a key fingerprint verification for the key, if no one else
trusts this person as a verifying entity, no one else will be able to
verify the signature.

imo, those kinds of pathelogical situations need to manage their risks
using additional means.

---

From: Hironobu SUZUKI <[email-masked]>
Date: Thu, 28 Dec 2000 13:24:02 +0900

> you gave is a design goal of public key distribution and verification.

I meant that PGP's conventional (simple, oldstyle, or whatever :-)
digital signature can use in very simple digital signature scheme.  My
scenario will be applied to not only PGP but also almost current
digital signature tools.

I guess that you want more sophisticated digital signature scheme than
current PGP digital signature scheme.

> but having a key from the keyserver that might be alice's
> key is not enough.  olive must also establish that the key is alice's.

Web-of-trust, X.509, and some certification schemes give us the
capability of public key trustness without contacting public-key
owner.

					--hironobu

---

From: [email-masked]
Date: Thu, 28 Dec 2000 17:53:15 +0900 (JST)

i am about to give up...i think we're going off-topic.  perhaps we
should continue this off-list.  the points i wish to make are:

  -expiring keys from keyservers is not necessarily a bad idea -- at least 
   your example does not convince me that we would be significantly worse
   off than the current situation.  i like Dave Del Torto's statement:

  -out-of-band channels for verification are necessary for using these
   kinds of systems well -- keyservers can help reduce the total amount of 
   out-of-band verification, but it is not a substitute on its own.
   (both web-of-trust and x.509 require at least some out-of-band verification
   at some point)

---

From: [email-masked]
Date: Fri, 29 Dec 2000 10:34:49 +0900 (JST)

From: Marc Horowitz <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Date: 26 Dec 2000 22:36:38 -0500

> Why do these people want to delete their keys?

[ text of various reasons deleted ]

> - I don't want my key on the keyservers at all.

for reference, below is part of an edited recent post from the
[email-masked] mailing list of someone who doesn't want their
key on a keyserver at all.

perhaps a survey announced on the various user-oriented pgp lists
would be useful for collecting feedback on the issue of deleting keys
from keyservers?

Subject: Re: Deleting Keys on Keyservers
From: Lazarus Long [address deleted]
To: GnuPG Users List <[email-masked]>
Date: Thu, 28 Dec 2000 15:50:23 +0000

On Wed, Dec 27, 2000 at 09:49:55PM +0100, Martin wrote:
 > From: Martin [address deleted]
  
 > im just curious. Is there a way to delete a key from a keyserver?

Nope.  Once your key is there, you are hanging out there in the wind for
spambots to come harvest for all eternity.

---

From: Frank Tobin <[email-masked]>
Date: Thu, 28 Dec 2000 20:33:12 -0600 (CST)

[email-masked], at 10:34 +0900 on Fri, 29 Dec 2000, wrote:

Of course, in the future, people's needs are going to change.  They're
going to want new policies about how keyservers (and other entities)
handle their keys, and have other metadata associated with them.  To try
to "guess" what people are going to really need or want two years from now
is a reach at best.  If there is no attempt to use an extensible format
that accounts for the many different key-handling policies and metadata
that different people/entities are going to want to use, evil, bad hacks
are going to start occuring eventually.

One of the problems, I feel, is that we're trying to jam too much into the
few bits available in the OpenPGP spec.  Simple boolean's just don't cut
it.

This is me dreaming here, but what'd really be good is to have the
metadata for keys separated out from the OpenPGP spec, and handled by
another, extensible mechanism, quite possibly/preferably XML.  This could
allow the metadata to be extended via namespaces by however one wishes.
There is no tie-down by specification mandating what policies can be
accomodated.  OpenPGP need not know about this extensible spec, since it's
pretty much finalized, but clients could adapt, and handle the specs in
pair.

In the end, I forsee troubles for OpenPGP if we try to quantify what
policies OpenPGP keys should be capable of holding metadata about.

- -- 
Frank Tobin		http://www.uiuc.edu/~ftobin/