Conjur Over a p2p Architecture

My apologies if this question has been asked before but I’m:

  1. Looking to deploy a p2p, distributed and decentralized network (akin to Bittorrent protocol or any other popular p2p protocol one can name)

  2. The p2p protocol in question that I’m creating uses the network itself as available storage (akin to IPFS, yet different). Let us assume that I’ve alerady handled the relevant logistics as far as how to distribute, locate, reliably store and later access said data in a sustainable manner

Considering the network that I’ve very briefly outlined in ‘1’ and ‘2’, is Conjur able to operate within these constraints?

Ultimate Plan

Since this is an open source protocol that my team and I are devising, I have no problem addressing why I’m asking about this:

  1. Last few months, I’ve been working on a specification that has a W3C approved scheme which allows users to derive a DID identity from an anchored hash on the blockchain. Users of course prove that they were the creator of said transaction via PKI (signing some arbitrary data that is later evaluated against the public key that they claim to own)

  2. Once established, an “anchor” is created - abstracting a named identity (URI) tied to the anchored public address (which was provided by the end user as they were verifying ownership of this address via PKI)

Tying This Back into the Documentation

By docs, I’m referring to the instructions given on the GitHub wiki here = https://github.com/cyberark/conjur-quickstart#certification-level

Specifically, it mentions the creation of a ‘data key’ (before instantiating the docker container). That data key is later piped into a command asking for a password for the admin account (the key is then stretched and used to generate a public / private pairing.

Given that this is how the private / public key pair is created, I was going to augment this process with a stateless one that allows users to generate their private + public key pairing without ever having to save the password / passfile on the server (or elsewhere).

This is done via the same magic that’s used for the ‘mindwallet’ app (for Bitcoin) located here:

A) https://github.com/patcito/mindwallet (Git Repo)

B) PWA for the code (you can absolutely run this offlne if you choose to: https://patcito.github.io/mindwallet/mindwallet_0.1_SHA256_29f7c0bf801f352420a3d770af723503d770dc10e11e2753a0c266825936967e.html

The PWA generates a Bitcoin address deterministically on the basis of one’s entered password and salt (e-mail). And since this is generated in a deterministic fashion, all that user needs to do is remember that very password & salt combination.

This is still a secure setup vs. randomly generated entropy-based seeds that are piped into wallet setups without forethough to generate insecure mnemonic phrases.

By deploying Argon2 as the KDF of choice here, we make up considerably for the inevitable ‘bad password’ breach that will happen at some point in the near future to apps like this or any others that have passwords / databases etc.

This has nothing to do with any perceived question of the credibility of the team or this project’s design. In fact, just the opposite.

Ultimate Goal

Going down to the part where it talks about API key generation, I was looking into retrofitting that portion of the software to generate bearer authentication tokens (JWT ; more specifically, JWKS) that are distributed to users that attempt to connect w/o having prior communication with the server since this is a distributed protocol.

This would allow me to drop the JWKS behind some other ‘challenge’ that the user must pass (perhaps on the basis of some whitelisted client access pool or DoS-mitigation; not sure yet), in order to distribute keys in the form of a JWE / JWKS (key pair that’s generated much along the same way that mine was + key wrapping that’s encrypted to the requesting resource’s original identity).

Forgive the Rambling at the End

Working on somewhat of a short deadline and a bit tired, so some of the specifics here at the end of this prospective setup that I’m planning may appear to be a bit hazy - but the **big picture here is that I’m wondering whether the Conjur tool can be reliably deployed over a dynamic p2p protocol that’s looking to come up with unique means for key distribution.