[Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

Fri Jul 8 10:57:13 UTC 2016

On 07/08/2016 05:42 AM, Fraser Tweedale wrote:
> On Thu, Jul 07, 2016 at 04:10:51PM +0200, Sebastian Hetze wrote:
>>
>> On 07/07/2016 03:16 PM, Rob Crittenden wrote:
>>> Sebastian Hetze wrote:
>>>> Hi *
>>>>
>>>> attached you find a patch that adds new options --subject_cn and
>>>> --subject_mail to ipa-server-install that make the CA cert subject CN
>>>> customizable.
>>>>
>>>> This patch has been tested by a customer in a PoC.
>>>> However, i assume additional testing in different environments is
>>>> required.
>>>>
>>>> It would be greatly appreciated if this patch would find its way into
>>>> the product very soon.
>>> I don't see the advantage of passing around the subject_rdn along with
>>> the base. Why not pre-combine them into a DN?
>> Think of the subject_rdn as given name for the CA cert and the
>> subject_base as family name for all subsequent service certs that IPA
>> automatically generates and signs. While the given names for the
>> generated service certs may stay hard coded, only the given name for the
>> CA cert needs to be customizable as requested in the RFE.
>> Look into the source and you will see that subject_base is used all over
>> the place and subject_rdn (as replacement for the hard coded
>> "CN=Certificate Authority") only related to the CA cert. They need to be
>> kept separate.
>>
> In your patch, subject_rdn is used in few places where it is passed
> around.  I agree with Rob; in the handful of places where the full
> DN is formed (currently by prepending "CN=Certificate Authority"),
> we should pass in the full DN.
I understand you have two objections: first the "passing around" of the
subject_rdn and second the additional command line options.

The "passing around" is required unless you decompose the "subject_base"
wherever it is used today. The name subject_base is chosen for a reason,
it is just the base of the subject DN. It is used all over the place,
not only for the CA cert.

So yes, it would be possible to rename subject_base to cacert_subject
and decompose the DN on every occurance of subject_base in the code.

    subject_rdn,subject_base = decompose_cacert_subject(cacert_subject)

Is this really an improvement to passing the parameter only to those
places where it is required?
I dont think so.

If passing around an additional parameter is a problem, I would rather
prefer to pass subject{_base,_ca_rdn,_audit_rdn,_ra_rdn} as a dictionary
instead of a string and possibly allow other certificate subjects to be
customized if this is required by a customer some time in the future.
But this again would require to change the code everywhere where
subject_base is currently used.

The current RFE (and my customer) only requests the CA cert subject to
be customizable.

>
>>>
>>> Similarly, I think I'd drop storing the subject base and RDN and just
>>> store just the DN. I don't think there would be any backwards compat
>>> issues as this would only apply to new installs.
>>>
>>> I think this would explode the number of options as users request
>>> additional attributes for the subject (OU, C, etc). Might be better to
>>> make the user pass in a full DN if they want to manage the CA subject.
>>> I don't know if any validation would be required for dogtag (e.g. is
>>> there a minimum set of components needed?)
>> CN is mandatory and only emailAddress is a commonly used option for the
>> "given name" subject_rdn. OU, C and alike belong to the subject_base.
>>
> Let us not add new arguments.  We should enhance --subject instead.
>
> Existing behaviour:
>
>     - ``--subject`` gives subject base.  If not given, defaults to
>       "O=$REALM".
>
>     - "CN=Certificate Authority" prepended to subject base to form
>       full subject DN.
>
>     - Dogtag requires that the CA Subject DN starts with CN.
>
> My proposal for augmented behaviour:
>
>     - If ``--subject`` not given, existing behaviour retained.
>
>     - If ``--subject`` supplied:
>
>       1. Extract O, OU, C, L, ST and DC components from argument
>       (order preserved) to form the subject base.  If argument
>       contains none of these attributes, subject base is defaulted
>       to "O=$REALM" (per current behaviour) and appended to the CA
>       Subject DN.
Actually, when using an external_ca you may rather want the subject to
be forced into the canonical order.
The AD PKI does this when signing the ipa.csr. That is: you need to pass
the subject in canonical order in the first place to receive a signed
cacert from AD that matches the requests subject.
I don't suggest such an behaviour, but you should not assume the order
of attributes in the base DN has no meaning just because dogtag ignores it.
>
>       2. If argument contains CN but it is not the "most specific"
>       RDN, move it to the front (to satisfy requirement of Dogtag
>       profile).
It is quite common to have the emailAddress as additional attribute in
the subject and if it exists it is always the most specific, followed by
the CN. The patch I am proposing works apparently with freeipa. So what
is this requirement you mention?

>
>       3. If argument does not contain CN, prepend "CN=Certificate
>       Authortiy" per existing behaviour.
>
>       4. Apart from (1), (2) and (3), CA Subject DN stays otherwise
>       unchanged, therefore Email Address (E) is supported.
As I said, the AD PKI does re-order the attributes. While you may argue
that it should not do that, this is reality for all of our customers
using that product. And the whole purpose of this RFE and my proposed
patch is to enable our customers to work with freeipa in an highly
regulated environment with specific requirements regarding the subject
of a CA cert, regardless what superodinate PKI the customer uses.
>
> Sebastian, would this scheme meet your customer's requirements?
With your proposal, a subject would look like this:
Subject: CN=Custom CA Name,E=caadmin at example.com,OU=Example IT,O=Example
Corp,L=City,ST=State,C=US

I will check with my customer if this can possibly be signed by the AD
PKI, and if that works what the ordering looks like after signing.

Just to indicate how weird that ordering is, observe how OpenSSL will
display that subject:
Subject: C=US,ST=State,L=City,O=Example Corp,OU=Example
IT/emailAddress=caadmin at example.com,CN=Custom CA Name
instead of the usual
Subject: C=US,ST=State,L=City,O=Example Corp,OU=Example IT,CN=Custom CA
Name/emailAddress=caadmin at example.com

Unless there is a strong feedback from other users/customers supporting
that unconventional ordering, I am against such an implementation.

>
> I also note, in your patch, that you define method
> DsInstance.find_subject_rdn() but it is not used.  What is the
> purpose of this method?
There is a method DsInstance.find_subject_base. The find_subject_rdn has
exactly the same purpose.
While I did get along without using it so far, I expect it to be
required somewhere down the line the very same way find_subject_base is
used today.
If your testing finds the patch works perfect in all possible occasions,
this new method should be removed.

>
> Thank you for providing this patch and pushing forward on this RFE.
> If you are happy with my above proposal I'm happy to take ownership
> and get this over this line.
>
> Cheers,
> Fraser
>
>>> rob
>> Beste Grüße / Best regards
>>   Sebastian Hetze
>> -- 
>> Senior Solution Architect
>> Red Hat GmbH. Niederlassung Berlin
>> Am Treptower Park 75 12435 Berlin
>> Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205
>> Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com
>>
>> -- 
>> Manage your subscription for the Freeipa-devel mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Beste Grüße / Best regards
  Sebastian Hetze
-- 
Senior Solution Architect
Red Hat GmbH. Niederlassung Berlin
Am Treptower Park 75 12435 Berlin
Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205
Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com