New LDAP server commands

[Shaun Savage]

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

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

there are commands send-keys and recv-keys that transfer keys with a
server. These commands use armored blocks of packets.  decoding and
encoding these commands use many pgp functions that I don't want to
rewrite.

finding a person's key on a LDAP key server may not require many gpg
functions but getting the correct key into the local keyring does.


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
will you please write a HOWTO on using server trust.

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.

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. 
Then the gets a signature of that pubkey by Chloe and Chloe pubkey. Now
Alice knows Chole full trust Elena or Chole marginal trust Elena.  But
At this point Alice still doesn't trust Chole.
Now Alice get Chole trust signatures from the server, Blake and Dharma.
The chain now is done.

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
block" to the server that is 'linked' with Elena key.  This link is a
database link not changing any of Elena data.

Blake meets Chloe and Dharma and after a night of 'group of three':)
they exchange keys.  Both Blake and Dharma sends a "trust block" to the
server that gets linked to Chloe's key. 

This scheme will also supports revoking your signatures of others public
keys.

-------------------------------------------
The pgp trust scheme is very flexible and most of the security decisions
are done by the user.  If the user does not follow good security
procedures then their trust is not good. It is can not be up to the
program to enforce good security procedures, because it requires a human
decision, and humans are and will be the weak link in the whole process.

Shaun Savage

answers to specific issues follow
-------------------------------------------
Christian Kurz wrote:
> 
> [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. ;)

Please send my the script.

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

There is no support for using pgp block and packet building and parsing
outside of gpg.


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

I believe it is local only.  I would like server trust database.  I
don't think this has been implemented any place, if I am wrong please
let me know where I can get information on this.
The issue of authentification is required but is more personal. There
are suggested ways of authentification that people should follow but
there is no enforcement of that.

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

I can exchange keys and I understand the local web of trust.  

> 
> > 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?
> 
No It's not running on the local machine, it is a LDAP server running
somewhere in the world.

> > 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.
> 
That I why I said "wrongly assume", then they can't use LDAP.  But if
they are connected to the net, even dial-up can use this feature. The
e-mail is locally encrypted using a private key and when net access is
avaiable the the e-mail is decrypted and encrypted again but this time
using the other person's pubkey.


> 
> > 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.
> 
In "Distributing keys" in the gpg manual it states that different people
can 
sign an other person key and it will get merged with that key.  I assume
that by sending a public key signed by you will do that( the manual does
not state how to do this directly).  

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

do you really need CA's, no. Would some type of CA be helpful, maybe
yes.  The trusting the CA is a totally different set of issues.


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

The server does not handle that trustlevels, the user does. The server
just reports the trustlevel the user assigned.


> 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