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

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Jan Cholasta wrote:
>On 20.7.2016 16:05, Ben Lipton wrote:
>>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.
>
>python-cryptography has the notion of backends, which allow it to 
>support multiple crypto implementations. Upstream it currently 
>supports only OpenSSL [2], but some work has been done on PKCS#11 
>backend [3], which provides support for HSMs and soft-tokens (like NSS 
>databases).
>
>Alternatively, for NSS databases (and other "simple" cases), you can 
>generate the private key with python-cryptography using the default 
>backend, export it to a file and import the file to the target 
>database, so you don't actually need the PKCS#11 backend for them.
>
>So, the only thing that's currently lacking is HSM support, but given 
>that we don't support HSMs in IPA nor in certmonger, I don't think 
>it's an issue for now.
>
>>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.
>
>They are implementation-agnostic, as long as you consider `openssl` 
>and `certutil` the only implementations :-) But I don't think this 
>solution scales well to other possible implementations.
>
>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).
This is a good point. However, for the scope of Ben's project can we
limit it by openssl and certutil support? Otherwise Ben wouldn't be able
to complete the project in time.

>>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.
>
>... which will be possible only as long as the helper understands the 
>extension. Which it might not, thus the current proposal works only 
>for *some* extensions that FreeIPA doesn't yet support.
We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well. The idea with unknown extensions was to allow mapping
their acceptance to a specific relationship between IPA objects
(optionally) and an input from the CSR. A simplest example would be an
identity rule that would copy an ASN.1 encoded content from the CSR to
the certificate.

That's on the mapping side, not on the CSR generation side, but it would
go similarly for the CSR if you would be able to enter unknown but
otherwise correct ASN.1 stream. There is no difference at which helper
type we are talking about because all of them support inserting ASN.1
content.

>>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.
>
>As I pointed out above, this needs to be figured out for the generic 
>case for both the current proposal and my suggestion.
>
>OTOH, I think we could use GSER encoding of the extension value:
>
>    { rfc822Name:"user at example.com", 
>directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" }
GSER is not really used widely and does not have standardized encoding
rules beyond its own definition. If you want to allow transformation
rules in GSER that mention existing content in IPA objects, you would
need to deal with templating anyway. At this point it becomes irrelevant
what you are templating, though.

-- 
/ Alexander Bokovoy