1 files changed, 0 insertions, 45 deletions
diff --git a/app/views/pages/technology/identity/en.haml b/app/views/pages/technology/identity/en.haml
deleted file mode 100644
index 27c8b8b..0000000
--- a/app/views/pages/technology/identity/en.haml
+++ /dev/null
@@ -1,45 +0,0 @@
-%h1.first The sad, sorry state of cryptographic identity
-
-%p Existing forms of secure identity are deeply flawed. These systems rely on either a single trusted entity (e.g. Skype), a vulnerable Certificate Authority system (e.g. S/MIME), or keys that cannot be made human memorable (e.g. OpenPGP, OTR). When an identity system is hard to use, it is effectively compromised because too few people take the time to use it properly.
-
-%p The broken nature of existing identities systems (either in security or in usability) is especially troubling because identity remains a bedrock precondition for any message security: you cannot ensure confidentiality or integrity without confirming the authenticity of the other party.
-
-%h1 NickID
-
-%p The cornerstone of the LEAP design is a system to make digital identity for messaging both secure and easy to use. We call this system NickID, since the goal is for the individual to be able to think of cryptographic identity in terms of a domain qualified nickname just as they do with email addresses.
-
-%p NickID is based on a federated structure where the difficult work is pushed to the service providers. Each provider is responsible for the due diligence of properly signing the keys of other providers, akin to the distributed web of trust model of OpenPGP. Providers also are responsible for signing the keys of their users, akin to the Certificate Authority model.
-
-%p When a user sends or receives a message, their software will discover the other party's key and trace a chain of signature's back to the user's service provider. NickID allows for identity that is verified through an end-to-end trust path from any user to any other user in a way that can be automated and is human memorable (e.g. identity in the form user@example.com).
-
-%h1 Users are not websites
-
-%p What about WebID or BrowserID (Mozilla Personas)? These are both interesting cryptographic identity standards that are gaining support and implementations. So why do we need something new?
-
-%p These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a Federated Web of Trust could be combined with something like BrowserID/Personas.
-
-%h1 Attacks and countermeasures
-
-%p Attacks on this system can be prevented with a simple “network perspectives” approach that keeps each service provider honest. Let's enumerate the attacks and how to prevent them. Suppose two providers, A and B.
-
-%p
-  %b Attack 1 - Intercept Outgoing:
-  provider A signs an impostor key for provider B and distributes it to users of A (in order to intercept outgoing messages sent to B).
-
-%p
-  %b Attack 2 - Intercept Incoming:
-  provider A signs an impostor key for one of its own users, and distributes to users of B (in order to intercept incoming messages).
-
-%p
-  %b Attack 3 - Association Mapping:
-  A provider tracks all the requests for key discovery in order to build a map of association.
-
-%p To prevent these attacks, NickID will support independent notaries who sole purpose is to answer a single question: "Do you see the same key that I see?"
-
-%p In order to prevent attack 1, the user's client software will not blindly trust that it has encountered the correct provider key for B. Instead, it will get confirmation from the notaries that they also received the same key (or a key signed by the same key).
-
-%p In order to prevent attack 2, the user's client software will regularly query the notaries for their own key. If the notaries see a different key, the user is alerted that their provider is attempting to intercept their messages.
-
-%p In order to prevent attack 3, the user's client software will be able to use the response of a notary as the initial key discovery, and to proxy a request to one notary through another. Each notary request will be encrypted to the public key of that notary.
-
-%p For this to work, client software that supports NickID will come pre-seeded with a list of notaries and their public keys. Although this sounds like a repeat of the problems associated with the Certificate Authority system, the notaries are actually quite different. Rather than placing irrevocable trust in an authority, clients are only using the notaries for a very narrowly defined ability to provide network perspective.