[Freeipa-devel] V4/Sub-CAs review

Tue May 10 10:36:17 UTC 2016

Honza, thanks for the review.  Comments inline.

Copy Nalin, re certmonger discussion at the very bottom.

On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:
> Hi,
> 
> 1)
> <http://www.freeipa.org/page/V4/Sub-CAs#Externally_signed_lightweight_CAs>
> 
> """
> The "upstream" root certificate and intermediate CA certificates would be
> stored in LDAP for distribution to clients, with the root CA having an
> ipaKeyTrust value of trusted and intermediate CAs having a value of unknown
> (see CA certificate renewal).
> """
> 
> Note that currently it's the IPA CA that is trusted by default, not any of
> the external (root or intermediate) CAs. I think it should stay this way, as
> we don't need to trust any of the external CAs for IPA to work correctly.
> 
Thanks for the clarification.  I updated the design page.  It is not
going to be in the initial implementation but good to know!

> 
> 2) <http://www.freeipa.org/page/V4/Sub-CAs#Sub-CA_plugin>
> 
> It should be mentioned here that the primary CA is also handled by this
> plugin.
> 
> I would like to propose two additional fields:
> 
>   * subject (required) - subject name of the CA, to be able to look up
> sub-CA that issued a certificate from its issuer name.
> 
>   * issuer_ca (optional) - name of the sub-CA which issued certificate for
> this CA, to have information about the sub-CA hierarchy. If there is no
> sub-CA entry for the issuer, it would be unset.
> 
These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?

> 
> 3) <http://www.freeipa.org/page/V4/Sub-CAs#Certificate_parameters>
> 
> """
> Subject Distinguished Name
> 
> When creating a sub-CA, the subject DN is constructed by copying the DN of
> the parent CA, then setting the CN to the name. More control could be
> implemented if there is a clear case for it.
> """
> 
> Note that adding the ability to override the CN in the subject name of the
> IPA CA certificate was requested a long time ago:
> <https://fedorahosted.org/freeipa/ticket/2614>.
>

This text was vestige of earlier design.  The DN is now completely
up to user and I updated the design accordingly.  (The validity of
the Subject DN *may* be subject to Name Constraints extension in
superior certs, but this is not checked).

> 
> """
> Validity
> 
> The default validity could be the default validity used by
> ipa-server-install. TODO what is the default duration?
> """
> 
> ATM the default duration is 10 years.
> 
Thanks, updated.

> """
> Specify the CA certificate validity. Something human-friendly should be
> used, e.g. a duration spec that supports 5y, 365d, etc. TODO is there a
> precendent for this sort of duration interpretation in FreeIPA? If so, be
> consistent.
> """
> 
> Currently there is (IIRC) only krbmaxticketlife (seconds) and
> krbmaxrenewableage (seconds) in the krbtpolicy plugin and krbmaxpwdlife
> (days) and krbminpwdlife (hours) in the pwpolicy plugin. If you are going to
> invent something generic, it would be nice if it worked for them as well.
> 
I've removed this part of the design for now, as it will not be in
initial implementation.

> 
> 4) <http://www.freeipa.org/page/V4/Sub-CAs#Key_replication>
> 
> """
> For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
> implements the KeyRetriever interface. It invokes a Python script that
> performs the retrieval, reusing existing FreeIPA Custodia client code.
> """
> 
> Will this be distributed with Dogtag or with IPA?
> 
It's shipped in Dogtag.

> The Python script bit sounds like an implementation detail rather than an
> actual design. Ideally the whole thing would be done in Java, right?
> 
I removed the script from the design page (it had changed, though
not dramatically).  It is written in Python so that we can reuse the
CustodiaClient.

> """
> The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
> and shall be executed as pkiuser.
> """
> 
> Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
> going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
> going to be distributed with IPA).
> 
What is the rationale - is it a packaging guideline or just common
sense?

> """
> pkiuser does not have read access to either of these locations, so a new
> service principal shall be created for each Dogtag CA instance for the
> purpose of authenticating to Custodia and retrieving lightweight CA private
> keys. Its principal name shall be dogtag-ipa-custodia/<hostname>@REALM. Its
> keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and
> mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and
> /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.
> """
> 
> Don't forget to update this paragraph with the new principal name.
> 
Thanks, I updated it.

> 
> 5) <http://www.freeipa.org/page/V4/Sub-CAs#Installation>
> 
> """
> A CA object for the top-level CA will initially be created, with DN
> cn=.,ou=cas,cn=ca,$SUFFIX.
> """
> 
> I would rather not use punctuation for the short name, as it can be easily
> overlooked (think logs). (Also it should be '/' if anything, not '.', which
> usually means "current".)
> 
> Above you stated that the subject name will be derived from the short name
> of the sub-CA. The top-level CA has subject name of the form "CN=Certificate
> Authority,$SUBJECT_BASE", so its short name should be "Certificate
> Authority".
> 

This section was also part of the old design.  The entry for the
host authority has ``ipaUniqueId=...`` as rightmost RDN, like other
CAs.  The cn is ``host-authority``.  Subject DN is no longer derived
from cn.

> 
> 6) <http://www.freeipa.org/page/V4/Sub-CAs#ipa_cert-find_.5Bshortname.5D>
> 
> """
> ipa ca-del <shortname>
> 
> Delete the given certificate authority. This will remove knowledge of the CA
> from the FreeIPA directory but will not delete the sub-CA from Dogtag.
> Dogtag will still know about the CA and the certificates it issued, be able
> to act at a CRL / OCSP authority for it, etc.
> """
> 
> What is the use case for this? Will the certificates issued by the sub-CA
> still be valid after delete or not? Will the sub-CA certificate be
> explicitly distrusted on delete or not?
> 
> IMO it should be possible to delete only a leaf sub-CA, i.e. anything but
> the top-level CA in the current design.
> 
> """
> ipa cert-find [shortname]
> 
> shortname
>      Optional positional parameter to specify a sub-CA to use (omit to
> specify the top-level CA). The special shortname * is used to search in all
> CAs.
> """
> 
> This should be "ipa cert-find [--ca=<shortname>]". At some point, cert-find
> should be fixed to be consistent with every other -find command and have an
> optional 'criteria' positional argument, and there can't be two optional
> positional arguments, as it creates an ambiguity.
> 
> I would prefer a separate argument (e.g. --all-cas, or --cacat=all) rather
> than a magic value for an all-CA search. Magic value might work for
> cert-find alone, but you are creating a precedent for the whole framework
> here.
>
Design updated.  No position arg anymore.  No special arg for "all
CAs" - it is implied unless one of ``--issuer=DN`` or ``--ca=NAME``
is given.

> 
> """
> ipa cert-show [shortname]
> 
> shortname
>      Optional positional parameter to specify a sub-CA (omit to specify the
> top-level CA).
> --chain
>      Request the certificate chain (when saving via --out <file>, PEM format
> is used; this is the format uesd for the end-entity certificate).
> """
> 
> This should be "ipa cert-show [--ca=<shortname>]", for consistency with
> cert-find, see above.
> 
Actually, we do not (at the moment) need a CA argument, because
serial numbers are unique in the whole Dogtag instance.  I have
removed the argument but if it makes a comeback in future, it will
be in the form you recommend.

> IMO it would make sense to add --chain to cert-request as well, it should be
> useful for certmonger.
> 
> 
> 7) <http://www.freeipa.org/page/V4/Sub-CAs#Certmonger>
> 
> How is a certificate going to be requested from a specific sub-CA using the
> getcert command?
> 
I added a preliminary design; add a new certmonger property and
corresponding getcert-request(1) option for specifying the target
CA.

http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA

Alternative approaches involve overloading an existing property
(e.g. profile) to optionally carry both profile and CA.  The
overloading could be handled in Certmonger or in FreeIPA.  Either
way is feasible - both are nasty hacks! - but it is worth mentioning
the alternatives.

Cheers,
Fraser