...
Private Key A Private Key B
During a communication, a message is send from Server A to Server B.
...
The sender server A can encrypt the message with his private key.
SS: Then it becomes a problem of how to trust the public key associated with A's private key, and how do you trust that A's private key has not been compromised. Blockchain could be useful (perhaps) in the trust model, and in the revocation model.
How to enable confidentiality in this scenario?
Server B can encrypt sign the answer message for server A with the A’s public key. Therefore, only the right receiver is able to decrypt and read the answer with its own private key.
SS: As above this becomes a problem of how to trust that you know the correct public key for A. If you trust the wrong key, you encrypt to the wrong recipient. Again, blockchain could help the model of how to trust public encryption keys.
Open issues / questions
What Consensus model could work in this context?
There could be used a "Proof of Authorization" model. For example when 2 of 3 nodes or even 3 of 4 nodes agree on "ServerA belongs to public key A" the entry is written to the block chain.
Open issues
How to put keys in the blockchain in a trusted way.
- Consensus model
o Proof of Authorzition
o (typically 2of3 or 3of4 nodes need)
When server B compares
Is there similarity with x.509 certifictes
...
Should we use an public or private ledger?
Let's start with a private ledger.
Why not using x.509 certificates?
No reason not to include X.509 certificates for the underlying operations. Where blockchain can make a difference is in the trust infrastructure that X.509 does not fully solve.