I agree that we don't necessarily want to tie dictate PGP forever, but I think that it's fine for an initial pass. We can always expand as long as we provide a good framework to do so.
As to: "I guess the next level is to determine what a an authenticated entity is allowed to query and retrieve, which will require a more sophisticated access control throughout Pirk. Again, I would argue that access control should be implemented in code that is independent of any credentials representation." This is beyond the Query-Response signing issue. The Responder can only run a query over data 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. What is within the scope of Pirk is to provide a means for Pirk to verify (via signing) the validity of its internally generated Query and Response objects. On Sun, Jul 24, 2016 at 9:40 AM, Tim Ellison <[email protected]> wrote: > On 23/07/16 21:40, Jacob Wilder wrote: > > Andy, I had considered using symmetric signatures but I think that while > it > > is simpler in the pairwise case it would lead to significant complexity > if > > we reach a point where one responder is servicing queries for multiple > > queriers. In that case we would need to use different symmetric signature > > keys for each partner-pair. > > > > As heavy as OpenPGP is we get the benefits of a standardized, language > > independent key and signature format for which software already exists. I > > like OpenPGP's clearsign format for this situation because it avoids > having > > to package a signature file with the payload whenever it is being sent > from > > one participant to another. > > The code I've prototyped already works with trusting multiple public > > keys—property serialization.openPGPPublicKeyRing will point to an OpenPGP > > ASCII armored public key ring which can contain as many public keys as > > desired. If you attempt to verify an object and the signing key (for the > > valid signature) is in that file it will be approved. > > Basically, we get the multi-party case for free. > > > > Would we rather specify a config parameter to determine whether we are > using > > PGP (or something else)? > > Now that the serialization and storage are separate from the fundamental > Query/Quuerier/Response/Responder logic, I don't so much care which > format or representation you choose -- provided you keep it as a > characteristic of the serializer. > > For the same reasons we don't really want to tie Pirk to one serialized > format for objects, we wouldn't want to dictate one authentication > mechanism (PGP) for all queries. > My original plan was to have a property which switches between "All files > > must be signed" and "All files must be unsigned" because it makes for > > really simple code paths. But when I wrote the original email I thought > > about it and realized that it'd be really annoying if you ran a system > > where you accepted unsigned files and someone sends you a signed one. You > > don't care about the signature but now you have to change your > > configuration (or hand-unwrap the base64-encoded binary object). That's > why > > I suggested "serialization.requireSignedInput" as the property so the > > option is between "All files must be signed" and "Unsigned files are just > > as OK as signed files". > > So the first level of authentication would be to be able to check the > identity of the sender of a query, and thereby that they are approved to > send queries by pre-approved list, trusted certificate chains, etc. > > I guess the next level is to determine what a an authenticated entity is > allowed to query and retrieve, which will require a more sophisticated > access control throughout Pirk. Again, I would argue that access > control should be implemented in code that is independent of any > credentials representation. > > Regards, > Tim > > > On Sat, Jul 23, 2016 at 1:48 PM, Andy LoPresto <[email protected]> > wrote: > > > >> PGP is a robust (but sometimes complicated) system for this purpose. It > >> certainly makes sense to offer it, but it seems that using an > HMAC/SHA-256 > >> for example would provide a sufficient level of trust over the > serialized > >> data. If my understanding is correct, it’s not necessary to fully > resolve > >> the identity of the data provider to a unique source, rather simply to > >> enforce that the data was provided by an entity at a certain trust > level. > >> It’s a trade-off between managing a high number of key pairs and > accepting > >> that a one or more shared secrets is distributed in the ecosystem. > >> > >> > >> Andy LoPresto > >> [email protected] > >> *[email protected] <[email protected]>* > >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> > >> On Jul 23, 2016, at 5:41 AM, Ellison Anne Williams < > >> [email protected]> wrote: > >> > >> Sounds good Jacob - this will be a great addition to Pirk. > >> > >> I think that the the specified properties/options seem reasonable. The > only > >> factor to consider down the line is that one instantiation of a > Responder > >> could be servicing multiple queries at one time -- if they are all being > >> signed, then you could have multiple keys. I don't think that we need to > >> necessarily tackle architecting for that case now (as our Responders > >> currently work on a single query at at time), but it's something to > think > >> about as we expand the Responders to multi-query (at some point in the > >> future). > >> > >> One question -- Are we sure that we want to tie it to PGP? > >> > >> "By default, all InputStreams used to read data will be checked to see > if > >> they start with the line "-----BEGIN PGP SIGNED MESSAGE-----" > >> > >> Would we rather specify a config parameter to determine whether we are > >> using PGP (or something else)? > >> > >> I am in favor of having an initial single-key, PGP implementation and > then > >> expanding from there. > >> > >> Thoughts? > >> > >> On Fri, Jul 22, 2016 at 11:43 PM, Jacob Wilder < > >> [email protected]> wrote: > >> > >> Given that deserialization attacks are a ripe attack surface > >> <https://www.owasp.org/index.php/Deserialization_of_untrusted_data> > it's a > >> good idea to make it possible to authenticate serialized objects > whenever > >> possible. In the case of Pirk—where systems which hold sensitive data > will > >> be deserializing objects received from other entities—offering users the > >> option to sign/verify objects before loading them is valuable. If our > users > >> were not dealing with sensitive information of some sort, they wouldn't > be > >> using Pirk. > >> > >> I have written some code that uses BouncyCastle to OpenPGP clearsign > base64 > >> encoded Java objects. I'm going to see how cleanly I can integrate it > with > >> Tim's new Serialization code so that it's automatically available to > >> anything that uses the serialization tools. > >> > >> Where things get complicated is in how to expose it to users. Below is > my > >> current thinking. I'd appreciate any feedback. > >> > >> By default, all InputStreams used to read data will be checked to see if > >> they start with the line "-----BEGIN PGP SIGNED MESSAGE-----". If it > does, > >> we'll pull the PGP public keyring from a path specified by property > >> serialization.openPGPPublicKeyRing and verify the signature. Failed > >> signature verifications result in an exit. > >> > >> Property serialization.requireSignedInput will reject any input that is > not > >> signed with a valid signature. > >> Property serialization.signOutgoingObjects will sign all outgoing > >> Serialized Java objects. > >> Properties serialization.openPGPPrivateKey, > >> serialization.openPGPPrivateKeyPassword, > >> and serialization.openPGPPublicKeyRing will indicate the location of the > >> private key, the password used to decrypt it, and the location of the > >> public key ring respectively. > >> > >> > >> I had considered using SignedObjects but decided to give OpenPGP a shot > >> because it's easier to hand-verify signatures or integrate verification > of > >> signed data into automated data flow (say, between two distinct entities > >> sharing data using Pirk). > >> > >> > >> — > >> Jacob WIlder > >> > >> > >> > > >
