[Pki-devel] [PATCH] 0026-5, 0044-3 Lightweight sub-CAs

Fri Aug 28 04:37:19 UTC 2015

On Thu, Aug 27, 2015 at 10:54:14AM -0400, Ade Lee wrote:
> One other thing to consider.
> 
> Endi suggested that it might be nice to have the UUID generated by the
> database.  One way to do this would be make use of the 389's DNA
> plugin.  As we do not expect too many of these subCAs to be created,
> this might work well.
> 
Too bad it appears 389ds does not support the 'entryUUID' attribute
defined in https://tools.ietf.org/html/rfc4530.  Seems that it would
be a good fit.

> Using DNA would ensure that all replicas would generate different IDs,
> and would prevent us having to make a database query to confirm that an
> ID has no longer been used.
> 
If we generate version 4 (pseudorandom) UUID, is the likelihood that
different replicas could generate the same UUID even worth worrying
about?

> On the other hand, this might be harder to set up than simply using
> java.util.UUID, and may require configuration changes on the DS.
> 
> For the first iteration, to unblock me so that I can start writing
> clients and testing, we can use something simple.  In a following
> iteration, we can look into DNA.
> 
> In fact, you can hide these details in a UUID Generator interface which
> we can switch out later.
> 
I agree on using java.util.UUID for first cut; interface makes good
sense.

