[ale] Key management

[Michael H. Warfield]

On Wed, 2008-05-14 at 11:01 -0700, Kevin O'Neill Stoll wrote:
> We are saying the same thing, just worded diff.

> Problem being, I don't want to have to distribute O's pub
> key manually to a dozen or 12 dozen sources.

> In the case of a pks, I would just configure the S clients
> to lookup against an internal pks for the O pub key,
> instead of manually placing a copy locally with each S.

	How does that differ from using a PGP key server (public or otherwise)?

> And in reverse, O could lookup the pub key of the signer to
> validate the origin.

	Same thing again.  And you could sign that key with O's key and only
accept keys that O had signed, preventing any key spoofing.

	Mike

> --- "Michael H. Warfield" <mhw at wittsend.com> wrote:
> 
> > Hello,
> > 
> > On Wed, 2008-05-14 at 09:26 -0700, Kevin O'Neill Stoll
> > wrote:
> > > Hey guys,
> > 
> > > Need some help with direction on encryption 
> > 
> > > Goal: I need to encryption plain text files while at
> > rest.
> > > One use case would be: files are received via ftp from
> > > various banks and should/could be encrypted with gpg
> > with
> > > the recipient defined as the consuming application, in
> > this
> > > case, Oracle Financials.
> > 
> > > Problem: the consuming application will be receiving
> > > encrypted files from many sources, not just the ftp
> > host,
> > > so Oracle Financials has to know about a great many
> > public
> > > keys, assuming the use of gpg. How do I got about
> > managing
> > > these keys in a central way?
> > 
> > 	Either I don't understand your application or you have
> > this completely
> > upside down.  "Oracle Financials" only needs one key, its
> > private key.
> > All the other parties will have the public key and
> > encrypt the data to
> > that public key.  Then, only Oracle Financials will be
> > able to decrypt
> > the files once it receives them.
> > 
> > 	So, I'm assuming that originating source "S" encrypts to
> > key "O" and
> > then the data is transferred to "O" through some means
> > involving some
> > resting data at each end.  "O" can then decrypt the data
> > as needed and
> > when needed and the data remains encrypted on storage. 
> > "S" would then
> > have no means to even decrypt the data that they
> > generated unless they
> > added their own key (and a wise move would be to also
> > sign the data for
> > authentication purposes) or kept a copy for themselves
> > (very unwise).
> > 
> > > I have looked into pks and sks, but catch here is they
> > > wanted something supported by our vendors (SuSE in this
> > > case).  
> > > 
> > > So, how do I manage a bunch of keys like this?
> > > 
> > >  
> > > If you don’t think gpg is the answer, I’m open to
> > ideas.
> > > I’m not stuck on anything at this point, just trying
> > to
> > > figure out how to roll an encryption solution that I
> > can
> > > ultimately hand off to an operations group and can
> > scale /
> > > support 500+ end-points.
> > > 
> > > Also, not afraid of commercial solutions but would like
> > to
> > > exhaust any and all oss solutions first.
> > > 
> > >  
> > > Thanks 
> > > 
> > > PKS: http://pks.sourceforge.net/
> > > 
> > > SKS: http://www.nongnu.org/sks/
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > >       
> > > _______________________________________________
> > > Ale mailing list
> > > Ale at ale.org
> > > http://mail.ale.org/mailman/listinfo/ale
> > > 
> > -- 
> > Michael H. Warfield (AI4NB) | (770) 985-6132 | 
> > mhw at WittsEnd.com
> >    /\/\|=mhw=|\/\/          | (678) 463-0932 | 
> > http://www.wittsend.com/mhw/
> >    NIC whois: MHW9          | An optimist believes we
> > live in the best of all
> >  PGP Key: 0xDF1DD471        | possible worlds.  A
> > pessimist is sure of it!
> > 
> > > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > 
> 
> 
> 
>       
> 
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080514/29ae99e9/attachment.bin