Dpal 02:24, 4 June 2009 (UTC)
I think there is some confusion about the XMLRPC, python and what is available and how things work with IPA.
When we talk about client we talk about a member of the IPA domain. In IPA v1 the clients had all the python commands installed so there was no difference between client and machine from which you can run CLI. In v2 this will change. In v2 it should not be assumed that the CLI is available on every machine. The CLI will be a separately installable package for the administration of the IPA. It will be recommended to install it only where needed. This all means that the the host that needs to escrow its keys will not have those utilities.
It will have utilities to enroll the machine. This utility will be written (most likely) in C to be able to cover a broad set of platforms we plan to eventually support.
So the client of the keys escrow would have to either use:
- Its own (most likely C) implementation of the XML-RPC so that it would talk to the server using XML-RPC protocol. This approach is something that is being explored by the entollment utility implementation. The issue that I see is that it would have to support kerberos over GSSAPI. Seems like a heavy lifting to me.
- The alternative would be to use LDAP protocol and submit the escrow packets using the ldapmodify or similar utility. It natively supports kerberos and GSSAPI so the solution would be much simpler. The issue with this approach is that it is a bit (as the previous one too) heavy for the other use cases related to key management. For example for use case when the IPA needs to be accessed from a preboot partition.
- Explore KMIP protocol. Unfortunately I have not have a chance to read the specs yet but I plan to as soon as I can. It the KMIP proves to be the way to go based on the specs then I envision that we would have to stand up a KMIP server that would have to be able to handle different requests one of which would be key escrow from the client. I am not sure that for other use cases related to management of the already saved keys we need to go though such KMIP server. It looks like that these use cases can be solved by the usual ipa commands. Those would leverage our framework. For them there is no need to have a special user account like ipaXMLRPCServiceAccount. The authenticated user that tries to perform an operation would have to have rights to access the DS entry and its attributes. This all controlled on the ACI level and enforced by DS itself. We would have to see if we need a special account for the KMIP server or not and how it would connect to the IPA. I can't say anything about this until I read the specs. If we go with KMIP than on the client we would implement KMIP client. I assume there is some way to secure the channel for the KMIP client to talk to server and I assume the KMIP client can be pretty light weight so that it can connect from the pre-boot partition.
So to summarize: the whole section after the schema definition seems a bit off to me since it talks about the XMLRPC and makes some assumtions about it that are not valid.