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

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?

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

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

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

> > 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 > > > -- > > > which maps to a server error? Is this a case where we need > > > a > > > bad request exception instead? > > > > > > 6. subca.schema > > > -- why is it specified in a separate file? (and also in > > > schema.ldif) > > > -- the subca is uniquely defined by only one MAY attribute for > > > nickname (which is in printable string format)? Is that > > > sufficient > > > and should that be a required attribute? Do you need to > > > store > > > the > > > issuerDN for uniqueness checks? > > > > > > 7. SubCAService.java > > > -- lets remove the commented out audit messages and functions > > > -- createSubCA() > > > -- should be some checks here on the data -- rather than > > > passing > > > through to the lower level. Bad data should return > > > BadRequestException, including for cases where we have > > > existing issuerDN or caRef. > > > > > > 8. SubCACreateCLI -- this code would be confusing: > > > > > > if (cmdArgs.length < positionalArgNames.length) { > > > System.err.println("Error: No " > > > + positionalArgNames[cmdArgs.length] > > > + " specified."); > > > > > > Just specify "Insufficient params .." > > > > > > 9. It would be good to have a DN check here on client side -- > > > this > > > can be added in a separate patch. > > > > > > 10. Should users be able to define the nickname? I would say > > > "yes" > > > because it might make it easier to notify services like > > > custodia > > > for > > > instance to distribute keys. > > > > > > 11. Should we also have the option to define the token in which > > > the > > > key is generated and stored? ( I think yes - in case for > > > instance, > > > your HSM has limited keys). Where do the subCA keys get > > > generated > > > by > > > default -- in the software or hardware token? > > > > > > 12. To help clarify this, please describe what would be > > > created > > > if one were to add a new subCA using the CLI at reference caRef > > > > > > Specifically, > > > a) what database entry is created? > > > b) what is the nickname for the key/cert? > > > c) Where is the repo (ie. the suffix) for this ca's certs? > > > d) Exactly which resources belong to the subCA only? > > > > > > 8. SubCACreateCLI -- this code would be confusing: > > > > > > if (cmdArgs.length < positionalArgNames.length) { > > > System.err.println("Error: No " > > > + positionalArgNames[cmdArgs.length] > > > + " specified."); > > > > > > Just specify "Insufficient params .." > > > > > > 9. It would be good to have a DN check here on client side -- > > > this > > > can > > > be added in a separate patch. > > > > > > 10. Should users be able to define the nickname? I would say > > > "yes" > > > because it might make it easier to notify services like > > > custodia > > > for > > > instance to distribute keys. > > > > > > 11. Should we also have the option to define the token in which > > > the > > > key > > > is generated and stored? ( I think yes - in case for instance, > > > your > > > HSM has limited keys). Where do the subCA keys get generated > > > by > > > default -- in the software or hardware token? > > > > > > 12. To help clarify this, please describe what would be > > > created > > > if one were to add a new subCA using the CLI at reference caRef > > > > > > Specifically, > > > a) what database entry is created? > > > b) what is the nickname for the key/cert? > > > c) Where is the repo (ie. the suffix) for this ca's certs? > > > d) Exactly which resources belong to the subCA only? > > > > > > MISSING ITEMS: > > > These can be in a separate patch, but if so, we need tickets to > > > track > > > them: > > > > > > 1. acls > > > 2. auditing > > > 3. key parameters > > > 4. migration scripts (i.e. how to add db entries) > > > 5. tests - we need unit/functional tests to show the data that > > > is > > > expected and to do basic error checking in the client. > > > These > > > are > > > very important. Eventually, we would like tests to be a > > > required > > > part of any check-in. > > > > > > Ade > > > > > > On Mon, 2015-08-24 at 17:27 +1000, Fraser Tweedale wrote: > > > > Hi team, > > > > > > > > The latest sub-CAs patches are attached. It has been a while > > > > since > > > > the last patchset (that was posted here, anyway) and there > > > > have > > > > been > > > > some significant changes, outlined below. (The patchset > > > > version > > > > skipped a couple numbers due to versions distributed > > > > privately > > > > that > > > > I felt were not stable enough to warrant posting to pki > > > > -devel.) > > > > > > > > Major changes: > > > > > > > > - The Java client and CLI were extracted to a separate patch > > > > (0044). > > > > - An LDAP entry for each sub-CA is written to database. > > > > - Database searched and sub-CAs are initialised at startup > > > > - Key nickname is store in / read from LDAP entry > > > > - Sub-CA "list" API call, client method and CLI was added > > > > - More resources are shared between top-level CA and sub-CAs > > > > - Suprious task threads and LDAP connections hunted down :) > > > > > > > > Dependencies: > > > > > > > > - Patch 0026-5 probably depends on 0045[1] for a clean merge. > > > > - Patch 0044-3 depends on my patch 0046[2]. > > > > > > > > [1] > > > > https://www.redhat.com/archives/pki-devel/2015-August/msg0007 > > > > 2.ht > > > > ml > > > > [2] > > > > https://www.redhat.com/archives/pki-devel/2015-August/msg0007 > > > > 3.ht > > > > ml > > > > > > > > Cheers, > > > > Fraser > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel(a)redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel(a)redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel