Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <0D364246-CBE2-4112-B30F-38113AEB4088@gmail.com>
References: <1450169782.6762.16.camel@mimir.webthing.com>
 <566FF1DF.6020604@nanthrax.net>
 <CAB8XdGCEhKDmu1sDFSUwd3dmEsoTn78r+0L5TsuXDfiUK8EHSw@mail.gmail.com>
 <0D364246-CBE2-4112-B30F-38113AEB4088@gmail.com>
From: Tom Barber <magicaltrout@apache.org>
Date: Tue, 15 Dec 2015 21:27:32 +0000
Message-ID: 
 <CABML50cb60_JqDO=w5s1mJtyLMnsd3rXHsR9=WDsxUnvEFT+gw@mail.gmail.com>
Subject: Re: [VOTE] Accept Milagro into the Incubator
To: general@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7bf10ab85446110526f676a7

--047d7bf10ab85446110526f676a7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+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=C3=A9 <jb@nanthra=
x.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
> >>>
> >>>
> >>> =3D Project Proposal: Milagro =3D
> >>> =3D=3D Abstract =3D=3D
> >>> Milagro is a distributed cryptosystem for cloud computing. Its purpos=
e
> >>> is to provide an open source alternative to proprietary key managemen=
t
> >>> and certificate backed cryptosystems used for secure communication an=
d
> >>> authentication. The adoption of Milagro will create a secure, free,
> open
> >>> source alternative to monolithic certificate authorities and eliminat=
e
> >>> single points of failure.
> >>>
> >>> =3D=3D Background =3D=3D
> >>> 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 encryptio=
n,
> >>> 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 wit=
h
> >>> stringent data security requirements won=E2=80=99t 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 re=
al
> >>> 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 t=
he
> >>> 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 =E2=80=9CAlthough the glo=
bal [TLS]
> >>> ecosystem is competitive, it is dominated by a handful of major CAs =
=E2=80=94
> >>> three certificate authorities (Symantec, Comodo, Godaddy) account for
> >>> three-quarters of all issued [TLS] certificates on public-facing web
> >>> servers.=E2=80=9D
> >>>
> >>> 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 trus=
t
> >>> 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.
> >>>
> >>> =3D=3D Proposal =3D=3D
> >>> 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 in=
to
> >>> place a new category of service providers called Distributed Trust
> >>> Authorities (D-TA's).
> >>>
> >>> The M-Pin protocol, and its existing open-source MIRACL implementatio=
n
> >>> on which Milagro will build, are already in use by Experian, NTT, Odi=
n,
> >>> Gov.UK and are being rolled out at scale for zero password multi-fact=
or
> >>> 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.
> >>>
> >>> =3D=3D=3D Why Pairing-Based Cryptography, why now? =3D=3D=3D
> >>> 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-bas=
ed
> >>> schemes. These include the IEEE, ISO, and IETF. Besides identity-base=
d
> >>> 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 t=
he
> >>> NIST "Report on Pairing-based Cryptography" issued in February 2015,
> >>> they state:
> >>>
> >>> "It has been a decade since the first IBE schemes were proposed. Thes=
e
> >>> 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=E2=
=80=99s
> >>> 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 no=
w,
> >>> 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 o=
f
> >>> geographically distributed and organizationally independent Distribut=
ed
> >>> 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 Authoritie=
s
> >>> and the current PKI system will be a landscape that provides secure
> >>> ease-of-use encryption and authentication, does not rely upon a singl=
e
> >>> trusted third party, and yet allows for limited key escrow subject to
> an
> >>> end customer's requirement.
> >>>
> >>> =3D=3D=3D Milagro =3D=3D=3D
> >>> The Milagro libraries and tools consist of:
> >>>
> >>>  * Distributed Key Management Service API
> >>>  * Distributed Key Management CLI
> >>>  * Software Defined Distributed Security Module (SD-DSM) build platfo=
rm
> >>>  * 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/
> >>>
> >>> =3D=3D=3D Distributed Trust Authorities =3D=3D=3D
> >>> 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 serve=
r
> >>> 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 do=
es
> >>> 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.
> >>>
> >>> =3D=3D=3D Distributed Key Management API, CLI, Endpoints =3D=3D=3D
> >>> The core infrastructure that consumes these thirds of private keys an=
d
> >>> 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 encapsulat=
es
> >>> 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.
> >>>
> >>> =3D=3D=3D SD-DSM / Crypto Applications =3D=3D=3D
> >>> 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-KM=
S
> >>> API in conjunction with orchestration tools such as Apache Mesos and
> >>> consume the de-encapsulated secrets and keys.
> >>>
> >>> =3D=3D=3D=3D M-Pin Authentication and Secure Channel =3D=3D=3D=3D
> >>> M-Pin is already deployed by such organizations as NTT and Experian i=
n
> 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 selecte=
d
> >>> 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 a=
n
> >>> 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 authenticatio=
n.
> >>> M-Pin binds to any identity (as long as it is worldly unique) and
> >>> improves the user authentication experience as it can be visualized i=
n
> 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 ke=
y
> >>> agreement between server and client and mutual client-server
> >>> authentication. The 'agreed key' is unique for each session, possessi=
ng
> >>> 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.
> >>>
> >>> =3D=3D=3D=3D Cloud Encryption Gateway =3D=3D=3D=3D
> >>> Many proprietary solutions have appeared on the information security
> >>> market to solve data governance issues about securing data in the clo=
ud
> >>> with encryption keys managed by an end customer. To date, most of the=
se
> >>> solutions involve purchasing hardware or virtualized appliances to ru=
n
> >>> 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 contain=
er
> >>> 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 t=
he
> >>> 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 t=
o
> >>> address data residency and governance requirements such as geo-locati=
on
> >>> while allowing key management and rotation protocols to be enforced.
> >>>
> >>> =3D=3D Rationale =3D=3D
> >>> 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 virt=
ue
> >>> 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 ta=
ke
> >>> 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, N=
TT
> >>> Data, with its own culture joins as core developers. For the outside
> >>> world, it offers the strong promise of openness.
> >>>
> >>> =3D=3D Initial Goals =3D=3D
> >>> 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).
> >>>
> >>> =3D=3D Current Status =3D=3D
> >>> 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 the=
m
> >>> beyond the realm of a single-company project, with NTT being the seco=
nd
> >>> corporate team to take a substantial part in development.  The projec=
t
> >>> now seeks to transition smoothly to a full Open Development model.
> >>>
> >>> The core team at Certivox (now MIRACL) is geographically dispersed an=
d
> >>> developers are well-accustomed to using online infrastructure and too=
ls
> >>> 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.
> >>>
> >>> =3D=3D Meritocracy and Community =3D=3D
> >>> 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 committe=
d
> >>> to broadening the community through meritocracy, and expects to welco=
me
> >>> 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 worki=
ng
> >>> collaboratively, growing communities, and protecting contributors.
> >>>
> >>> =3D=3D Core Developers =3D=3D
> >>> 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
> >>>
> >>> =3D=3D=3D Existing team at Certivox/MIRACL: =3D=3D=3D
> >>>  . Patrick Hilt - CTO
> >>>  . Kealan Mccusker - Cryptographer
> >>>  . Stanislav Mihaylov - Architect
> >>>  . Simeon Aladhem - Developer
> >>>
> >>> =3D=3D=3D Existing team at NTT: =3D=3D=3D
> >>>  . Go Yamamoto - Cryptographer
> >>>  . Kenji Takahishi - Developer
> >>>
> >>> =3D=3D=3D Existing ASF Member: =3D=3D=3D
> >>>  . Nick Kew - Developer
> >>>
> >>> =3D=3D Alignment: =3D=3D
> >>> 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.
> >>>
> >>> =3D=3D Known Risks =3D=3D
> >>> =3D=3D=3D Orphaned products =3D=3D=3D
> >>> 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 expect=
ed
> >>> to grow strongly.  There is little risk of the project losing momentu=
m
> >>> in the foreseeable future.
> >>>
> >>> =3D=3D=3D Experience with Open Source =3D=3D=3D
> >>> The software has a history as open source, developed until recently b=
y
> 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 o=
f
> >>> 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 a=
n
> >>> environment of mutual benefit, as well as attract independent
> developers
> >>> to play a full part.
> >>>
> >>> =3D=3D=3D Homogenous Developers. =3D=3D=3D
> >>> 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.
> >>>
> >>> =3D=3D=3D Reliance on Salaried Developers =3D=3D=3D
> >>> 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.
> >>>
> >>> =3D=3D=3D Apache Brand =3D=3D=3D
> >>> 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.
> >>>
> >>> =3D=3D Relationships with Other Apache Products =3D=3D
> >>> See Alignment above.
> >>>
> >>> =3D=3D Documentation =3D=3D
> >>> 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.
> >>>
> >>> =3D=3D Initial Source and Intellectual Property =3D=3D
> >>> As soon as Milagro is accepted into the Incubator, Certivox (now
> MIRACL)
> >>> will transfer the source code and trademark to the ASF with a Softwar=
e
> >>> Grant, and licensed under the Apache License 2.0. Certivox/MIRACL
> >>> retains rights to its existing MIRACL mark.
> >>>
> >>> =3D=3D External Dependencies =3D=3D
> >>> There are no external dependencies and all software is under the sole
> >>> ownership of Certivox/MIRACL.
> >>>
> >>> =3D=3D Cryptography =3D=3D
> >>> This is advanced cryptographic software, and as such may be subject t=
o
> >>> 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).
> >>>
> >>> =3D=3D Required Resources =3D=3D
> >>> 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
> >>>
> >>> =3D=3D=3D=3D Trust Authority Service =3D=3D=3D=3D
> >>> 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.
> >>>
> >>> =3D=3D Initial Committers =3D=3D
> >>>  * 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)
> >>>
> >>> =3D=3D Sponsors =3D=3D
> >>> =3D=3D=3D Champion =3D=3D=3D
> >>>  . Nick Kew
> >>>
> >>> =3D=3D=3D Mentors =3D=3D=3D
> >>>  * Sterling Hughes
> >>>  * Jan Willem Janssen
> >>>  * Nick Kew
> >>>
> >>> =3D=3D=3D Sponsoring Entity =3D=3D=3D
> >>>  . 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=C3=A9
> >> 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
>
>

--047d7bf10ab85446110526f676a7--