I really like the direction. The schedule is realistic to my opinion and I'm excited to work with the community to achieve that. We need to define what exactly will go into the specific releases and I will try to help with that as well.
Regards, Stan On 2019/06/05 11:23:57, Brian Spector <[email protected]> wrote: > 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. >
