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

[Dmitri Pal]

John Dennis wrote:
> 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.
>
Ok so here are the questions I have:

We send the CSR from cermonger and the principal name separately. Is
this a right approach?
Do we send the principal in case admin requests a cert for someone using
main CLI. I hope not.
Does that mean that server already knows how to dig into the CSR and get
the principal out of it?
Why we can't reuse same approach then?

The more I think about the difference between the admin+CLI use case vs
cermonger use case
the more I come to conclusion that they should have a lot in common. I.e:

a) Server side part of the XML RPC is probably same
b) The permissions are checked on the ACI basis so interface and XML-RPC
code does not know anything about that part at all.
c) Logic of the client is pretty same. The only main difference it seems
that certmonger is a C application
and admin CLI is python but they should do pretty much same thing:
* create CSR
* send it to the server
* when server responds, process the result (save cert to the file or NSS
database or just spit out as based 64 encoded string).
 
Am I oversimplifying things and there is really something different on
the server side between processing certmonger's cert
request vs processing CLI request initiated by admin?


 


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


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