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