You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@milagro.apache.org by Brian Spector <br...@qredo.com> on 2019/06/05 11:23:57 UTC
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.
Re: Product Direction and Release Schedule
Posted by Stanislav Mihaylov <sm...@apache.org>.
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 <br...@qredo.com> 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.
>
RE: Product Direction and Release Schedule
Posted by John McCane-Whitney <jo...@qredo.com>.
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 <br...@qredo.com>
Sent: 05 June 2019 12:24
To: dev@milagro.incubator.apache.org
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.
Re: Product Direction and Release Schedule
Posted by Kealan McCusker <ke...@gmail.com>.
Hi Brian
This looks great to me.
It should be possible to get the crypto updated in a very short time.
Today, we have just got Travis-CI enabled which will be a big help.
The services are going to take longer but I think that the release schedule
is
realistic, especially now that we have more committers involved.
I am looking froward to working with the community to further the aims of
the project.
Regards
Kealan
On Wed, 5 Jun 2019 at 12:24, Brian Spector <br...@qredo.com> 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.
>
Re: Product Direction and Release Schedule
Posted by Giorgio Zoppi <gi...@gmail.com>.
Thanks, I'll check it out.
El jue., 6 jun. 2019 a las 10:40, jean-frederic clere (<jf...@gmail.com>)
escribió:
> On 06/06/2019 00:34, Giorgio Zoppi wrote:
> > Ok, well done. Just a question. does anyone how enable Sonar on our
> github.
> >
> https://blog.sonarsource.com/reviewing-the-apache-sling-code-quality-using-sonar
> > .
>
> That is a 10 years old blog...
>
> Try to look to
> https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis
>
> > Could we ask to Sling People?
>
> Ask infra I guess ;-)
>
> > Best Regards,
> > Giorgio
> >
> >
> > El mié., 5 jun. 2019 a las 13:24, Brian Spector (<br...@qredo.com>)
> > escribió:
> >
> >> 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.
> >>
> >
> >
>
>
> --
> Cheers
>
> Jean-Frederic
>
--
Life is a chess game - Anonymous.
Re: Product Direction and Release Schedule
Posted by jean-frederic clere <jf...@gmail.com>.
On 06/06/2019 00:34, Giorgio Zoppi wrote:
> Ok, well done. Just a question. does anyone how enable Sonar on our github.
> https://blog.sonarsource.com/reviewing-the-apache-sling-code-quality-using-sonar
> .
That is a 10 years old blog...
Try to look to
https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis
> Could we ask to Sling People?
Ask infra I guess ;-)
> Best Regards,
> Giorgio
>
>
> El mié., 5 jun. 2019 a las 13:24, Brian Spector (<br...@qredo.com>)
> escribió:
>
>> 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.
>>
>
>
--
Cheers
Jean-Frederic
Re: Product Direction and Release Schedule
Posted by Giorgio Zoppi <gi...@gmail.com>.
Ok, well done. Just a question. does anyone how enable Sonar on our github.
https://blog.sonarsource.com/reviewing-the-apache-sling-code-quality-using-sonar
.
Could we ask to Sling People?
Best Regards,
Giorgio
El mié., 5 jun. 2019 a las 13:24, Brian Spector (<br...@qredo.com>)
escribió:
> 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.
>
--
Life is a chess game - Anonymous.