Comments inline: On Sun, Jul 24, 2016 at 10:22 AM, Tim Ellison <[email protected]> wrote:
> On 24/07/16 14:51, Ellison Anne Williams wrote: > > 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. > > Ok, that's a good, and important point for Pirk. Can I rephrase as: > Pirk can run a query over all data that the data owner has given it access. > > Yep -- I concur with that phrasing. > > 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. > > I think the suggestion is not just message validation, but also > establishing sender identity and comparing it against a white-list too, > right? (i.e. a simple form of ACL ;-) > > To turn things completely upside down - we (Pirk) could take the position that any type of white-list/ACL for Pirk Query/Response objects occurs *outside* of Pirk. In other words, Pirk just produces the Query and Response objects and any verification of sender identity is done outside of Pirk as Pirk doesn't (and shouldn't) provide communication channels between the Querier and Responder (as entities, not in the java object sense). As the comms channels are outside of the scope of Pirk, perhaps verification/white-listing of sender/receiver objects should be as well. Curious as to what other folks think... > Regards, > Tim > > > 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 > >>>> > >>>> > >>>> > >>> > >> > > >
