[Pki-devel] [PATCH] 0026-5, 0044-3 Lightweight sub-CAs
Fraser Tweedale
ftweedal at redhat.com
Thu Aug 27 07:22:35 UTC 2015
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/msg00072.ht
> > > > ml
> > > > [2]
> > > > https://www.redhat.com/archives/pki-devel/2015-August/msg00073.ht
> > > > ml
> > > >
> > > > Cheers,
> > > > Fraser
> > >
> > > _______________________________________________
> > > Pki-devel mailing list
> > > Pki-devel at redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> >
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
More information about the Pki-devel
mailing list