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