This approach works for me. I’ll echo Tim’s earlier suggestion that we work towards eliminating (or at least reducing) our use of serialized Java objects as soon as we can. That way we don’t have the sort of remote code execution concerns that serialization entails. This would bring the level of concern down from “attacker can do terrible things to your system” to “attacker gets you to operate on the wrong data”.
> On Jul 24, 2016, at 12:35, Ellison Anne Williams <[email protected]> > wrote: > > Hi Guys, > > There has been a lot of good discussion lately about signing Pirk objects, > validating, etc in another thread. I would like for us to step back and > consider the trust model for Pirk. > > Pirk is an application that runs within a user's system to provide the > ability to (1) generate a secure query via PIR and/or (2) execute a secure > query via PIR. A Pirk Querier generates a Query object and a Pirk Responder > generates a Response object. For a user system that is running the Pirk > application, these objects are just an output of the application. > > Communication between the Querier and Responder entities is necessary for > the Querier to send the Responder a query (Query object) and for the > Responder to return the results (Response object), but those transport > mechanisms are external to Pirk. User systems running the Pirk application > can choose to communicate with each other in whatever way they would like > to. > > As such, I propose that the authentication of the Query and Response > objects remain external to Pirk. It seems that this is best left as a part > of the access control/authentication of users' systems that are running the > Pirk application and communicating with each other. > > This also of the same philosophy as the Responder's data access: the > Responder can only execute a query over data to which the data owner has > given it access. This is enforced outside of Pirk -- data access controls > of the data owner for a data user (such as Pirk) are outside of the scope > of the Pirk project. > > Thoughts? > > Ellison Anne
