Daniel N
1/18/2007 9:55:00 AM
On 1/18/07, benjohn@fysh.org <benjohn@fysh.org> wrote:
> *snip*
> >> My thinking is firstly to require all clients to provide a public
> >> digital
> >> certificate, then when they request the data send something like.
> >>
> >> <data_transmission>
> >> <key>
> >> AES key that has been encrypted with PGP using the public key
> >> </key>
> >> <data>
> >> data encrypted with AES using the un-encrypted key
> >> </data>
> >> </data_transmission>
> >>
> >> Then when the client recieves the data, they un-encrypt the key with
> >> their
> >> private key, and then un-encrypt the data.
> >>
> >> Firstly, is this approach secure?
> >
> > If you implement it correctly, this is the "standard" approach
>
> *snip*
>
> This isn't something I've got a lot of experience of, but...
>
> It's worth pointing out that you probably wouldn't send the lump of XML
> above. If you do this, you'll have to get your software to manage
> encryption, decryption, key sharing, and lots of other fluf that I doubt
> you care about.
>
> What you'd probably do instead is simply communicate over a secure
> socket, and pretty much forget about encryption. Your program may be
> entirely oblivious to it, in fact, or may be a little aware in that it
> knows it's setting up a secure socket, or perhaps checks that the socket
> creation parameter it's been given results in a secure socket. Something
> like that.
I thought about just doing the communication over ssl, but I want to
ensure that the correct client is requesting the data. At this stage
I'm still early in my thought processes on exactly how to achieve
this.
It's important that only the correct client, obtain the data. Also it
is important that the client is who they say they are, and not just
someone who setup an account claiming to be someone else. Hence my
interest in using their certificates and encrypting using their public
key, so only they can unencrypt.
My current thinking is that when a client signs up for an account, use
their digital certificate and domain to confirm their identity, and
then in the future they can request data from the site. I don't need
to go over ssl, because by encrypting with their own public key, only
they can get the data.
At least this is my undestanding at the moment, but I have to read the
posts from Jan yet.
Cheers