[Freeipa-devel] V4/Sub-CAs review

[Fraser Tweedale]

Christian, thank you for the review.

Responses inline.  I will update the design page soon with
clarifications and information about backup.

On Tue, Apr 19, 2016 at 01:24:54PM +0200, Christian Heimes wrote:
> Hi Fraser,
> 
> I'm the reviewer for your Sub-CAs and RFC 2818 designs. Let's start with
> Sub-CAs first. http://www.freeipa.org/page/V4/Sub-CAs
> 
> In general the design is well written -- accurate as usual. I didn't
> want to ACK the design with a simple LGTM, so I put myself in the
> position of a customer and potential user of Sub-CAs. From the end-users
> perspective couple of points in the design doc are either unclear or are
> not addressed details.
> 
> 
> 1) How can I restrict a Sub-CA to a specific key usage or DNS suffix?
> 
> The design doc mentions a comment from the puppet community or the
> possibility to use a SubCA for short-lived certs for VPN authentication.
> As a customer I would like to restrict the KU, EKU and maybe name
> constraints, e.g. a SubCA for hosts should be limited to EKU "TLS
> webserver auth". Would it be possible to use a custom profile to
> generate a SubCA and let users select the profile in ipa ca-add?
> 
For things that go in EE cert, specify the target sub-CA in addition
an appropriate profile.  (More on that below).

For things that go in CA cert (e.g. NameConstraints) - not an
initial requirement but definitely a nice-to-have - a
special-purpose profile is needed.  Such profiles can be
added/managed via the `certprofile' plugin.  Dogtag will have to be
updated to provide the means of specifying an alternative profile
when creating the CA (see ticket[1]), and the means of conveying any
data required.  These options will be reflected in the ca-add
options.

[1] https://fedorahosted.org/pki/ticket/1338


> 2) What is the relationship between Sub-CAs and profiles?
> 
> From the design doc it is unclear how cert profiles and Sub-CAs
> interact. The certificate profile doc has
> http://www.freeipa.org/page/V4/Certificate_Profiles#Schema_2, but that's
> too technical. I'm not even sure I fully understand the meaning of the
> schema and how memberCa affects profiles.
> 
tl;dr profiles and authorities don't affect each other, but caacls
determine which profiles and authorities can be used together, for
which subject principals.

CA ACLs currently determine which profiles can be used with which
subject principals.  With Lightweight CAs, CA ACLs are expanded in
scope to also include which CA(s) can be used with which profiles
for a particular subject principal.

This is what the memberCa attribute of the caacl object class
accomplishes.  A single caacl rule allows specified (or all)
profiles to be used by specified (or all - if caCategory=all) CAs to
issue certificates to specified principals or principal types.

> 
> 3) How can I make FreeIPA use a specific Sub-CA in a cert request?
> 
> IMO a 1:n relationship between CAs and profiles would make sense. That
> way ipa cert-request --profile-id=caVPNCert could automatically select
> the VPN Sub-CA.
> 
Simply supply the ``--ca <id>`` option.
http://www.freeipa.org/page/V4/Sub-CAs#ipa_cert-request

Your suggestion about a default sub-CA for a profile is interesting.
We still need the option to specify both CA and profile but it is
good UX becaues it will cover many use cases.  I filed a ticket[2].

[2] https://fedorahosted.org/freeipa/ticket/5836

> 
> 4) Where is the private key of a Sub-CAs stored locally and how is it
> secured?

> Customers will like to know where Dogtag keeps its crown jewels and how
> they are secured.
> 
Stored in the NSSDB.  For key replication, Custodia transports the
key wrapped by the signing key of the "host authority" (i.e. the CA
that Dogtag was installed with).  There's a ticket for HSM
support[3] but FreeIPA doesn't support HSM yet, anyway.

[3] https://fedorahosted.org/pki/ticket/2292

> 
> 5) What is the backup and export strategy for a Sub-CA private key?
> 
> Similar to 4), customers want to backup the private keys.
> 
I'll look at what the main IPA backup process does.  If it already
backs up the whole of /etc/pki/pki-tomcat/alias, we're good.  If
not, I'll extend it to include whatever is needed.

> 
> Christian
>