[Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Ben Lipton wrote:
>On 07/25/2016 05:07 AM, Simo Sorce wrote:
>>On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
>>>Anyway, my main grudge is that the transformation rules shouldn't
>>>really
>>>be stored on and processed by the server. The server should know the
>>>*what* (mapping rules), but not the *how* (transformation rules). The
>>>*how* is an implementation detail and does not change in time, so
>>>there's no benefit in handling it on the server. It should be handled
>>>exclusively on the client, which I believe would also make the whole
>>>thing more robust (it would not be possible for a bug on the server
>>>to
>>>break all the clients).
>>W/o entering in specific +1 as a general comment on this.
>>If it can be done on the client, probably better be done there.
>>
>>Simo.
>>
>My thinking was that while the CSR generation must be done on the 
>client, the retrieval and formatting of the data for the CSR should be 
>done on the server, so that the functionality is available to all 
>consumers of the API (ipa command-line, certmonger, Web UI, something 
>else?). I imagine it would be relatively easy to move the formatting 
>stuff into the ipa CLI, but all the other clients would then need an 
>implementation of their own, and so we'd need to worry about 
>interpreting the templates and generating CSRs in multiple different 
>languages. It's true that as it stands a bug on the server could break 
>all the clients, but on the other hand there's only one implementation 
>to maintain, rather than a different one in each client.
For other clients we would need to worry about CSR, not generating them.
For them we *could* make use of the fact that IPA server is IPA client
as well and provide some API to create CSR based on a pre-defined
request type (e.g. don't support all CSR backends, just one, like
python-cryptography). That wouldn't be too flexible but for flexibility
we already accept CSRs generated by someone else.

>But maybe I'm not seeing the proper priorities here. Perhaps it's more 
>of a problem because clients are easier to update with bugfixes than 
>the server? Or maybe the preference for the client is for scalability 
>reasons? Could you tell me more about why you prefer a client 
>implementation?
Making client responsible for generating the certificate signing
request serves several purposes where privacy is one of main benefits:
access to private key stays at the client side.

>(And yeah, everything here carries a disclaimer of "I probably can't 
>make any large changes in the remaining 3 weeks of my internship," but 
>I think it's still good to know and document what the limitations of 
>the current implementation are.)
Agreed.
-- 
/ Alexander Bokovoy