5:59 a.m.
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