[Pki-devel] [PATCH] Lightweight CAs

[Endi Sukma Dewata]

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.

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.

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.

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.

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.

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>

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.

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.

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.

-- 
Endi S. Dewata