recieving/updating Public Keys from SKS keyserver to pubring.gpg

[John Clizbe]

MFPA wrote:
> On Wednesday 4 August 2010 at 8:14:16 AM, in
> <mid:646262.92885.qm at web94804.mail.in2.yahoo.com>, Prasanth Thandra
> wrote:
>> When a user receives an encrypted mail from his peer ... he is
>> able to read the mail only after receiving the KEY of sender to his
>> pubring.gpg .
> 
> Not quite right, but Faramir has already addressed this point.

Public key of sender is needed to verify his signature OR to encrypt
messages sent to him.

>> But the problem here is each user has to receive KEYs of all the
>> other one after another....which i dont think is the correct way.
>> ???????
> 
> It would be the usual way to download keys from the server as needed.

True, but there are easier solutions

>> is there any way of receiving all the Public-keys that are
>> available with the local SKS keyserver ???????
> 
> If all the keys on your local server have a common string in the
> user-id, this would be trivial. Let's assume the common string is
> "@domain.example" and try issuing the command
> 
> gpg --keyserver hkp://localhost --recv-key @domain.example
> 
> Doesn't that fetch all keys on that server containing that string?
> 
> Or maybe "gpg --fetch-keys hkp://localhost" might do it?

Nope, that won't do it. --recv-key takes one of more hex key IDs.
--search-key will work with part of an address, but it is a manual
process. There's still an easier way to do this

> if it is ?? how to update users pubring.gpg periodically

gpg --refresh-keys on a periodic basis, cron job or Scheduled Tasks on
Windows

> Put the required commands in a batch file and schedule it to be run
> periodically, perhaps?
> 
>> or when ever a new KEY is received by the KEYSERVER? Please help me..

Not any mechanism within SKS for this directly, although... SKS'
mailsync mechanism could be used to forward updates to an all-employees
list, but the volume would probably get to be a nuisance. Doable but not
a good approach

> "--auto-key-locate [parameters]" could be used to fetch new keys as
> needed, rather than as soon as posted to the server

auto-key-locate is more of a last-minute fetch, as such, it can be a bit
of a gamble

Since this is all happening within the context of a single enterprise,
what we have here is a system administration/HR issue. IMNSHO, the
intelligent thing to do in this implementation would be yo keep a
separate globally readable keyring of all the employee's keys (they need
not be current)

For each new employee, the employee:
1) generates a key and sends the pub key to the ring admin and the
   keyserver, and generates a revocation certificate, a copy of which
   stays with HR (alternatively, designate HR as a revoker)

2) The employee then imports the company pubring, thus obtaining all of
   the base keys

3) Then Employee then issues gpg --refresh-keys thus updating all keys
   to their current status

This global keyring doesn't even need to be binary, it can be a
concatenation of .asc exported keys

This scenario, along with ADKs, is part of what prompted PGP Corp to
create their PGP Enterprise offering.

If I was implementing this, I would not bother with running a private
SKS server for keys, it's serious overkill -- it's akin to using a
bazooka instead of a fly-swatter. (Note: I run a SKS keyserver.)

I'd use LDAP to serve keys as part of an enterprise wide directory
system.  Much, much, much more cleaner, easier, and more multipurpose of
a solution.

Honestly, you want LDAP. Really.

-- 
John P. Clizbe                      Inet: John (a) Keyservers DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 499 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100805/996a6ad6/attachment.pgp>