+1 non-binding. Thanks Flavio!
On Wed, Dec 16, 2015 at 9:42 AM, Flavio Junqueira <f...@apache.org> wrote: > +1 binding. > > Great project, good luck. > > -Flavio > > > On 15 Dec 2015, at 21:27, Tom Barber <magicaltr...@apache.org> wrote: > > > > +1 binding > > > > > > On Tue, Dec 15, 2015 at 6:30 PM, Sterling Hughes < > > sterling.hughes.pub...@gmail.com> wrote: > > > >> +1 binding > >> > >>> On Dec 15, 2015, at 7:51 AM, Colm O hEigeartaigh <cohei...@apache.org> > >> wrote: > >>> > >>> +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 > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
