[Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

[Martin Kosek]

On 08/16/2016 08:12 PM, Alexander Bokovoy wrote:
> On Tue, 16 Aug 2016, Ben Lipton wrote:
>> On 08/10/2016 08:52 AM, Ben Lipton wrote:
>>> The pull request at https://github.com/LiptonB/freeipa/pull/4/commits has
>>> been brought up to date (with a force push), and also includes 3 more
>>> patches, described below.
>>>
>>> The patchset is also attached. To make sure that everything applies, I just
>>> regenerated the whole set, though there may not be meaningful changes.
>>>
>> After a discussion about how to address some of the concerns that have been
>> voiced about this project, there have been some changes to the project
>> direction. So, I wanted to provide an update about what the plans are. If you
>> have objections or feel that I'm not representing it correctly, please let me
>> know.
>>
>> Since we have yet to see all the ways people will want to use this feature,
>> the immediate goal is to provide something that we can iterate on. To make
>> this easier, we will avoid storing rule data on the server or modifying the
>> server schema, as those changes would need to be supported long term/handled
>> correctly on update. I plan to approach this as follows:
>> - Separate the provider of mapping rules into a separate component from the
>> generation of a config based on those rules
>> - Build an alternative rule provider that reads local files rather than
>> querying IPA
>> - Move the implementation of CSR config formatting from the server API into a
>> library (where should this go? ipalib? ipapython?), and then provide a
>> client-side command that builds a config using the library.
> Up to you -- ipapython is traditionally used for very basic dependencies
> when nothing is configured and is used by both installers and the
> framework, ipalib -- for common code in the framework itself.
> 
>> - Templates for at least two profiles ("user" profile with
>> CN=<username>,<subject_base> subject and email address SAN, "service" profile
>> with CN=<fqdn>,<subject_base> subject and DNS SAN) will be provided. Users
>> will be able to build custom profiles by putting files in the appropriate
>> directories on their client machines (but we will not guarantee backward
>> compatibility for the format of these files).
>> - If we decide to move forward with storing rules on the server, the library
>> call can be referenced from the server code, using the rule provider that
>> pulls rules from the API. However, at that point we may also go in the
>> direction of making automatic cert generation fully the responsibility of
>> Dogtag, and keep the CSR-generation approach client-side only.
>>
>> Comments welcome! Unless the changes are more complex than I anticipate, I
>> hope to have a prototype of this approach for review by the end of this week.
> The summary above looks fine.

+1, this looks good to me too. Thanks Ben, good job!

Martin