[Freeipa-devel] Re: Certificate enrollment, principal names

[John Dennis]

On 11/05/2009 12:04 PM, Nalin Dahyabhai wrote:
> On Thu, Nov 05, 2009 at 10:39:00AM -0500, Dmitri Pal wrote:
>> This is not what Andrew was saying.
>> As far as I understand the CSR is a blob of signed information that
>> client sends to server
>> to get a certificate. The CSR needs to be created somehow. I do not know
>> how it is created
>> but it seems that there are two steps:
>> * create CSR
>> * pass CSR to the command
>>
>> Andrew suggested to do it in one step (and I agree with him).
>> However we have two different use cases:
>> * Admin wants to create a cert - in this case our standard CLI is called
>> (and the discussion about hooks
>> is related to this part)
>> *  Certmonger asks for cert -in this case it does not use our standard
>> XML-RPC framework but rather
>> prepares the request itself and sends it over XML-RPC
>>
>> So how do we do or plan to do it in each of the two use cases?
>> It seems that the most user friendly approach would be to ask user for
>> arguments,
>> using these arguments generate CSR on the client and then pass it to the
>> server.
>> In both cases it should be done in one step by invoking other tools and
>> utils (if any)
>> needed to prepare CSR from within the command.
>>
>> And I correct?
>
> Yes, and that's what we do now -- when you tell certmonger you want a
> certificate, it handles generating a CSR with the key you provide (or
> one it generates and saves, if there isn't already one in the location
> where you told it to look) and the settings you supply, or with default
> settings if you don't provide any.  It then goes about the business of
> getting a certificate, usually from a CA, using the CSR.  For IPA,
> that's done with the XMLRPC call to the cert_request() method.
>
> At the moment, we also have to send the principal name that we've
> encoded into the CSR as a separate string parameter to the XMLRPC
> request that we send to IPA.  If we find we need more info later, we'll
> either need to add another argument to the request (and my reading of
> the XMLRPC spec doesn't tell me if that's considered an incompatible
> change or not) or teach the server to dig it out of the CSR.

Because of the way we're using XMLRPC in IPA we can add a new parameter 
at anytime. That's because we don't actually use positional parameters 
in the traditional sense. Instead our XMLRPC interface takes a one 
positional parameter which is a struct (e.g. dict) with all the *named* 
parameters in it as key/value pairs. (O.K. I fudging a bit on the 
details). Because we're passing *all* arguments as key/value pairs we 
can add or remove a parameter at will without breaking core XMLRPC.

However, both the client and server need to be versioned correctly. It's 
fine to send a new parameter through XMLRPC but the server has to know 
to look for it. This is really no different than "teaching the server to 
extract it from the CSR". In both cases the server has to be aware of 
the new value. The XMLRPC interface in this instance is a bit of a red 
herring.

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/