[Pki-devel] [PATCH] Lightweight CAs

[Ade Lee]

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.

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