For those who're interested in what I ended up doing;

a) the client registers itself with the server, by sending it a CSR.  In
order to access this registration page, it must authenticate itself
through conventional means (username/password or auth token).

b) the server generates a certificate based on the client's CSR and the
server's CA key, and returns this cert to the client.

c) all further communication with the server takes place in an area where
the server requires the client's SSL cert to be signed by it. 
Identification is embedded in the cert (as it was in the client's CSR).

This works quite well (once you get around the php openssl bugs) with the
existing usefulinc xmlrpc implementation.


On Tue, 29 Oct 2002 07:30:52 -0600, Miles Lott wrote:

>> I'm attempting to add key signing to your xmlrpc library (I'll feed
>> changes back upstream once I'm done).  Once an xmlrpcmsg is about to be
>> sent, it is serialized, a private key is used to generate a signature of
>> the serialized data, and both are sent to the xmlrpc server.  The server
>> uses the client's public key to verify that the msg came from the actual
>> client; if verification is sucessful, decode the xmlrpcmsg as normal.
> 
> In phpgroupware/groupwhere, a login function is called first.  This
> generates a sessionid and key as with their normal browser login.  The
> sessionid/key are then sent in Authorization: Basic header to verify
> subsequent requests.  Lastly, a logout packet is sent to clear the user
> session.  Public/private keys would be cool, though.  I had not done
> much in that implementation to encrypt subsequent requests...
> 




_______________________________________________
phpxmlrpc mailing list
[EMAIL PROTECTED]
http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc

Reply via email to