[
Lists Home |
Date Index |
Thread Index
]
Jeff,
It is not a key exchange issue. With SOAP, you can easily separate
routing information and data so that you can encrypt head and body
elements independently, REST does not. Cool thing about SOAP approach
is that you can sign with multiple keys so that no only routers don't
know about the content, routers themselves don't know where it will
eventually end up.
If you do come up with some standard structure to do the same in REST,
you are basically reinventing SOAP.
A side note: Security and high availability often don't mix at web
server level because you often can't afford to add crypto hardware to
every web server in a large web farm. Doing it at application server
level makes more sense in most applications.
Best,
Don Park
Docuverse
> Why isn't it a RESTful solution to have the client encrypt
> the data (using an applet on the original page, or some
> Javascript or something else) and POST the encrypted data
> (encoded in base64 if necessary) to the HTTP server? Only the
> backend program (running inside the firewall perhaps on a different
> machine) would know how to decrypt the POSTed data. It could
> still return a URL representing the resulting resource, etc.
> I think this handles both the wire security and web server
> security issues. There is then some kind of key exchange
> issue, presumably with some standard solution, as long as
> there is one which does not require the program which
> eventually decrypts the data to call back to the encrypting
> program. It should be clear that I'm speculating, not
> speaking from authoritative knowledge, here!
|
