[Freeipa-devel] CSR autogeneration next steps

[Ben Lipton]

Hi Jan, thanks for the comments.


On 12/05/2016 04:25 AM, Jan Cholasta wrote:
> Hi Ben,
>
> On 3.11.2016 00:12, Ben Lipton wrote:
>> Hi everybody,
>>
>> Soon I'm going to have to reduce the amount of time I spend on new
>> development work for the CSR autogeneration project, and I want to leave
>> the project in as organized a state as possible. So, I'm taking
>> inventory of the work I've done in order to make sure that what's ready
>> for review can get reviewed and the ideas that have been discussed get
>> prototyped or at least recorded so they won't be forgotten.
>
> Thanks, I have some questions and comments, see below.
>
>>
>> Code that's ready for review (I will continue to put in as much time as
>> needed to help get these ready for submission):
>>
>> - Current PR: https://github.com/freeipa/freeipa/pull/10
>
> How hard would it be to update the PR to use the "new" interface from 
> the design thread? By this I mean that currently there is a command 
> (cert_get_requestdata), which creates a CSR from profile id + 
> principal + helper, but in the design we discussed a command which 
> creates a CertificationRequestInfo from profile id + principal + 
> public key.
>
> Internally it could use the OpenSSL helper, no need to implement the 
> full "new" design. With your build_requestinfo.c code below it looks 
> like it should be pretty straightforward.

This is probably doable with the cffi, but I'm concerned about 
usability. A user can run the current command to get a (reusable) 
script, and run the script to get a CSR. It works with keys in both PEM 
files and NSS databases already. If we change to outputting a 
CertificationRequestInfo, in order to make this usable on the command 
line, we'll need:
- An additional tool to sign a CSR given a CertificationRequestInfo (for 
both types of key storage).
- A way to extract a SubjectPublicKeyInfo structure from a key within 
the ipa command (like [1] but we need it for both types of key storage)
Since as far as I know there's no standard encoding for files containing 
only a CertificationRequestInfo or a SubjectPublicKeyInfo, we'll be 
writing and distributing these ourselves. I think that's where most of 
the extra work will come in.

Would it be ok to stick with the current design in this PR? I'd feel 
much better if we could get the basic functionality into the repo and 
then iterate on it rather than changing the plan at this point. I can 
create a separate PR to change cert_get_requestdata to this new 
interface and at the same time add the necessary adapters (bullet points 
above) to make it user-friendly.

I would probably just implement the adapters within the 
cert_build/cert_request client code unless you think having standalone 
tools is valuable. I suppose certmonger is going to need these features 
too, but I don't know how well sharing code between them is going to work.
>
>>
>> - Allow some fields to be specified by the user at creation time:
>> https://github.com/LiptonB/freeipa/commits/local-user-data
>
> Good idea :-)
>
>>
>> - Automation for the full process from getting CSR data to requesting
>> cert: https://github.com/LiptonB/freeipa/commits/local-cert-build
>
> LGTM, although I would prefer if this was a client-side extension of 
> cert-request rather than a completely new command.

I did try that at first, but I struggled to figure out the interface for 
the modified cert-request. (Not that the current solution is so great, 
what with the copying of options from cert_request and certreq.) If I 
remember correctly, I was uncertain how to implement parameters that are 
required/invalid based on other parameters: the current cert-request 
takes a signed CSR (required), a principal (required), and a profile ID; 
the new cert-request (what I implemented as cert-build) takes a 
principal (required), a profile ID (required), and a key location 
(required). I can't remember if that was the only problem, but I'll try 
again to merge the commands and get back to you.
>
>>
>> Other prototypes and design ideas that aren't ready for submission yet:
>>
>> - Utility written in C to build a CertificationRequestInfo from a
>> SubjectPublicKeyInfo and an openssl-style config file. The purpose of
>> this is to take a config that my code already knows how to generate, and
>> put it in a form that certmonger can use. This is nearly done and
>> available at:
>> https://github.com/LiptonB/freeipa-prototypes/blob/master/build_requestinfo.c 
>>
>
> Nice! As I said above, this could really make implementing the "new" 
> csrgen interface simple.
>
>>
>>
>> - Ideally it should be possible to use this tool to reimplement the full
>> cert-request automation (local-cert-build branch) without a dependency
>> on the certutil/openssl tools. However, I don't think any of the python
>> crypto libraries have bindings for the functions that deal with
>> CertificationRequestInfo objects, so I don't think I can do this in the
>> short term.
>
> You can use python-cffi to write your own minimal bindings. It's 
> fairly straightforward, take a look at FreeIPA commit 500ee7e2 for an 
> example of how to port C code to Python with python-cffi.

Thank you for the example. I will take a look.
>
>>
>> - Certmonger "helper" program that takes in the CertificationRequestInfo
>> that certmonger generates, calls out to IPA for profile-specific data,
>> and returns an updated CertificationRequestInfo built from the data.
>> Certmonger doesn't currently support this type of helper, but (if I
>> understood correctly) this is the architecture Nalin believed would be
>> simplest to fit in. This is not done yet, but I intend to complete it
>> soon - it shouldn't require much code beyond what's in 
>> build_requestinfo.c.
>
> To me this sounds like it should be a new operation of the current 
> helper rather than a completely new helper.

Maybe so. I certainly wouldn't call this a finished design, I just 
wanted to have some kind of proof of concept for how the certmonger 
integration could work. For what it's worth, that prototype is now 
available at [2].
>
> Anyway, the ultimate goal is to move the csrgen code to the server, 
> which means everything the helper will have to do is call a command 
> over RPC.
>
>>
>> - Tool to convert an XER-encoded cert extension to DER, given the ASN.1
>> description of the extension. This would unblock Jan Cholasta's idea of
>> using XSLT for templates rather than text-based formatting. I should be
>> able to implement the conversion tool, but it may be a while before I
>> have time to demo the full XSLT idea.
>
> Was there any progress on this?

I have started working on implementing it with asn1c, and I'm already 
seeing some of the inconvenience (security issues aside) of building on 
the server. Libtasn1 seems like a much better model, but doesn't seem to 
have XER support. Anyway, don't quite have results here yet but I think 
I should have the XER->DER demo with asn1c ready in a week or two.
>
>>
>> So: currently on my to do list are the certmonger helper and the
>> XER->DER conversion tool. Do you have any comments about these plans,
>> and is there anything else I can do to wrap up the project neatly?
>>
>> Thanks,
>> Ben
>>
>
> Honza
>
[1] https://github.com/LiptonB/freeipa-prototypes/blob/master/key2spki.c
[2] 
https://github.com/LiptonB/freeipa-prototypes/blob/master/cm_ipa_csrgen.c