Subject: Question regarding 2440:5.2.3.16

From: "L. Sassaman" <[email-masked]>
Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT)

Would anyone like to make a suggestion for a standard HTTP mechanism for
doing signed key adds to keyservers?

In order for keyservers to take advantage of 2440:5.2.3.16, there must be
a way to authenticate the user submitting the add as being the owner of
the key.

This can be done quite easily using an LDAPS connection, but since most
keyservers do not support such a connection, and some clients do not
either, I think there should be a standard data format for submitting
signed add requests to "HKP" keyservers.

Werner Koch and I have been discussing this, and he suggests that we put
it into a clear-text signature packet. Would that be suitable? 

- --Len.

__

L. Sassaman

System Administrator                |  
Technology Consultant               |  "Credo quia absurdum."
icq.. 10735603                      |  
pgp.. finger://ns.quickie.net/rabbi |          --Tertullian

---

From: [email-masked]
Date: Mon, 10 Jul 2000 12:37:46 +0900

From: "L. Sassaman" <[email-masked]>
Subject: Question regarding 2440:5.2.3.16
Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT)
Message-ID: <[email-masked]>

> a way to authenticate the user submitting the add as being the owner of

so you are suggesting that proof of ownership of the corresponding
secret key (via an appropriate signature) should server this purpose,
right?

> it into a clear-text signature packet. Would that be suitable? 

would you mind briefly describing the steps involved for the mechanism
you are considering (in terms like "first, the client connects to the
server.  then the server responds w/..." etc.)?  

[ i understand what you are saying about the form a signature would
take, but i don't see the overall flow of the process of
authentication. ]

also, is it necessary to consider replay attacks for this kind of
scenario?  alternatively, would the following scenario be of any concern:

  an attacker captures a session between a user and a keyserver at some
  point in time.  later, after the user has made several updates to the
  keyserver, the attacker replays the captured session to set the
  state of the user's key to an earlier state.

---

From: "L. Sassaman" <[email-masked]>
Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT)

> secret key (via an appropriate signature) should server this purpose,

Yes, because the owner needs to prove he has the secret key, and the
public key block that is to be added must be signed to prevent
unauthorized signatures being added during this process.

> take, but i don't see the overall flow of the process of

The client takes the public key block, signs it, and submits this signed
blob to the server. The server then verifies the signature, trims away
that signature, and adds the key.

Keys that are added unsigned should always be checked for the existance of
the "no-modify" flag, and rejected if it exists.

Furthermore, I suggest that we have a "modify" flag added to the spec, so
that, if a signature is made at a later date containing this flag, it
would superceed a preveous no-modify. But that digresses from this
discussion. 

>   state of the user's key to an earlier state.

This scenerio is only partially valid. A signed key that is added to a
server does not remove the previous key and replace it with the new
one. It is treated like and other add, and is merged with the existing
key. So, an attacker could not truly set the key to a previous state.

What an attacker *could* do, via a replay attack, is re-add signatures or
user-ids to a key on the server that the owner had later deleted. I see
this as a minor annoyance, rather than an attack, so I don't think that we
need to address it. (Though we could, through the use of server tokens or
timestamps, etc. I just think it is more work than is necessary.)

- --Len.

__

L. Sassaman

System Administrator                |

---

From: Werner Koch <[email-masked]>
Date: Tue, 11 Jul 2000 13:18:26 +0200

> that signature, and adds the key.

Don't forget that the server needs to accept unsigned requests too and
allow to add key revocations and certicate revocations.

   Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

---

From: "L. Sassaman" <[email-masked]>
Date: Tue, 11 Jul 2000 10:24:01 -0700 (PDT)

> allow to add key revocations and certicate revocations.

Yep. I figured I wouldn't bring that up again, since it looks like we're
going to be needing an I-D on keyservers, and that would fit in there. But
yes, the owner-update-only flag must be ignored on all types of
revocations.

- --Len.

__

L. Sassaman

System Administrator                |

---

From: [email-masked]
Date: Wed, 19 Jul 2000 16:41:01 +0900

sorry for the horribly slow response.

From: "L. Sassaman" <[email-masked]>
Subject: Re: Question regarding 2440:5.2.3.16
Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT)
Message-ID: <[email-masked]>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

sure, i was just making sure i followed your statements.

> that signature, and adds the key.

thanks for the explanation.

> would superceed a preveous no-modify. But that digresses from this

that makes sense.

> key. So, an attacker could not truly set the key to a previous state.

is there a reason why it is not replacement?  from the standpoint of a
user, i think i prefer replacement as that goes along w/ being able to
delete.

> timestamps, etc. I just think it is more work than is necessary.)

i guess i'd prefer to have the ability to delete things and then not
have other people be able to add things back later.  whether the
annoyance is minor or major is in the eye of the beholder, imo.  i
don't consider it minor.

i would prefer to have a timestamp / server token kind of a set-up.
if some people don't care about this and others do, i suppose it could
also be expressed as policy as part of a user's key.