[Pki-devel] [PATCH] Lightweight CAs

[Fraser Tweedale]

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!
> >