[Freeipa-devel] V4/Sub-CAs review

Jan Cholasta jcholast at redhat.com
Mon May 9 06:54:32 UTC 2016


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.


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.


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>.

"""
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.

"""
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.


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?

The Python script bit sounds like an implementation detail rather than 
an actual design. Ideally the whole thing would be done in Java, right?

"""
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).

"""
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.


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".


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.

"""
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.

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?


Honza

-- 
Jan Cholasta




More information about the Freeipa-devel mailing list