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

[Ben Lipton]

On 07/25/2016 08:12 AM, Alexander Bokovoy wrote:
> On Mon, 25 Jul 2016, Jan Cholasta wrote:
>>>>> 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.
>>
>> My point was that the current proposal is not any better than my 
>> proposal in this regard, as neither of them allows one to use an 
>> arbitrary extension.
> That's true. One of arguments for supporting openssl format was to allow
> people to generate CSRs themselves later. E.g. it would be a stepping
> stone to some automation around certificates to those who need it.
> Turning everything into python-cryptography has less benefit in this
> context.
>
>>> 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.
Along similar lines, on the CSR generation side, certutil has an 
--extGeneric flag, and openssl also has an "ARBITRARY EXTENSIONS" 
feature described in x509v3_config(5). I'm guessing that generating 
those configs automatically would be a bit beyond the current feature 
set of jinja2, but when we allow the requester to specify contents for 
some of the data fields it should be possible to build ok automation 
around that.
>>>
>>>>> 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.
>>
>> True, but the goal here is not to avoid templating, but rather to 
>> avoid implementation-specific bits on the server, and GSER is the 
>> only thing that is textual, implementation-neutral and, as a bonus, 
>> standardized.
> If we move these bits to the client, the only thing server will need to
> deal with is CSR. The client then would definitely need to have ability
> to provide alternative CSR sources (e.g. openssl text format) to aid
> API users that don't utilize IPA tools directly. At this point GSER use
> is irrelevant either.
The GSER format is new to me, but I don't see any particular reason the 
existing design would not be able to produce this format. But: is there 
an existing library that allows creating a CSR from a GSER description? 
If our goal is to provide an easy way to create certificates according 
to a particular profile, and the CSR is still our main way to provide 
that data to the IPA cert-request feature, we need to be able to build 
that CSR. If we have a client that accepts GSER and has at least the CSR 
generation features we need, then maybe we don't need support for 
generating the other formats anymore.