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

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy