+1 (binding) Colm.
On Tue, Dec 15, 2015 at 10:56 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > +1 (binding) > > Regards > JB > > > On 12/15/2015 09:56 AM, Nick Kew wrote: > >> I should like to call a vote to accept Milagro into >> the Incubator. The full proposal is available at >> https://wiki.apache.org/incubator/MilagroProposal >> as well as below. >> >> Note that the project was first discussed here under >> the name OpenMiracl. The adoption of the Milagro name >> is a response to that discussion. >> >> [ ] +1 Accept Milagro into the Apache Incubator >> [ ] 0 >> [ ] -1 Do not accept Milagro into the Apache Incubator ... >> >> The vote remains open until at least the end of the week. >> >> For myself: >> [*] +1 Accept Milagro into the Apache Incubator >> >> >> = Project Proposal: Milagro = >> == Abstract == >> Milagro is a distributed cryptosystem for cloud computing. Its purpose >> is to provide an open source alternative to proprietary key management >> and certificate backed cryptosystems used for secure communication and >> authentication. The adoption of Milagro will create a secure, free, open >> source alternative to monolithic certificate authorities and eliminate >> single points of failure. >> >> == Background == >> The Cloud Computing industry is using 40-year-old cryptographic >> algorithms and infrastructure, invented for a different era when >> client-server computing was the dominant paradigm. At the heart of it, >> is the continued reliance on outdated, and problematic, monolithic >> cryptographic trust hierarchies such as commercial certificate >> authorities. >> >> A number of factors are aligning to make this the right time to bring >> forth an alternative to the Internet's continued reliance on PKI. >> >> The Cloud Infrastructure as a Service (IaaS) industry as a whole >> encounters friction bringing the largest customers in regulated >> industries onto their platforms because issues of cryptographic trust, >> data residency, and data governance prevent total adoption among >> regulated industries. >> >> Devops teams tasked with running an IaaS provider's datacenter >> automation encounter challenges scaling and automating data center >> operations when confronted with the complexities of running encryption, >> certificate and key management infrastructures built for a client-server >> era. >> >> Enterprises in regulated industries find challenges to transform >> entirely into digital businesses because the economics of cloud >> computing are unavailable to them. >> >> Despite the astounding growth of cloud infrastructure as a service >> platforms over the last few years, full adoption by organizations with >> stringent data security requirements won’t be achieved until these >> fundamental capability issues get resolved. >> >> Lastly, the Internet as a whole is suffering from an erosion of trust >> following incidents with commercial certificate authorities industry, >> i.e., compromised root keys, and failures in due diligence issuing real >> domain certificates. >> >> Indeed, mass surveillance, a lack of easy end-user encryption, a growing >> demand for key escrow under legal oversight, and general certificate >> authority security concerns create the question: How appropriate is the >> continued dependency on PKI when the goal is to advance the benefits of >> cloud computing across the technology landscape? >> >> Netcraft is the industry standard for monitoring Active TLS >> certificates. In May 2015, they stated that “Although the global [TLS] >> ecosystem is competitive, it is dominated by a handful of major CAs — >> three certificate authorities (Symantec, Comodo, Godaddy) account for >> three-quarters of all issued [TLS] certificates on public-facing web >> servers.” >> >> The Internet Security Research Group's (ISRG) "Let's Encrypt" initiative >> aims to make Secure Sockets Layer/Transport Layer Security (SSL/TLS) >> certificates available for free in an automated fashion. This a step in >> the right direction, in that it removes the risk of profit before >> ethics. The real issue, which is one entity acts as a monolithic trust >> hierarchy, is not addressed. The monolithic trust hierarchy is a >> fundamental design flaw within PKI itself. >> >> The rate of attacks against certificate authorities seems to be >> [increasing](http://wiki.cacert.org/Risk/History) as the obvious single >> point of compromise design inherent to PKI is becoming a more popular >> route to carry out attacks. >> >> == Proposal == >> Milagro is an open source, pairing-based cryptographic platform to solve >> key management, secure communications, data governance and compliance >> issues that are challenging Cloud Providers and their customers. >> >> It does this without the need for certificate authorities, putting into >> place a new category of service providers called Distributed Trust >> Authorities (D-TA's). >> >> The M-Pin protocol, and its existing open-source MIRACL implementation >> on which Milagro will build, are already in use by Experian, NTT, Odin, >> Gov.UK and are being rolled out at scale for zero password multi-factor >> authentication and certificate-less HTTPS / secure channel. >> >> It is proposed that Milagro enter incubation at Apache. At the same >> time, a draft standard for M-Pin has been prepared and recently >> submitted to IETF. The standards process at IETF and the platform >> implementation at Apache will run in parallel. >> >> === Why Pairing-Based Cryptography, why now? === >> Over the last decade, pairings on elliptic curves have been a very >> active area of research in cryptography. Pairings map pairs of points on >> an elliptic curve into the multiplicative group of a finite field. Their >> unique properties have enabled many new cryptographic protocols that had >> not previously been feasible. >> >> Standards bodies have already begun standardizing various pairing-based >> schemes. These include the IEEE, ISO, and IETF. Besides identity-based >> encryption (IBE), the standardized schemes include identity-based >> signatures, identity-based signcryption, identity-based key >> establishment mechanisms, and identity-based key distribution for use in >> multimedia. >> >> NIST has also recommended the standardization and adoption of >> pairing-based cryptographic systems __for government agencies__. In the >> NIST "Report on Pairing-based Cryptography" issued in February 2015, >> they state: >> >> "It has been a decade since the first IBE schemes were proposed. These >>> >> schemes have received sufficient attention from the cryptographic >> community and no weakness has been identified. IBE is being used >> commercially, primarily by Voltage Security and Trend Micro. Intel’s >> EPID scheme is another example of pairings being used commercially. > As >> a result of our study, we believe there is a good case for allowing >> government agencies to use pairings. Pairings have been shown to have >> numerous applications, helping to solve problems that are impossible, >> difficult, or inefficient with traditional public-key cryptography or >> symmetric encryption." >> >> The biggest beneficiary of these new pairing-based cryptographic >> protocols will be the Cloud Infrastructure as a Service industry. >> Pairing-based cryptography can provide real world solutions, right now, >> to the outstanding issues of cryptographic trust, data security, >> governance and compliance that create roadblocks to adoption of the >> Cloud by the industries that can most benefit from it. >> >> Pairing cryptography also makes possible the world in which a fleet of >> geographically distributed and organizationally independent Distributed >> Trust Authorities act as multiple private-key generators (PKGs) where >> trust need not reside in a single entity. >> >> The difference between this new world of Distributed Trust Authorities >> and the current PKI system will be a landscape that provides secure >> ease-of-use encryption and authentication, does not rely upon a single >> trusted third party, and yet allows for limited key escrow subject to an >> end customer's requirement. >> >> === Milagro === >> The Milagro libraries and tools consist of: >> >> * Distributed Key Management Service API >> * Distributed Key Management CLI >> * Software Defined Distributed Security Module (SD-DSM) build platform >> * Distributed Key Management Endpoints (software) >> * Crypto Apps, consisting of: >> * M-Pin Authentication Platform (delivering password-less 2FA) >> * M-Pin Secure Channel (delivering certificate-less TLS-PSK) >> * M-Pin-in-Mobile Client Libraries for iOS, Android and Windows Phone >> * M-Pin-in-Javascript Libraries for Browsers >> * Cloud Encryption Gateway (under nascent development) >> * Distributed Trust Authority Crypto App >> * Generic library for IoT cryptographic library >> >> The startingpoint for these is the existing MIRACL library and tools at >> http://github.com/Certivox/ >> >> === Distributed Trust Authorities === >> The Milagro project introduces a service concept called a Distributed >> Trust Authority, to replace either single-authority certificates or >> public key infrastructure. >> >> The D-TA splits the functions of a pairing-based key generation server >> into three services issuing thirds of private keys to distinct >> identities. The shares of the private keys, received by Crypto App >> clients or Distributed Key Management Endpoints, become the only >> entities that possess any knowledge of the whole key created from the >> shares. >> >> To effect anything resembling a root key compromise that can occur in a >> traditional PKI or commercial certificate authority, ***ALL*** >> Distributed Trust Authority servers must be compromised. >> Cryptographically, one compromise of a Distributed Trust Authority does >> not yield an attacker any advantage, all Distributed Trust Authority >> master secrets inside each D-TA providing shares must be compromised. >> Note that all 3 D-TA's operate independently and are under separate >> organizational control. >> >> For the following examples, envision a Distributed Trust Authority model >> consisting of Cloud Provider (D-TA 1), Cloud Provider end customer (D-TA >> 2) and neutral third party (D-TA 3). >> >> Under this three participant model, where each member is responsible for >> the security of their D-TA, the Cloud Provider can not subvert the >> security of the end customer, even with the collusion of the neutral >> third party. The end customer will not suffer an internal insider attack >> unless the Cloud Provider and neutral third party also collude. >> >> === Distributed Key Management API, CLI, Endpoints === >> The core infrastructure that consumes these thirds of private keys and >> is responsible for their distribution is a message bus and API (D-KMS >> API), a command line interface (CLI) and software (D-KMS Endpoints) >> which builds the Crypto Applications from source. >> >> Any entity can run any mix or combination of components with other >> entities, but there is no restriction on configuration. One party may >> operate all three D-TAs, Endpoints and APIs if they wish. >> >> The D-KMS CLI communicates securely with the API. The API is responsible >> for either creating cryptographic keys and secrets or protecting >> existing keys and secrets through cryptographic encapsulation, via a >> choice of pairing-based protocols. In either case, the API encapsulates >> the keys and secrets for the identity of particular D-KMS Endpoints. >> >> The D-KMS Endpoints are server operating systems with D-KMS Endpoint >> software installed. The D-KMS Endpoint software, in conjunction with the >> D-KMS CLI, has the appropriate pairing-based cryptographic keys to be >> able to de-encapsulate secrets and keys received from the D-KMS API. >> These de-encapsulated secrets and keys can be stored, distributed or >> used in Crypto Applications, such as M-Pin Authentication, Secure >> Channel or Encryption Gateway. >> >> === SD-DSM / Crypto Applications === >> Software Defined Distributed Security Modules, otherwise known as Crypto >> Applications "Crypto Apps" get compiled from source files on-demand. >> Crypto App source files will be hosted on major public repositories such >> as Github and Apache. >> >> Crypto Applications are scaled across the datacenter through the D-KMS >> API in conjunction with orchestration tools such as Apache Mesos and >> consume the de-encapsulated secrets and keys. >> >> ==== M-Pin Authentication and Secure Channel ==== >> M-Pin is already deployed by such organizations as NTT and Experian in a >> two node Distributed Trust Authority model, where MIRACL and its >> customer each host a D-TA node. In Experian's case, M-Pin was selected >> to provide authentication for Experian's identity assurance platform, >> contracted to the UK Government, for secure authentication of online >> citizens into UK government websites, including HMRC (tax office). M-Pin >> was selected based on its security efficacy and ability to scale to an >> Internet scale user population (UK online citizenry). >> >> The M-Pin Authentication Platform serves as an example of what is >> possible exploiting a pairing based protocol. M-Pin is capable of >> running in a native browser mode, delivering two-factor authentication. >> M-Pin binds to any identity (as long as it is worldly unique) and >> improves the user authentication experience as it can be visualized in a >> familiar ATM-style pin pad. >> >> It's most unique trait is the exploitation of zero knowledge proof >> authentication. The M-Pin Client proves to the M-Pin Server it possesses >> its cryptographic authentication key without revealing it to the server. >> As a result, the M-Pin Server stores no authentication credentials, >> eliminating the possibility of credential (i.e., password) smash n' grab >> attacks. >> >> M-Pin Secure Channel extends the protocol to include authenticated key >> agreement between server and client and mutual client-server >> authentication. The 'agreed key' is unique for each session, possessing >> perfect forward secrecy. >> >> M-Pin Secure Channel takes the agreed key and injects the key into a >> TLS-PSK session between client and server, providing mutual >> authentication and perfect forward secrecy without the need for PKI. >> This cryptographic underpinning can be extended to create secure VPN >> sessions over various protocols. >> >> In an M-Pin client and server context, clients and servers receive their >> shares of their private keys from all three Distributed Trust >> Authorities. In the previously mentioned example, this could be Cloud >> Provider, end customer and neutral third party or any combination >> thereof. >> >> M-Pin Client and Server code are already open source, having been >> previously released under BSD-Clause-3. >> >> The next iteration and revision will be licensed under the Apache >> License. >> >> ==== Cloud Encryption Gateway ==== >> Many proprietary solutions have appeared on the information security >> market to solve data governance issues about securing data in the cloud >> with encryption keys managed by an end customer. To date, most of these >> solutions involve purchasing hardware or virtualized appliances to run >> in an end customer's datacenter, with nothing more delivered than a >> single encryption key under control of the end customer, performing >> sub-optimum deterministic encryption on data sent to the cloud. >> >> The Milagro Cloud Encryption Gateway will be a virtualized or container >> based software, deployed in an end customer's environment. This CEG will >> exploit pairing-based capabilities such as attribute-based encryption >> (anyone in possession of the correct set of attributes can decrypt) and, >> more generally, predicate-based encryption (anyone in possession of the >> right set of attributes and a decryption key corresponding to a >> particular predicate can decrypt). >> >> Doing so increases the flexibility of the solution by being enabled to >> address data residency and governance requirements such as geo-location >> while allowing key management and rotation protocols to be enforced. >> >> == Rationale == >> The benefits of a strong authentication, secure channel and cloud >> encryption via an identity framework for people and things are >> self-evident, and the plethora of homebrew proprietary solutions and >> password nightmares seen today is clear evidence of a need for better >> solutions. >> >> Milagro's distributed trust model is particularly attractive, by virtue >> of dispensing with need for (and potential for abuse of) any central >> trust authority without requiring sophistication - such as understanding >> a Web of Trust - from end users. >> >> A move to incubation at Apache will help the community to grow and take >> on new members in an environment that guarantees open development and >> protection of participants. >> >> This is particularly relevant right now as a second corporate team, NTT >> Data, with its own culture joins as core developers. For the outside >> world, it offers the strong promise of openness. >> >> == Initial Goals == >> Milagro will seek to integrate the existing projects at Certivox (now >> MIRACL) and NTT, and will invite participation from a nascent broader >> community evidenced by the core MIRACL library's 65 watchers and 29 >> forks at Github. >> >> As well as looking to broaden direct participation, it will seek >> synergies with relevant Apache projects, for example by providing >> Milagro plugins for HTTPD and Trafficserver. >> >> The initial software products will be the current standing M-Pin Core >> platform, client libraries and the SD-DSM and Distributed Key Management >> API and client CLI (as noted above). >> >> == Current Status == >> Certivox (now MIRACL) has developed open source software at Github since >> 2014, though the core MIRACL library goes back much further. Projects >> currently at Github include the M-Pin Authentication Platform and the >> MIRACL cryptographic libraries under BSD-Clause-3 and AGPL licenses. >> >> These have attracted both community and corporate interest taking them >> beyond the realm of a single-company project, with NTT being the second >> corporate team to take a substantial part in development. The project >> now seeks to transition smoothly to a full Open Development model. >> >> The core team at Certivox (now MIRACL) is geographically dispersed and >> developers are well-accustomed to using online infrastructure and tools >> for their everyday work. The team at NTTi3 and NTT DATA and other >> contributing developers are included amongst the initial committers. >> >> In addition to MIRACL operating a community D-TA, NTT, Experian and >> Dimension Data have all agreed to host no-charge community D-TAs. Other >> cloud providers are considering and have been engaged. An open source >> platform from which to offer these services is a necessary component to >> finalizing and launching community D-TA's. >> >> == Meritocracy and Community == >> The project is moving from a single (startup) company open source >> project seeking a wider community, to embrace a second corporate >> development team and third-party developers. The project is committed >> to broadening the community through meritocracy, and expects to welcome >> contributions and recognize contributors. >> >> It is hoped that incubation at Apache will help with this broadening, by >> providing a widely-recognised and well-understood framework for working >> collaboratively, growing communities, and protecting contributors. >> >> == Core Developers == >> Dr. Michael Scott, Chief Cryptographer at Certivox (now MIRACL), has >> been a major open source and standards contributor to the field of >> elliptic curve cryptography for over twenty-five years. >> >> Others include >> >> === Existing team at Certivox/MIRACL: === >> . Patrick Hilt - CTO >> . Kealan Mccusker - Cryptographer >> . Stanislav Mihaylov - Architect >> . Simeon Aladhem - Developer >> >> === Existing team at NTT: === >> . Go Yamamoto - Cryptographer >> . Kenji Takahishi - Developer >> >> === Existing ASF Member: === >> . Nick Kew - Developer >> >> == Alignment: == >> Whereas Milagro has no track record of its own, the Certivox (now >> MIRACL) team have been working on related projects at Github. Being >> geographically diverse, the team is well-accustomed to day-to-day >> working in a similar environment to Apache and with similar tools and >> processes. The anticipated role of Apache is to help the community to >> grow without fragmentation of communities, code, or intellectual >> property. >> >> We are not aware of any link with existing Apache projects. However, it >> is likely that several Apache projects may be interested in working with >> Milagro to provide distributed identity services. Plugins for HTTPD and >> Trafficserver are already anticipated. >> >> == Known Risks == >> === Orphaned products === >> Milagro, as successor to the existing MIRACL and M-Pin software at >> github, is at the core of Certivox (now MIRACL)'s business and important >> to NTT, Experian, and other platform adopters who are in the process of >> coming online. >> >> Interest, and with it both developer and user communities, are expected >> to grow strongly. There is little risk of the project losing momentum >> in the foreseeable future. >> >> === Experience with Open Source === >> The software has a history as open source, developed until recently by a >> geographically distributed team within a single company. Github activity >> shows some evidence of a wider community. The major new development >> that leads the proposers to seek incubation at Apache is the coming of >> new corporate interest: while both corporate teams have open-source >> experience, their cultures and backgrounds differ. >> >> We hope that incubation at Apache may help the teams collaborate in an >> environment of mutual benefit, as well as attract independent developers >> to play a full part. >> >> === Homogenous Developers. === >> The established corporate teams are dispersed across several European >> countries and Japan. Prospective developers (whose companies are >> interested in Milagro) are located in other countries, and we anticipate >> a global community. >> >> === Reliance on Salaried Developers === >> Most of the initial committers are salaried developers from the core >> corporate teams. Github activity, including 29 forks of the Miracl >> library, indicates wider community interest, and it is hoped that the >> developer community will grow substantially at Apache. >> >> === Apache Brand === >> The Apache brand is of course seen as an advantage. However, the >> project is more directly concerned with the Apache platform and >> environment to unite diverse teams. >> >> == Relationships with Other Apache Products == >> See Alignment above. >> >> == Documentation == >> Milagro derives from Certivox's existing M-Pin, MIRACL and associated >> tools at github.com/Certivox/ Documentation at http://docs.certivox.com/ >> may also inform and feed into the Milagro project. >> >> == Initial Source and Intellectual Property == >> As soon as Milagro is accepted into the Incubator, Certivox (now MIRACL) >> will transfer the source code and trademark to the ASF with a Software >> Grant, and licensed under the Apache License 2.0. Certivox/MIRACL >> retains rights to its existing MIRACL mark. >> >> == External Dependencies == >> There are no external dependencies and all software is under the sole >> ownership of Certivox/MIRACL. >> >> == Cryptography == >> This is advanced cryptographic software, and as such may be subject to >> government interest and red tape in some countries. However, the >> architecture by which SD-DSM / Crypto Apps are distributed, via open >> source freely available code repositories, is intentional to exploit the >> near universal interpretation of the Wassenar agreement to permit export >> of open source cryptography without restriction (in most cases). >> >> == Required Resources == >> Mailinglists: >> >> * private >> * dev >> * users >> >> Git repository (to mirror existing github repo) >> >> * https://git-wip-us.apache.org/repos/asf/incubator-milagro.git >> >> Issue Tracking >> >> * JIRA repository to be requested >> >> ==== Trust Authority Service ==== >> The podling would like to request a VM at >> "ta.milagro[.incubator].apache.org" with which to run a Community Trust >> Authority. It is anticipated that this will serve as a test facility >> for developers and may become a Trust Authority for the community of ASF >> committers. >> >> == Initial Committers == >> * Akira Nagai (NTT) >> * Brian Spector (Certivox/MIRACL) >> * Fuji Hitoshi (NTT) >> * Genoveffa Pagano (Certivox/MIRACL) >> * Go Yamamoto (NTT) >> * Jordan Katserov (Certivox/MIRACL) >> * Kealan Mccusker (Certivox/MIRACL) >> * Kenji Takahishi (NTT) >> * Michael Scott (Certivox/MIRACL) >> * Milen Rangelove (Certivox/MIRACL) >> * Mitko Yugovski (Certivox/MIRACL) >> * Michael Scott (Certivox/MIRACL) >> * Nick Kew (Apache) >> * Nick Pateman (Certivox/MIRACL) >> * Patrick Hilt (Certivox/MIRACL) >> * Simeon Aladhem (Certivox/MIRACL) >> * Stanislav Mihaylov (Certivox/MIRACL) >> * Tetsutaro Kobayashi (NTT) >> >> == Sponsors == >> === Champion === >> . Nick Kew >> >> === Mentors === >> * Sterling Hughes >> * Jan Willem Janssen >> * Nick Kew >> >> === Sponsoring Entity === >> . The Apache Incubator >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
