Just today, Oraclize released an update to support Encrypted Queries, which allow private information to be stored publicly.
To fully understand what is happening here, you have to understand the purpose Oraclize serves.
Let's say you want to get a random number on the blockchain. Or you want to get the weather in San Francisco right now. When every individual on the blockchain executes this, there can never be consensus. I get a random number, it gives me 3. Then you go get a random number, it gives you 4. I get the weather, it says its 61F and sunny. You get it an its 60 and sunny.
Oraclize solves this by essentially taking data that is offchain and putting it on the chain once so that everyone reaches the same answer. Instead of asking "what's the weather" on the chain, you would ask Oraclize what the weather was and it would respond "It's 61F and sunny" and the 61F and sunny is stored on the chain.
Their update today takes that one step further. Instead of putting
"My SSN is: 738-94-0293" on the blockchain, you would encrypt it and then Oraclize would use it's private key to decrypt it.
You would store the encrypted version of my SSN, and whenever you needed to know my SSN you would query Oraclize to decrypt it, and then you would do whatever with it.
Problems
Encrypted data is more expensive (uses more gas) than unencrypted because it has more bits
You have to trust Oraclize that (1) they hold the only private key and (2) that private key never gets stolen, misplaced, etc. ever. Even if it's in 10 years, if that private key becomes public, anyone can access all the data stored in that format on the chain. There is no way to remove that data from the chain either. This is the reason they use API keys & answers to trivia questions in their examples, not SSNs or other truly secret information. It's not the end of the world if the answer to the trivia question gets stolen. It kind of is if 5000 SSNs get decrypted.
Your actual questions ;)
It's hard to give you a good answer. I can tell you this:
If the information is sensitive enough that in 1 year, 5 years, or 10 years the private information become public would be detrimental to businesses, people's lives, etc. then a private sidechain or something you control 100% would be better.
It doesn't necessarily mean that you must keep everything on a private blockchain or private servers, it just means that the sensitive information needs to be able to be deleted in case of a breach of private keys.
Other security precautions should be taken on your end to prevent a more typical hack/breach/etc. of your traditional servers/database.
I would recommend that you stick verification or tracking-styling information on the blockchain, anything sensitive would be off-chain. Saying "Mary says she picked object #123 up" is much different than "Mary Holland, SSN: 469-23-9484, address: 1234 5th Street Los Angeles CA 90123, picked up 5oz. of cocaine from Joseph Burr, SSN: 764-18-2393, at 54321 18th Street Compton CA 90321 at 3:34pm on 5/4/2016."
Would it be possible to restrict access to the information depending on which parties are listed as having permission to view asset details.
This deserves a question of it's own.
You could use public key cryptography (like Orcalize is doing, but on your own) in order to issue private keys to necessary parties that would allow them to decrypt the information when they need to. It would take some orchestration and the encryption of the data would need to be done offchain as well, but it's doable. I don't have enough knowledge to say the best procedure for this but essentially each user would have a key to decrypt and therefore they could successfully decrypt any data what was encrypted using their key. Again, breaches of these keys could be detrimental and the more people who have a key floating around, the more likely it will be that the key gets lost/stolen/publicly posted/etc. Especially if you are dealing with a "normal" user like Mary who just knows she has to press this button when X happens, not how the underlying architecture works.
