Re: Question regarding 2440:5.2.3.16

["L. Sassaman" <rabbi@xxxxxxxxxxx>]

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

On Mon, 10 Jul 2000 sen_ml@xxxxxxxxxxx wrote:

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

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.

> > 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? 
> 
> 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. ]

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. 

> 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.

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                |  
Technology Consultant               |  "Credo quia absurdum."
icq.. 10735603                      |  
pgp.. finger://ns.quickie.net/rabbi |          --Tertullian 







-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5agW/PYrxsgmsCmoRAhJhAKCo88zWNgPDz7aQ77qGMv7wmNgVWgCdGfcs
6xQ9X0cE6PywApXO0N0FVRc=
=IpeB
-----END PGP SIGNATURE-----