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 <alopre...@apache.org> 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 >> alopre...@apache.org >> *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Jul 23, 2016, at 5:41 AM, Ellison Anne Williams < >> eawilliamsp...@gmail.com> 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 < >> jacobwilder.opensou...@gmail.com> 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 >> >> >> >
