[ale] Key management

[Kevin O'Neill Stoll]

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.

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



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