[Pki-devel] [PATCH] Lightweight CAs

Sat Sep 26 04:14:56 UTC 2015

On Sat, Sep 26, 2015 at 12:30:02PM +1000, Fraser Tweedale wrote:
> 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.
>
Pushed to master:

058f1cf Lightweight CAs: REST cert request param to specify authority
5cdad30 Lightweight CAs: add ca-authority CLI
2a9f56d Lightweight CAs: initial support

Cheers,
Fraser

> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel