New LDAP server commands

[Christian Kurz]

[I read the list where I write, so there's absolutely no need to send me
any extra Cc.]

On 00-10-21 Shaun Savage wrote:
> Christian Kurz wrote:
> > 
> > On 00-10-20 Shaun Savage wrote:
> > > I have to ask a question.
> > 
> > > I would like to add three more commands to the gpg
> > 
> > > --view-keys and --send-sign and --recv-trust
> > 
> > > **********
> > 
> > > --view-keys koch     and this command will list all/some of the gpg
> > > keys                          that match "koch" in the user_id field.

> I changed it to  --find-keys

> > This is an operation that should not be done by GnuPG itself, but
> > instead by a seperate programm. Either include this feature in the
> > mailreader itself or use an external programm for this. (I send a
> > preliminary script for this already to Werner but got no answer about
> > it till today. ;)

> I am adding this feature in to gpg because I need alot of functions that
> gpg supply and I am lazy and don't want to rewrite all the functions I


And where's the problem with using an external script for this purpose
that could interact with gpg? Why do you need special function included
in GnuPG itself? And just because you are too lazy to rewrite your
functions, this new options should be implemented? Sorry, but this is no
good explanation why this functions should really be available in GnuPG
itself and not in an external program/script.

> use.  But yes,  I hope that that after I get yhis functionality working
> that moving these operations into a seperate program/library is the next
> step. 

Well, but why don't you then direclty move the stuff into an extra
program but instead first ask for a modicifation of GnuPG?

> > > -u bar --send-sign foo      this command will send a trust signature of
> > > foo                           signed by bar.
> > 
> > What should this be good for? What do you mean with trust signature
> > exactly?

> I am not sure.  I want people to be able to 'sign' other peoples pubkeys
> so that a greater web of trust can be built.  

You can already sign their keys and built a web of trust, but I hope you
do some authentification prior to sign their keys.

> All data will be stored in armored pgp packet/block format only the
> search stuff and extracted info in stored in the server.  
> this block consist of a optional pubkey packet and a signature of that
> pubkey packet.

What? This sounds very much like you don't know how to sign keys already
with GnuPG and how to exchange signatures with other people with the
functions already available. If not, then please provide a detailed and
clear explanation (maybe with an example) what exactly you mean.

> > > Here is an example of how a "normal" person would encrypt a e-mail.
> > 
> > > encrypt is enabled by default
> > 
> > > the person writes the letter then presses SEND
> > > the gpg then checks the local keyring for the email address(es)
> > > if not found it then checks a ldap server with the e-mail address as the
> > 
> > And what if you don't have a LDAP-Server configured or available? What
> > should happen then?

> there can be a default server in the setup.  I wrongly assume that if

What? Another server running on the machine where you installed GnuPG?
Do you want to open another security hole with a daemon not needed?

> a person is sending e-mail that they have network access.  If this this

What with people having only dial-up network access or which only use
uccp for sending and receiving mails? Don't assume that everybody has
full net access, who uses GnuPG.

> > > search filter.  If a key is found it will return it and ask(or not) to
> > > put the key into the local keyring.  It then encrypts the e-mail and
> > 
> > You trust keys that you get from a LDAP-Server? How can you be sure that
> > this the right key and not a compromised one? How do you make sure that
> > you really have the key of the person you are mailing to?

> this is that what that signature packet is for. If one of the signatures
> for this person is someone you trust then the pubkey can be trusted. 

NO! I would never trust a pubkey just because a signature on it has been
made by a person that I trusted. Trust has to be defined by some
authentification, which includes more then a signature. This sounds like
you don't understand the idea behind the "Web Of Trust" and "Signatures"
really.

> the question here is
> how deep in the trust tree do you want to go?  There are CA for x509
> certs why not have a CA for pgp also (MAY) but not have to. 

Do we really need CAs to sign GnuPG keys to trust them? How can you
trust the CA? How did authentificate itself to you? How can you be sure
that they real do everyhting the right and correct way? 

> user "foo bar <foob at bar.com>" is found by searching for "foo" on the
> server or "foob at bar.com" from an e-mail client.

> when this key block arrives   it contains atleast three packets
> (pubkey,userid,selfsig) now they have a new pubkey. The user is asked
> do you want to add pubkey "foo bar <foob at bar.com" the fingerprint
> "0a9b8c7d6e5f4321" or do you want to get more trust signatures?  More
> trust signature was choosen. Now some number of sign block arrive
> (signature) because sign packet has a keyid of the pubkey. now one of
> these sig blocks is know the signature. that info is showed to the user
> and he make the decision to use it or not.  

You trust a pub key just because it has 10 signatures of people that you
trusted? Well, what meaning have 10 signature of people you trusted on a
pubkey? You know that GnuPG already has different trustlevels? How do
you want to handle that? 

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/20001021/3bfd498f/attachment.bin