> Ade
> 
> 
> On Thu, 2015-08-27 at 10:22 -0400, Ade Lee wrote:
> > On Thu, 2015-08-27 at 17:22 +1000, Fraser Tweedale wrote:
> > > On Wed, Aug 26, 2015 at 11:09:24AM -0400, Ade Lee wrote:
> > > > Some more comments to clarify my concerns on the use of 
> > > > hierarchical
> > > > urls as the identifier for subcas.
> > > > 
> > > > This is the "usual" way (ie. for example OpenStack) REST 
> > > > interfaces 
> > > > are
> > > > defined:
> > > > 
> > > > POST /subcas  -- creates a subca and returns the reference
> > > > /subcas/{uuid}
> > > > 
> > > > POST /subcas/ -- POST includes 
> > > > "parent_ref"=http://../subcas/{uuid}" ; 
> > > >    returns a subca that has the relevant parent
> > > > 
> > > Full URL reference mandatory here?  Preferable?  Much-of-a
> > > -muchness?
> > > Would a plain UUID suffice?
> > 
> > > If URL is the way to go here, is it necessary to ensure that the
> > > host:port refers to "this" server, or can we just ignore the front
> > > matter and go straight to looking up the UUID?
> > > 
> > I used full URL reference here because of my experience with 
> > OpenStack,
> > where systems can be federated across multiple domains.  Using URLs 
> > for
> > all references is de rigueur there.  I do not expect us to be 
> > federated
> > in the same way, and we tend to use plain ids everywhere in the API
> > now.  Lets use a plain ID.
> >  
> > > > GET /subcas  -- list all subcas
> > > > 
> > > > GET /subcas/{uuid}  - get details on subca.
> > > > 
> > > > GET /subcas/{uuid}/subcas -- list subcas for subca {uuid}
> > > > 
> > > > 
> > > > An alternate formulation could also be:
> > > > 
> > > > POST /subcas/{uuid}/subcas 
> > > > -- creates subca with subca {uuid} as parent.
> > > > 
> > > > I don't like this as much because its a little less standard. 
> > > >  The
> > > > resulting resource would be /subcas/{uuid2} rather than
> > > > /subcas/{uuid}/subcas/{uuid2}
> > > > 
> > Lets not use the above alternative formulation.  It is as suggested 
> > non
> > -standard and therefore less intuitive.
> > 
> > > >  
> > > > Now, I hate uuids.  I mean whats not to love about "2a549393-0710
> > > > -444b
> > > > -8aa5-84cf0f85ea79" ?  It just rolls off the tongue.
> > > > 
> > > > Everyone hates uuids but thats actually an advantage, rather than 
> > > > a
> > > > weakness in that no one possibly would want to change the URL.
> > > > 
> > > Great wisdom!
> > > 
> > > > Handles on the other hand - are subject to all kinds of bike 
> > > > shedding. 
> > > >  Do I use something like "ca1", "ca2"?  Thats no better than a 
> > > > UUID 
> > > > in
> > > > terms of semantic content.  How about org references? 
> > > >  "foo_it_dept",
> > > > "bar_domain"?  Uh oh, what if I decide later I didn't like my 
> > > > handle? 
> > > >  What if there is an org rename?  Or a reorg?  Remember, certs 
> > > > can
> > > > potentially live a long time.
> > > > 
> > > > And what if I'm really perverse and use the handle "subcas" -- 
> > > > aargh!
> > > > now I've broken one of the possible paths above.  Or I might end 
> > > > up
> > > > breaking a path we'll add in future.
> > > > 
> > > > No - the only way to keep this straight is to have the resource
> > > > identifier be something unique that no one will want to change -- 
> > > > like
> > > > /subcas/{uuid} - and have some kind of alias system for that 
> > > > subca 
> > > > that
> > > > can be changed at will.
> > > > 
> > > > That mapping could be kept in IPA or Barbican database for 
> > > > instance,
> > > > rather that in dogtag itself.
> > > > 
> > > Yep.  Unless you need it for feel strongly otherwise, we can avoid
> > > implementing the alias indirection in initial feature.  Certainly 
> > > it
> > > is not needed for IPA use case.
> > > 
> > Agreed.  Aliases can come later (if ever).
> > 
> > > > We can also do what we did for secrets
> > > > and allow the user to define a "client nickname" as part of the 
> > > > subca
> > > > record.  This is a field that can later be searched for or 
> > > > changed.
> > > > 
> > > > As for hierachical-ness, flatter is easier to understand and 
> > > > maintain.
> > > > 
> > > Fair enough.  I will implement the scheme proposed above.  Thank 
> > > you
> > > for your input!  Hope to have a new patchset tomorrow or early next
> > > week.
> > > 
> > Excellent.  Also, while we want to keep the hierarchy flat, we do 
> > want
> > to keep track of which CA/subCA is the parent CA in the CA record. 
> >  This should probably be the plain ID of the parent CA.  On the other
> > hand, we want to return this to the client as a fully formed URL. 
> >  Its
> > the HATEOAS thing to do.
> > 
> > Looking forward to the patches.
> > 
> > Ade
> > > > 
> > > > Ade
> > > > 
> > > > On Wed, 2015-08-26 at 02:09 -0400, Ade Lee wrote:
> > > > > Some more thoughts.
> > > > > 
> > > > > First off, there are things that should be included with the 
> > > > > CAData 
> > > > > for
> > > > > each subsystem.
> > > > > 
> > > > > 1. CA signing cert (or more likely a reference to the ca cert)
> > > > > 2. pkcs7 chain (again this is something that could/should 
> > > > > likely 
> > > > > be a
> > > > > reference)
> > > > > 3. status - ie. enabled/disabled.
> > > > > 4. Description -- user defined description.
> > > > > 
> > > > > For the motivation for (30 status, we do need to consider what 
> > > > > we 
> > > > > want
> > > > > do when someone wants to delete or decommission a subCA.  If we 
> > > > > want 
> > > > > to
> > > > > keep the subCA record -- and we almost certainly need to  -- we 
> > > > > should
> > > > > probably add some kind of field to enable/disable.
> > > > > 
> > > > > Second, we definitely need code to be able to issue a cert 
> > > > > using 
> > > > > the
> > > > > subcas from the REST interface.  This will allow us to actually 
> > > > > test
> > > > > that the subCA is working.
> > > > > 
> > > > > Third, if we do stick with the current REST API, I think we 
> > > > > should
> > > > > consider using something like:
> > > > > 
> > > > > POST /subcas/ca1/ca2  {"id": "ca3"} to generate a subca 
> > > > > /ca1/ca2/ca3
> > > > > 
> > > > > Fourth, though, we need to consider carefully whether or not it 
> > > > > makes
> > > > > sense to identify a subca through 
> > > > > 1) an identifier that contains slashes
> > > > > 2) an identifier that is defined by the user instead of the 
> > > > > server. 
> > > > >  We
> > > > > have currently no controls as to what names are chosen, and no 
> > > > > clear
> > > > > rationale for what should be chosen.
> > > > > 
> > > > > Much as I dislike uuids, there is a good reasons openstack uses 
> > > > > them
> > > > > everywhere.
> > > > > 
> > > > > We can discuss over IRC, but I can see many issues here.
> > > > > 
> > > > > Ade
> > > > > 
> > > > > 
> > > > > 
> > > > > On Tue, 2015-08-25 at 14:40 -0400, Ade Lee wrote:
> > > > > > Some initial comments and questions. Will have more after 
> > > > > > playing 
> > > > > > with
> > > > > > it and testing. Looks pretty good so far.
> > > > > > 
> > > > > > 1. what is 
> > > > > > org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
> > > > > > and why is it needed?
> > > > > > 
> > > > > > 2. In CAService.java: issueX509Cert() - if ca is null, this 
> > > > > > throws 
> > > > > > an
> > > > > > ECAException - which, if I understand the code correctly, 
> > > > > > ends 
> > > > > > up 
> > > > > > being
> > > > > > some kind of BaseException.  So, if someone requests a cert 
> > > > > > and
> > > > > > provides a bogus caref, it will be reported as a server error 
> > > > > > instead
> > > > > > of a installation error?
> > > > > > 
> > > > > > 
> > > > > > 3. CertificateAuthority.java
> > > > > > -- subCAHier --> rename to subCAHierarchy.
> > > > > > 
> > > > > > -- In the constructor, it would be useful to have example 
> > > > > > inputs in 
> > > > > > the
> > > > > > method documentation so that we can see what data is expected 
> > > > > > to be 
> > > > > > in
> > > > > > each of the fields.  Its hard to review/understand/maintain 
> > > > > > otherwise.
> > > > > > 
> > > > > > -- you have extracted initCetDatabase() and initCRLDB(), also 
> > > > > > extract
> > > > > > the replica repo initialization code into initReplicaRepo() 
> > > > > > or 
> > > > > > similar.
> > > > > > 
> > > > > > -- loadSubCAs - could use some description in method comments 
> > > > > > about 
> > > > > > the
> > > > > > structure we expect to construct here.  An example config 
> > > > > > would 
> > > > > > help
> > > > > > understanding.
> > > > > > 
> > > > > > -- createSubCA 
> > > > > >    -- returns ECAException() in many different cases ie.
> > > > > >    if the CA exists, if the parent does not exist, if there 
> > > > > > is 
> > > > > > an 
> > > > > >    error in CA creation.  This makes it difficult to separate 
> > > > > > out 
> > > > > > the 
> > > > > >    things that are likely client request issues vs. server 
> > > > > > issues. 
> > > > > >    More likely, we want different exceptions that can be 
> > > > > > caught 
> > > > > > by 
> > > > > > the 
> > > > > >    caller and handled appropriately.
> > > > > >    -- what about uniqueness checks for the issuer DN?
> > > > > > 
> > > > > > 
> > > > > > 4. SubCAResource.java 
> > > > > > -- path should be subcas ? not subca ..
> > > > > > -- acls needed of course
> > > > > > 
> > > > > > 
> > > > > > 5. CAEnrollProfile.java 
> > > > > > --> could not reach CA -- that ends up being a 
> > > > > > ProfileException