New LDAP server commands

[Shaun Savage]

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

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

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.



> 
> > 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
a person is sending e-mail that they have network access.  If this this
happens then the mail program could/should ask about what to do.  save
it for later encryption and sending or ask if they what to send it
unencrypted.

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

All packets from the server are armored  GPG blocks. This put the
responsibility of make eveything is OK on the user.  here is and example

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.  
Most users will most likely just accept the pubkey and send the email. 
You can offer the user choices but you can't make them drink, or was
that horses.
 
Shaun Savage


> 
> 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.
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature