Janusz A. Urbanowicz
alex at bofh.torun.pl
Mon Oct 4 02:04:23 CEST 1999
> "Janusz A. Urbanowicz" <alex at bofh.torun.pl> writes:
> > Splitting keyring option into keyring and additional-keyring.
> What I want to do is do check fro RO keyrings and don't update them at
A good idea. But I'd suggest a possibility of _declaring_ a RO keyring.
> > be used. Key disabling (and revocation ?) should apply to both keyrings.
> Disabling would work but revocations are a problem because the
> samllest entity the key management code handles is the keyblock and
> therefore we would have to copy the keyblock to a RW keyring and add
> the revocation there.
> Things are getting too complicated. The real way to handle the things
> you need is a local keyserver. Thomas Roessler has a keyserver proxy
> which might be extented to fulfill your requirements (I guess you find
> it somewhere at ftp.mutt.org)
I'll have a look at it, tomorrow. But what I think a real solution would be
an alternative source for keys (additional to keyring[s]) that probably
should be LDAP based.
> > This option should be also settable in system-wide options file (in case
> > such a feature will ever exist). This way admins could keep system-wide
> My opionion is that key distribution should be handled automagically
> and the user should not have to think about it. This is the reason
> for removing the trust parameters from the keyrings.
Maybe should I start to look at how to implement keyring-via-LDAP ? What do
you thing, guys'n'gals ?
* | Janusz A. "Alex" Urbanowicz, | DSS: 1024/0x21939169
--+~| | http://eris.phys.uni.torun.pl/~alex/ | D-H: 2048/0xA2E48564
\_|/ | |_ RSA: 512/0xAB425659
| | WAR IS PEACE FREEDOM IS SLAVERY ERASE IS BACKSPACE -- rms
More information about the Gnupg-devel