incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Junqueira <>
Subject Re: [VOTE] Accept Milagro into the Incubator
Date Wed, 16 Dec 2015 09:42:13 GMT
+1 binding.

Great project, good luck.


> On 15 Dec 2015, at 21:27, Tom Barber <> wrote:
> +1 binding
> On Tue, Dec 15, 2015 at 6:30 PM, Sterling Hughes <
>> wrote:
>> +1 binding
>>> On Dec 15, 2015, at 7:51 AM, Colm O hEigeartaigh <>
>> wrote:
>>> +1 (binding)
>>> Colm.
>>> On Tue, Dec 15, 2015 at 10:56 AM, Jean-Baptiste Onofré <>
>>> 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
>>>>> 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
>>>>> 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
>>>>> 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]( 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
>>>>> === 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
>>>>> 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
>>>>> 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
>>>>> 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 Documentation at
>>>>> 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
>>>>> 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)
>>>>> *
>>>>> Issue Tracking
>>>>> * JIRA repository to be requested
>>>>> ==== Trust Authority Service ====
>>>>> The podling would like to request a VM at
>>>>> "ta.milagro[.incubator]" 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:
>>>>> For additional commands, e-mail:
>>>> --
>>>> Jean-Baptiste Onofré
>>>> Talend -
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> --
>>> Colm O hEigeartaigh
>>> Talend Community Coder
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message