Hi, Thanks for this Brian - it's really helping me see the big picture of how all the pieces can come together to fulfil many known (and certainly many new) use cases.
Seeing a proposed release schedule is also great motivation - looking forward to helping out. Regards, John -----Original Message----- From: Brian Spector <[email protected]> Sent: 05 June 2019 12:24 To: [email protected] Subject: Product Direction and Release Schedule NOTE: This also exists as a post here: https://cwiki.apache.org/confluence/display/MILAGRO/2019/06/04/Product+Direction+and+Release+Schedule Please comment on this thread though, as with the Apache Way, “if it doesn’t happen on email, it doesn’t happen.” Milagro (the project) needs a general purpose Milagro Server that can encapsulate all the required components to bring up and distributed / decentralized core security services. As an example, in the current Python versioned M-Pin server there does not exist any flag on whether to run this as a D-TA (serving shares of secrets) or as an M-Pin Server. This means someone building a fully fledged M-Pin protocol based implementation needs to construct their own D-TA services, which is causing implementation drag. Thankfully, Giorgio has been working on this. I propose that we fix this going forward by having an install script that can pull down various components and complete installation according to config/install scripts. So, going forward, we just have something called 'Milagro Server'. Second, in order for Milagro to stay relevant, Milagro should address use cases within the digital asset space that deliver on the security requirements for decentralized networks, in addition to the enterprise and IoT spaces. There is much interest from these communities for open source platforms that can secure escrow of private keys used to store value and transact cryptocurrencies (custody) but operate in a decentralized manner - capability that is native to Milagro. Qredo has been working on such a platform using the Milagro crypto libraries, which has authentication based on M-Pin (using Milagro) and will grant the software to Apache in the next few weeks. This will enable Milagro to finally get a release out the door of a product, not just a release of the crypto libraries. The list of capabilities for this product as it continues its development trajectory incorporates decentralized storage and backup. It is envisioned that M-Pin protocol authentication and D-TA's will also be a part of this mix. Decentralized Milagro Qredo has incorporated into its custody server product (based on Milagro) a distributed, immutable file system called IPFS, an immutable, operation-based conflict-free replicated data structure (CRDT) for distributed systems with MIT license. On top of IPFS, we have built a decentralized public key infrastructure that does away with certificates and certificate authorities. This decentralized public key infrastructure enables an encrypted messaging over IPFS pubsub. We propose to call this the 'Milagro encrypted envelope' format. This functionality is required to enable Milagro Servers to distribute secrets over a decentralized infrastructure - imagine a D-TA operating in this manner and distributing shares of M-Pin secrets to clients. The custody server that Qredo has created uses the encrypted envelope format to distribute Elliptic Curve keys between operators of the Milagro Server. This EC keys are ultimately used to create wallet addresses, or create private keys used to control digital assets inside a cryptocurrency wallet. This capability is also critical for D-TAs, so that decentralized D-TA services can distributed shares of M-Pin protocol based private/server keys to authenticated endpoints/clients. I will create another blogpost describing the functional overview of the Milagro Server configured for decentralized custody services and a separate blogpost for decentralized backup of key stores. PKCS#11 Qredo has also created a PKCS#11 implementation that enables secrets generated by a Milagro Server to be protected by AWS HSM-Clusters. We will contribute this code as part of the Milagro Server. Docker Container Apache has its own Docker registry now, so Milagro should take full use of this. I propose that we implement a Milagro Server in a docker container and this be part of the initial release schedule. Release Schedule July 1 - Milagro Crypto Library Release (milagro-crypto-c) The C library is in good shape and will have additional fixes made by the end of the month. At the moment, all tests are passing. Releasing the Milagro Crypto Library first will enable the contributors to Milagro to familiarize themselves with the processes for getting releases out the door under the 'Apache Way'. This experience is essential for the success of the project. We have some tasks outstanding on Milagro-JavaScript. Depending on resource availability, we may or may not be able to August 1 - Milagro Server Release Candidate 1 of v0.1 (RC1) First release candidate September 1 - Milagro Server Release Candidate 2 of v0.1 (RC2) Second release candidate October 1 - Milagro Server v 0.1 GA Incorporating Current Functional Code Qredo has specifics in mind with regards to functionality available in each RC and GA releases in regards to decentralized custody and backup but an equal priority will be given to contributor's work done so far on ZKP MFA services, particularly with regards to Giorgio's work and the current working implementations of the M-Pin Server. Going forward, I propose we stop referring to the underlying protocol and be explicit about what the functionality is, as an example, this is the zero-knowledge proof multi-factor authentication (ZKP MFA) server. Figuring out what is going into these releases should be our next immediate priority.
smime.p7s
Description: S/MIME cryptographic signature
