+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
