[Pki-devel] [PATCH] Lightweight CAs

[Ade Lee]

On Fri, 2015-09-18 at 05:59 -0500, Endi Sukma Dewata wrote:
> On 9/14/2015 2:25 AM, Fraser Tweedale wrote:
> > The latest lightweight CAs (f.k.a. Sub-CAs) patches are attached.
> > This cut has significant changes and additions including:
> > 
> > - CAs are now stored in a flat structure with references to parents
> > 
> > - CAs are now identified by "AuthorityID" (which for now is a UUID
> >    underneath).  Many variables, method names and user-visible
> >    strings were updated accordingly.  Out with "caRef" terminology.
> > 
> > - "Sub-CA" terminology is (mostly) out; "Authority" is in.  This is
> >    to support lightweight CAs that are not descendents of top-level
> >    CA (which can be implemented later).
> > 
> > - ca-cert-request-submit command and related client / service
> >    classes were updated to add "authority" parameter
> > 
> > - Some more specific use of exception (including some new exception
> >    classes) to indicate / catch particular errors.
> > 
> > - More appropriate HTTP status codes return when client has send
> >    invalid data (400), referenced unknown authority (404) or 
> > attempts
> >    to create an authority with Subject DN already uesd by another
> >    authority (409 Conflict)
> > 
> > - LDAP entry now gets added before key generation and signing.  If
> >    something goes wrong, the DB entry is removed in the catch 
> > block.
> > 
> > There are still notable gaps in functionality that are in progress
> > or will be implemented soon:
> > 
> > - Audit log events
> > - Resources to enable/disable/delete authority
> > - Resources to access cert and pkcs7 chain of authority
> > - Keygen params
> > - Param to specify token on which to generate authority key
> > 
> > Thanks,
> > Fraser
> > 
> 
> Some comments:
> 
> 1. The db.ldif creates ou=subCAs instead of ou=authorities.
> 
yup -Fraser already knows about this one.

> 2. Is authority DN globally unique? If that's the case it can be used 
> as 
> a user-friendly representation of the UUID. We'll continue to use 
> UUID 
> for the LDAP entry DN and REST URL, but users don't really need to 
> see 
> it in the CLI (except in detailed output). So the CLI output can be 
> changed as follows:
> * Issuer DN/ID -> Authority DN
> * Parent ID -> Parent DN
> 
> I think "Issuer DN" is more appropriate to be used in the context of 
> a 
> certificate to refer to the authority that issued the certificate.
> 
I think I've been living in the openstack world too long, but I have no
objection to seeing UUIDs.  In fact, you need to see the UUID in order
to figure out what to put in for the authority ID when making a
request.  So, showing the ID is required.

> 3. Right now it's possible to create an authority with the same DN as 
> the main CA's DN (it created the LDAP entry, but later failed due to 
> nickname mismatch). If authority DN is unique, we shouldn't allow 
> that.
> 

agreed - we need to check for this.

> We can fix this by creating the main authority LDAP entry during 
> installation. It's not just for fixing this issue, but all 
> authorities 
> (including the top-level ones) should have the corresponding LDAP 
> entries.
> 
> 4. In CertificateAuthority.createCA() if no parent is specified, the 
> authority will be added as a subordinate of the main CA. I think 
> adding 
> an authority without parent should be reserved for top-level 
> authorities 
> which we may support in the future. For now the ca-authority-create 
> CLI 
> should require a parent. In #3 we're adding the main CA entry, so 
> there's always a parent.
> 
thats a great idea.  And yeah, we will eventually be considering
multiple top-level authorities.

> 5. In the CLI output, if the authority doesn't have a Parent ID it 
> shows 
> a "null". It would be better to show "None" instead, or just don't 
> show 
> the Parent ID at all.

I like parent ids, but null is not user friendly.

> 
> 6. Assuming authority DN is unique, we can add --issuer <DN> option 
> to 
> these commands:
> * pki ca-cert-find --issuer <dn>
> * pki ca-cert-request-submit --issuer <dn>
> * pki client-cert-find --issuer <dn>
> * pki client-cert-request --issuer <dn>
> 

If we do this, then we need to be sure that the DN is normalized - both
on input -- ie. when the subca is created (we need to do this in any
case) and also on processing in the CLI.

I'm ok with offering this as an option (maybe --issuer_dn), but the
primary (and initially required option) will be using UUID.  We can
defer this mechanism to another ticket/patch.  Please open one.

> 7. I think we should store authority DN and parent DN in the LDAP 
> entry 
> itself. This way we don't need to rely on the nickname and NSS 
> database 
> to figure out the DNs.
> 

agreed.

> 8. Right now the authority certs & keys are stored in the NSS 
> database. 
> I'm not sure about the scalability & manageability (e.g. replication, 
> orphaned keys). It might be OK for now, but if possible they should 
> be 
> stored (securely) in the LDAP entry itself or in KRA. We probably 
> only 
> need to store the certs & keys of the top-level authorities in the 
> NSS 
> database.
> 
This was a big discussion a few months ago, and it was decided then
that we were not comfortable with storing the keys in ldap.  We can
reconsider - but the mechanism of transferring keys is supposed to be
custodia.
 
9. To support paging in AuthorityService.listCAs() later you might want
> to use DataCollection because it provides the fields to put the total 
> results, the entries in the current page, and the paging links.
> 
agreed.