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.