[VOTE] Accept Milagro into the Incubator

[Nick Kew <ni...@apache.org>]

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

Re: [VOTE] Accept Milagro into the Incubator

[Niall Pemberton <ni...@gmail.com>]

+1

Niall

On Tue, Dec 15, 2015 at 8:56 AM, Nick Kew <ni...@apache.org> 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
>
>

[RESULT] Re: [VOTE] Accept Milagro into the Incubator

[Nick Kew <ni...@apache.org>]

On Tue, 2015-12-15 at 08:56 +0000, 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.

The vote passes:
+1:  12 votes (9 *binding)
0:   No votes
-1:  No votes

For the record, the +1 votes cast were (in the
order they appear in my mailer):
   *Nick Kew,
    Markus Geiß,
   *Jan Willem Janssen,
   *Rob Vesse,
   *Jean-Baptiste Onofré,
   *Colm O hEigeartaigh,
   *Sterling Hughes,
   *Tom Barber,
   *Flavio Junqueira,
    Brian Spector,
   *Niall Pemberton,
    Patrick Hilt

Next step, we'll set the incubation process in motion!

-- 
Nick Kew


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [VOTE] Accept Milagro into the Incubator

[Markus Geiß <mg...@mifos.org>]

+1 (non-binding)

Cheers


*Markus Geiss*
Chief Architect
RADAR, The Mifos Initiative
mgeiss@mifos.org | Skype: mgeiss.mifos.org | Mobil: +49.152.295.05306 |
http://mifos.org  <http://facebook.com/mifos>
<http://www.twitter.com/mifos>



On Tue, Dec 15, 2015 at 9:56 AM, Nick Kew <ni...@apache.org> 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
>
>

Re: [VOTE] Accept Milagro into the Incubator

[Jan Willem Janssen <ja...@luminis.eu>]

> On 15 Dec 2015, at 09:56, Nick Kew <ni...@apache.org> wrote:
> 
> 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.

Thanks Nick for starting the vote!

+1 from me as well.

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

My world is revolving around INAETICS and Amdatu

Luminis Technologies B.V.
Churchillplein 1
7314 BZ   Apeldoorn
+31 88 586 46 00

http://www.luminis-technologies.com
http://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01

Re: [VOTE] Accept Milagro into the Incubator

[Brian Spector <br...@miracl.com>]

+1 non-binding.

Thanks Flavio!

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

> +1 binding.
>
> Great project, good luck.
>
> -Flavio
>
> > On 15 Dec 2015, at 21:27, Tom Barber <ma...@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 <co...@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
>
>

Re: [VOTE] Accept Milagro into the Incubator

[Flavio Junqueira <fp...@apache.org>]

+1 binding.

Great project, good luck.

-Flavio

> On 15 Dec 2015, at 21:27, Tom Barber <ma...@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 <co...@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

Re: [VOTE] Accept Milagro into the Incubator

[Tom Barber <ma...@apache.org>]

+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 <co...@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
>
>

Re: [VOTE] Accept Milagro into the Incubator

[Sterling Hughes <st...@gmail.com>]

+1 binding 

> On Dec 15, 2015, at 7:51 AM, Colm O hEigeartaigh <co...@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

Re: [VOTE] Accept Milagro into the Incubator

[Colm O hEigeartaigh <co...@apache.org>]

+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

Re: [VOTE] Accept Milagro into the Incubator

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

+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

Re: [VOTE] Accept Milagro into the Incubator

[Rob Vesse <rv...@dotnetrdf.org>]

+1 (binding)

Good luck

Rob

On 15/12/2015 08:56, "Nick Kew" <ni...@apache.org> 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
>





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [VOTE] Accept Milagro into the Incubator

[Patrick Hilt <pa...@miracl.com>]

+1 (non-binding)

Patrick
On Dec 15, 2015 9:56 AM, "Nick Kew" <ni...@apache.org> 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
>
>