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

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.

to use DataCollection because it provides the fields to put the total results, the entries in the current page, and the paging links.

Latest patches attached. Relative to previous patchset this one: - fixes a compile error in CATest.java - fixes a ton of warnings and some poorly ordered imports - adds ACLs and ACL enforcement for privileged operations on AuthorityResource Here's an ldif snippet for adding the ACLs to an existing database dn: cn=aclResources,o=ipaca changetype: modify add: resourceACLS resourceACLS: certServer.ca.authorities:list,read:allow (list,read) user="anybody":Anybody may list and read lightweight authorities resourceACLS: certServer.ca.authorities:create,modify:allow (create,modify) group="Administrators":Administrators may create and modify lightweight authorities Cheers, Fraser

Latest patches attached. Most issued addressed; see inline for comments and ticket URLs for deferred items. There is a problem with allowing authority DNs to be reused - when adding the cert to the NSSDB, despite what nickname you tell it to you, it will put the cert under the nickname of the existing cert with that subject DN. Thus when you go to find the cert by nickname, it cannot locate it. Failure ensues. This is possibly a bug in NSS (it's certainly surprising), but I need more time to analyse it. I've attached an experimental (builds, but as yet completely untested with high chance of brokens) patch on top of my current patches that switches to looking up the cert by issuer DN and serial. I need to consider implications of this switch including for renewal in replicated environments. It might not be the right approach but afaict it is the only other way CryptoManager gives you to look up a cert. Ideally we discover that NSS/JSS is doing the wrong thing with what it is doing with nicknames and we can get a fix there are move on with life. Anyhow, other comments inline. Thanks, Fraser On Thu, Sep 24, 2015 at 06:26:39PM -0500, Endi Sukma Dewata wrote: > Some comments: > > 1. Right now the create & modify operations over non-secure URL > will fail: > > $ pki -d ~/.dogtag/pki-tomcat/ca/alias -c Secret123 -n caadmin > ca-authority-create o=test --parent 85a2c5c2-869d-467c-9adf > -dcc34367e836 > ForbiddenException: No user principal provided. > > It works with the secure URL: > > $ pki -U https://$HOSTNAME:8443 -d ~/.dogtag/pki-tomcat/ca/alias -u > caadmin > -w Secret123 ca-authority-create o=test --parent > 85a2c5c2-869d-467c-9adf-dcc34367e836 > Authority DN: O=test > ID: 14004c0f-3531-49c2-ae7a-99f715af7cc4 > Parent DN: 85a2c5c2-869d-467c-9adf-dcc34367e836 > Enabled: true > > This can be fixed by adding <security-constraint> into the web.xml > and > registering it in auth-method.properties. > Thanks for this explanation. Worked a treat! > 2. The "Parent DN" field in the output above should show the DN of > the > parent authority instead of the ID. We probably should show both > Parent DN > and Parent ID. > Fixed the label, filed ticket for including the Parent/Issuer DN: https://fedorahosted.org/pki/ticket/1618 > 3. Per discussion with alee, we need a way to find the host/main CA > using > something like: > > $ pki ca-authority-show --host-authority > Done. > 4. I think we also need a way to translate a DN into ID: > > $ pki ca-authority-show --dn <DN> > Filed ticket: https://fedorahosted.org/pki/ticket/1617 > 5. Also per discussion with alee, the authority DN should be unique > only > among active CAs. So you should be able to create a CA, disable it, > then > create another one with the same DN. If you try to enable the old > CA it > should fail. This can be implemented later. > Per discussion above, implemented, but breaks your CA if you try it! > 6. In AuthorityData.java the @XmlRootElement probably should be > changed to > "authority" for consistency. Also the following fields can be > renamed > because the "a" is redundant: > * aid -> id > * parentAID -> parentID > I think the XML output will look better that way. > Done. > 7. The method description in ISigningUnit.java doesn't match the > method name > (public vs. private). > Fixed; well spotted. > I think these are not difficult to fix, and once fixed it should be > sufficient to push as initial implementation, so consider this a > conditional > ACK (unless alee has other comments). Item #5 (or #4 too) can be > implemented > later. > > I also created this page to document the CLI: > http://pki.fedoraproject.org/wiki/PKI_CA_Authority_CLI > Feel free to expand it further. > Thanks a bunch; I will review this Monday. This also reminds me to spend some time updating the design pages as well - there have been many changes!

On Fri, Sep 25, 2015 at 02:41:30PM -0400, Ade Lee wrote: > I'm inclined to not allow reuse of DNs until we can figure this out. > If we can't, then we need to add the DELETE functionality. > I'll reinstate the previous restriction and merge the patches.

Investigation of the issue and possible solutions to continue next week. For now, during testing if you really need to reuse a DN you'll have to ldapdelete the entry and delete the corresponding certificate from the NSSDB. Cheers, Fraser > Ade > > On Fri, 2015-09-25 at 23:30 +1000, Fraser Tweedale wrote: > > Latest patches attached. Most issued addressed; see inline for > > comments and ticket URLs for deferred items. > > > > There is a problem with allowing authority DNs to be reused - when > > adding the cert to the NSSDB, despite what nickname you tell it to > > you, it will put the cert under the nickname of the existing cert > > with that subject DN. Thus when you go to find the cert by > > nickname, it cannot locate it. Failure ensues. This is possibly a > > bug in NSS (it's certainly surprising), but I need more time to > > analyse it. > > > > I've attached an experimental (builds, but as yet completely > > untested with high chance of brokens) patch on top of my current > > patches that switches to looking up the cert by issuer DN and > > serial. I need to consider implications of this switch including > > for renewal in replicated environments. It might not be the right > > approach but afaict it is the only other way CryptoManager gives you > > to look up a cert. > > > > Ideally we discover that NSS/JSS is doing the wrong thing with what > > it is doing with nicknames and we can get a fix there are move on > > with life. > > > > Anyhow, other comments inline. > > > > Thanks, > > Fraser > > > > On Thu, Sep 24, 2015 at 06:26:39PM -0500, Endi Sukma Dewata wrote: > > > Some comments: > > > > > > 1. Right now the create & modify operations over non-secure URL > > > will fail: > > > > > > $ pki -d ~/.dogtag/pki-tomcat/ca/alias -c Secret123 -n caadmin > > > ca-authority-create o=test --parent 85a2c5c2-869d-467c-9adf > > > -dcc34367e836 > > > ForbiddenException: No user principal provided. > > > > > > It works with the secure URL: > > > > > > $ pki -U https://$HOSTNAME:8443 -d ~/.dogtag/pki-tomcat/ca/alias -u > > > caadmin > > > -w Secret123 ca-authority-create o=test --parent > > > 85a2c5c2-869d-467c-9adf-dcc34367e836 > > > Authority DN: O=test > > > ID: 14004c0f-3531-49c2-ae7a-99f715af7cc4 > > > Parent DN: 85a2c5c2-869d-467c-9adf-dcc34367e836 > > > Enabled: true > > > > > > This can be fixed by adding <security-constraint> into the web.xml > > > and > > > registering it in auth-method.properties. > > > > > Thanks for this explanation. Worked a treat! > > > > > 2. The "Parent DN" field in the output above should show the DN of > > > the > > > parent authority instead of the ID. We probably should show both > > > Parent DN > > > and Parent ID. > > > > > Fixed the label, filed ticket for including the Parent/Issuer DN: > > https://fedorahosted.org/pki/ticket/1618 > > > > > 3. Per discussion with alee, we need a way to find the host/main CA > > > using > > > something like: > > > > > > $ pki ca-authority-show --host-authority > > > > > Done. > > > > > 4. I think we also need a way to translate a DN into ID: > > > > > > $ pki ca-authority-show --dn <DN> > > > > > Filed ticket: https://fedorahosted.org/pki/ticket/1617 > > > > > 5. Also per discussion with alee, the authority DN should be unique > > > only > > > among active CAs. So you should be able to create a CA, disable it, > > > then > > > create another one with the same DN. If you try to enable the old > > > CA it > > > should fail. This can be implemented later. > > > > > Per discussion above, implemented, but breaks your CA if you try it! > > > > > 6. In AuthorityData.java the @XmlRootElement probably should be > > > changed to > > > "authority" for consistency. Also the following fields can be > > > renamed > > > because the "a" is redundant: > > > * aid -> id > > > * parentAID -> parentID > > > I think the XML output will look better that way. > > > > > Done. > > > > > 7. The method description in ISigningUnit.java doesn't match the > > > method name > > > (public vs. private). > > > > > Fixed; well spotted. > > > > > I think these are not difficult to fix, and once fixed it should be > > > sufficient to push as initial implementation, so consider this a > > > conditional > > > ACK (unless alee has other comments). Item #5 (or #4 too) can be > > > implemented > > > later. > > > > > > I also created this page to document the CLI: > > > http://pki.fedoraproject.org/wiki/PKI_CA_Authority_CLI > > > Feel free to expand it further. > > > > > Thanks a bunch; I will review this Monday. This also reminds me to > > spend some time updating the design pages as well - there have been > > many changes! > > _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel