New LDAP server commands

[Christian Kurz]

On 00-10-21 Shaun Savage wrote:
> >From the tone of your replies, I think there is some miss
> understanding.  I am trying to add LDAP server communcation to gpg. 
> Right now there is the HK Protocol supported, I would like to add LDAP
> support also.  This server is not running on your local machine.
> Do you think LDAP support should be added, or have you added it already?

What has an LDAP-Server to do with an Keyserver and why should keys be
available from an LDAP-Server? Do you have problems installing a
keyserver or where exactly is the problem with the HK-Protocol, that you
need gpg to use the LDAP-Protocol?

> In order to improve usability for the average user, LDAP I hope would
> make it easy for the average user to find keys.  

The interface via webpages to find keys is already very easy and i think
the GnuPG Privacy Assistent and other third party tools should include
an interface for contacting the keysever to get keys that are not in
your local keyring. This isn't a functionality that is needed and useful
in gpg itself.

> As for the web of trust and such, AS I understand it, all the signing is
> done on your local keyring, not on a server. This means that
> localazation of trust is good but it does not scale well. If I am wrong

Yes, you are signing the key on your local machine, but you giving the
signed key to the person who owns the key and often you upload a copy of
it to the keyserver itself, so that other people are able to see the
trust between those two keys. And I don't talk about localisation of
trust, please read exactly what I write.

> Trust is the big issue.  The LDAP does no 'trust' it just allow a user
> to access data that may help in the local trust decision.

What access does it allow that you don't get from a keyserver?

> example:
> on the server there are pubkeys of
> 	Alice,Blake,Chloe,Dharma,Francis,Elena
> on the server there are signatures
> 	Blake:   Alice
> 	Dharma:  Alice
>  	Chloa:	 Blake, Dharma
> 	Francie: Chloe, Dharma
> 	Elena:	 Chloe

> On Alice local key ring is Blake and Dharna pubkey

> If Alice want to send someting to Elena, first she get Elena pubkey. 

Which can already be done very easy with the webinterface at
keyserver.net.

> Then the gets a signature of that pubkey by Chloe and Chloe pubkey. Now

by Chloe and Chloe pubkey? What's the first Chloe? A special key not
mentioned above? Also if you get a key from the keyserver you already
see this signature. 

> Alice knows Chole full trust Elena or Chole marginal trust Elena.  But

Or? You the big difference between full and marginal trust? This is a
big difference and if a user is not fully aware what kind of trust is
used, it's broken by design. The user has always to see first what kind
of trust is existing between those two keys. 

> At this point Alice still doesn't trust Chole.

And shouldn't trust here.

> Now Alice get Chole trust signatures from the server, Blake and Dharma.
> The chain now is done.

No, because you don't know if the key from Blake and Dharma belong
really to them? Also you have no clue about the trust, if it's fully or
only marginally. And just seeing this two signatures would make me
really trust that key, because I prefer signature by people that I meat. 

> Before all this can happen Chloa needs to send the key to the server.
> Later Chloa meets Elena, the exchange fingerprints and keys.  Now Chloa
> what the world to know Elena key is valid(trusted).  Chloa send a "trust

Be careful, it can be fully trusted or marginally. So just writing the
key is "valid (trusted)", doesn't work. 

> block" to the server that is 'linked' with Elena key.  This link is a
> database link not changing any of Elena data.

Argh, this is already very easy to do, without using some LDAP-stuff.
Chloe and Elena exchange keys and sign them (and define the
trust-level). Now both exchange their signed keys via email and upload a
copy of it to the keyserver and now the whole world can see the trust
between those two keys. Absolutely no need for using an LDAP-Server for
this.


> answers to specific issues follow

Full quoting of answers is bad style. Please either remove the answer
completelty or just quote the parts that you are answering too.
(http://learn.to/quote/)

Ciao
     Christian
-- 
While the year 2000 (y2k) problem is not an issue for us, all Linux
implementations will impacted by the year 2038 (y2.038k) issue. The Debian
Project is committed to working with the industry on this issue and we will
have our full plans and strategy posted by the first quarter of 2020.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url : /pipermail/attachments/20001022/d5524679/attachment.bin