incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Spector <brian.spec...@miracl.com>
Subject Re: [VOTE] Accept Milagro into the Incubator
Date Thu, 17 Dec 2015 10:00:19 GMT
+1 non-binding.

Thanks Flavio!

On Wed, Dec 16, 2015 at 9:42 AM, Flavio Junqueira <fpj@apache.org> wrote:

> +1 binding.
>
> Great project, good luck.
>
> -Flavio
>
> > On 15 Dec 2015, at 21:27, Tom Barber <magicaltrout@apache.org> wrote:
> >
> > +1 binding
> >
> >
> > On Tue, Dec 15, 2015 at 6:30 PM, Sterling Hughes <
> > sterling.hughes.public@gmail.com> wrote:
> >
> >> +1 binding
> >>
> >>> On Dec 15, 2015, at 7:51 AM, Colm O hEigeartaigh <coheigea@apache.org>
> >> wrote:
> >>>
> >>> +1 (binding)
> >>>
> >>> Colm.
> >>>
> >>> On Tue, Dec 15, 2015 at 10:56 AM, Jean-Baptiste Onofré <
> jb@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-unsubscribe@incubator.apache.org
> >>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
> >>> --
> >>> Colm O hEigeartaigh
> >>>
> >>> Talend Community Coder
> >>> http://coders.talend.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message