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

[Ben Lipton]

Hi,

Thanks very much for the feedback! Some responses below; I hope you'll 
let me know what you think of my reasoning.


On 07/20/2016 04:20 AM, Jan Cholasta wrote:
> Hi,
>
> On 17.6.2016 00:06, Ben Lipton wrote:
>> On 06/14/2016 08:27 AM, Ben Lipton wrote:
>>> Hello all,
>>>
>>> I have written up a design proposal for making certificate requests
>>> easier to generate when using alternate certificate profiles:
>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. 
>>>
>>> The use case for this is described in
>>> https://fedorahosted.org/freeipa/ticket/4899. I will be working on
>>> implementing this design over the next couple of months. If you have
>>> the time and interest, please take a look and share any comments or
>>> concerns that you have.
>>>
>>> Thanks!
>>>
>>> Ben
>>>
>> Just a quick update to say that I've created a new document that covers
>> the proposed schema additions in a more descriptive way (with diagrams!)
>> I'm very new to developing with LDAP, so some more experienced eyes on
>> the proposal would be very helpful, even if you don't have time to
>> absorb the full design. Please take a look at
>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema 
>>
>> if you have a chance.
>
> I finally had a chance to take a look at this, here are some comments:
>
> 1) I don't like how transformation rules are tied to a particular 
> helper and have to be duplicated for each of them. They should be 
> generic and work with any helper, as helpers are just an 
> implementation detail and their resulting data is the same.
>
> In fact, I think I would prefer if the CSR was generated using 
> python-cryptography's CertificateSigningRequestBuilder [1] rather than 
> openssl or certutil or any other command line tool.
>
There are lots of tools that users might want to use to manage their 
private keys, so I don't know if we can assume that whatever library we 
prefer will actually be able to access the private key to sign a CSR, 
which is why I thought it would be useful to support more than one. The 
purpose of the mapping rule is to tie together the transformation rules 
that produce the same data into an object that's 
implementation-agnostic, so that profiles referencing those rules are 
automatically compatible with all the helper options.

I do agree that it would be preferable to target APIs rather than 
command-line tools. When looking at the openSSL and NSS APIs I came to 
the conclusion that they would be more difficult than the command-line 
tools to target, as a first implementation. However, I haven't really 
looked at python-cryptography, and maybe it would have been a good choice.
>
> 2) The schema seems unnecessarily complex. I think all we need is a 
> single new multi-value attribute in certprofile. For your S/MIME 
> example, it could be something like:
>
>     attr: subjectname=CN={subject.cn},{subject_base}
>     attr: san_rfc822name={subject.email}
>     attr: san_directoryname={subject.dn}

This is turning out to be a common (and, I think, reasonable) reaction 
to the proposal. It is rather complex, and I worry that it will be 
difficult to configure. On the other hand, there is some hidden 
complexity to enabling a simpler config format, as well. One of the 
goals of the project as it was presented to me was to allow the creation 
of profiles that add certificate extensions *that FreeIPA doesn't yet 
know about*. With the current proposal, one only has to add a rule 
generating text that the helper will understand. With your suggestion, 
if there's a mapping between "san_directoryname" and the corresponding 
API calls or configuration lines, we need some way for users to augment 
that mapping without changing the code. If there's no mapping, and it's 
just done with text processing, we need enough in the config format to 
be able to generate fairly complex structures:

builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM'))
builder = 
builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), 
x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False)

and we need to do it without it being equivalent to calling eval() on 
the config attributes. I'm not sure how to achieve this (is it safe to 
call getattr(x509, extensiontype)(value) where extensiontype and value 
are user-specified?) and it definitely would have to be tied to a 
particular library/tool.

Ben
>
>
> Honza
>
> [1] 
> <https://cryptography.io/en/latest/x509/reference/#x-509-csr-certificate-signing-request-builder-object>
>