s/nickid/nicknym

8 files changed, 17 insertions, 17 deletions

diff --git a/pages/home/en.haml b/pages/home/en.haml
index 754458f..ae1979f 100644
--- a/pages/home/en.haml
+++ b/pages/home/en.haml
@@ -47,7 +47,7 @@
       %tr
         %td June
         %td 2014
-        %td #{link('email')} with #{link 'automatic key validation' => 'nickid'}.
+        %td #{link('email')} with #{link 'automatic key validation' => 'nicknym'}.
       %tr
         %td
         %td 2015
diff --git a/pages/menu.txt b/pages/menu.txt
index 426c514..8522714 100644
--- a/pages/menu.txt
+++ b/pages/menu.txt
@@ -6,7 +6,7 @@ services
   technology
     infosec
     client-app
-    nickid
+    nicknym
     routing
     critiques
 about-us
diff --git a/pages/services/email/en.haml b/pages/services/email/en.haml
index ff2aa9b..4c79e8e 100644
--- a/pages/services/email/en.haml
+++ b/pages/services/email/en.haml
@@ -12,7 +12,7 @@
 
   The LEAP approach to email is to support communication with the legacy email infrastructure while also adding optional layers to the protocol that bring email more in line with modern security practices.
 
-  *Opportunistic Content Encryption:* Whenever possible, all outgoing email will be encrypted to all the recipients. Encryption keys will be automatically discovered and verified using the #{link 'LEAP Identity' => 'nickid'} service.
+  *Opportunistic Content Encryption:* Whenever possible, all outgoing email will be encrypted to all the recipients. Encryption keys will be automatically discovered and verified using the #{link 'LEAP Identity' => 'nicknym'} service.
 
   *Client-encrypted Mail Storage:* Incoming clear-text mail will get encrypted to the user's public key, stored in their cloud storage space, and sync'ed locally for direct access by a mail client.
 
diff --git a/pages/services/en.haml b/pages/services/en.haml
index 56787f3..b7ad664 100644
--- a/pages/services/en.haml
+++ b/pages/services/en.haml
@@ -1,6 +1,6 @@
 %h1.first User Services
 
-%p LEAP's multi-year plan to secure everyday communication breaks down into discrete services, to be rolled out one at a time. When we introduce a new service, integrated support will be added to both the user-facing #{link 'client'} and the server-side #{link 'platform'}. All communication content will be client-side encrypted, and as much of the metadata as possible. Most importantly, all LEAP services will be based on our plan for #{link 'federated secure identity' => 'nickid'} and #{link 'unmappable routing' => 'routing'}.
+%p LEAP's multi-year plan to secure everyday communication breaks down into discrete services, to be rolled out one at a time. When we introduce a new service, integrated support will be added to both the user-facing #{link 'client'} and the server-side #{link 'platform'}. All communication content will be client-side encrypted, and as much of the metadata as possible. Most importantly, all LEAP services will be based on our plan for #{link 'federated secure identity' => 'nicknym'} and #{link 'unmappable routing' => 'routing'}.
 
 %h2 Roadmap
 
diff --git a/pages/services/technology/client-app/en.haml b/pages/services/technology/client-app/en.haml
index 995ec40..07dfab8 100644
--- a/pages/services/technology/client-app/en.haml
+++ b/pages/services/technology/client-app/en.haml
@@ -83,7 +83,7 @@
     If the user chooses to enable the EIP service, then all their internet traffic will pass through the service provider. A nefarious or compromised provider could monitor this traffic.
   -# %li
     %b Notary Keys:
-    The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'nickid'}. If a supermajority of these notaries conspire or get hacked then the security of the identity system will be compromised.
+    The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'nicknym'}. If a supermajority of these notaries conspire or get hacked then the security of the identity system will be compromised.
   %li
     %b Client Software:
     Unless the user builds the client software from the source code, the user will trust LEAP Encryption Access Project for the application builds and code updates.
diff --git a/pages/services/technology/en.haml b/pages/services/technology/en.haml
index e261ad0..2ca579e 100644
--- a/pages/services/technology/en.haml
+++ b/pages/services/technology/en.haml
@@ -15,7 +15,7 @@
   Easy to use client for secure communication.
 
 %p
-  %b #{link 'NickID' => 'nickid'}:
+  %b #{link 'Nicknym' => 'nicknym'}:
   A system for automatic discovery and validation of cryptographic identity.
 
 %p
diff --git a/pages/services/technology/infosec/en.haml b/pages/services/technology/infosec/en.haml
index 35c9ddf..8fd1efe 100644
--- a/pages/services/technology/infosec/en.haml
+++ b/pages/services/technology/infosec/en.haml
@@ -39,7 +39,7 @@
 %ul
   %li
     %b Authenticity:
-    Message security rests entirely on a foundation of authenticity. Without proper validation of encryption keys, you cannot be assured of confidentiality or integrity. Unfortunately, current system of establishing message authenticity are so difficult to use that most users simply ignore this step. LEAP will address these problems with a system of #{link 'strong and automatic identity validation' => 'nickid'}.
+    Message security rests entirely on a foundation of authenticity. Without proper validation of encryption keys, you cannot be assured of confidentiality or integrity. Unfortunately, current system of establishing message authenticity are so difficult to use that most users simply ignore this step. LEAP will address these problems with a system of #{link 'strong and automatic identity validation' => 'nicknym'}.
   %li
     %b Usability:
     There are plenty of high security tools that are nearly impossible for the common user to use correctly. If the tool is too difficult, it will not be widely adopted and will likely be used incorrectly by those who do adopt it. LEAP with address these problems with the #{link 'LEAP client' => 'client'} that is tightly coupled with the server-side software and is autoconfiguring.
diff --git a/pages/services/technology/nickid/en.md b/pages/services/technology/nicknym/en.md
index f763af1..55ff2c8 100644
--- a/pages/services/technology/nickid/en.md
+++ b/pages/services/technology/nicknym/en.md
@@ -1,4 +1,4 @@
-@title = 'NickID'
+@title = 'Nicknym'
 @toc = true
 
 The sad, sorry state of cryptographic identity
@@ -8,12 +8,12 @@ Existing forms of secure identity are deeply flawed. These systems rely on eithe
 
 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.
 
-NickID
+Nicknym
 ============================
 
-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.
+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 Nicknym, 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.
 
-With NickID, we want to be backward compatible with existing public key infrastructures, like OpenPGP and OTR, but also add additional support for automatic validation that happens invisibly in the background without the need for user intervention. NickID does this with three levels of automatic validation:
+With Nicknym, we want to be backward compatible with existing public key infrastructures, like OpenPGP and OTR, but also add additional support for automatic validation that happens invisibly in the background without the need for user intervention. Nicknym does this with three levels of automatic validation:
 
 **Level 1 — TOFU of user keys:** The first and lowest level of validation is to naively accept the key of another user when you first encounter it. This is often called "trust on first use" or TOFU and is used commonly by SSH (and, in common practice, how many people use OTR and OpenPGP). This level of validation is backwards compatible with existing infrastructure, but has many obvious flaws. When you TOFU a user key, you are making a bet that possible attackers against you did not have the foresight to specifically target you with a false key during discovery. TOFU of user keys can be considerably strengthened by using network perspective and by anonymizing the discovery process, but you still have problems with key expiration, ambiguous mapping between email and keys, and with attackers flooding the discovery process (for example, by filling keyservers with bogus keys).
 
@@ -28,14 +28,14 @@ Discovery mechanisms
 
 It is important to not collapse concept of discovery with the concept validation. Although there is some overlap, they should be thought of as entirely distinct.
 
-Currently, no single discovery mechanism has emerged as a dominant method for key discovery. There are several proposed standards, but few people are using any of them. NickID will take an agnostic approach by allowing providers to use whichever standard they choose.
+Currently, no single discovery mechanism has emerged as a dominant method for key discovery. There are several proposed standards, but few people are using any of them. Nicknym will take an agnostic approach by allowing providers to use whichever standard they choose.
 
-To discover a key, a NickID agent will try these methods, in this order:
+To discover a key, a Nicknym agent will try these methods, in this order:
 
+* **Nickserver**: Part of Nicknym is a server-side agent called a "Nickserver" that returns JSON encoded key information in response to a simple HTTP GET with a user's address.
 * **Webfinger**: Webfinger includes a standard mechanism for distributing a user's public key via a simple HTTP request. This is very easy to implement on the server, and very easy to consume on the client side.
-* **DNS**: There are multiple competing standards for key discovery via DNS. When and if one of these emerges predominate, NickID should attempt to use this method when available. DNS discovery, however, has some problems. DNS discovery of keys is much harder to implement, because the service provider must run their own customized authoritative nameserver. Also, since keys can be too big for domain UDP packets, any future-proof DNS method relies on an HTTP request, thus undermining the potential benefit of decentralization you might get from using DNS rather than webfinger.
-* **Keyservers**: As a fallback, NickID agents will try the existing keyservers when other mechanisms are not supported. This should be avoided when possible, because current keyservers are vulnerable to be flooded with bogus keys. This can be improved by prioritizing responses from keyservers that add mailback verification during key registration (currently not supported by many, but easy to add).
-
+* **DNS**: There are multiple competing standards for key discovery via DNS. When and if one of these emerges predominate, Nicknym should attempt to use this method when available. DNS discovery, however, has some problems. DNS discovery of keys is much harder to implement, because the service provider must run their own customized authoritative nameserver. Also, since keys can be too big for domain UDP packets, any future-proof DNS method relies on an HTTP request, thus undermining the potential benefit of decentralization you might get from using DNS rather than webfinger.
+* **Keyservers**: As a fallback, Nicknym agents will try the existing keyservers when other mechanisms are not supported. This should be avoided when possible, because current keyservers are vulnerable to be flooded with bogus keys. This can be improved by prioritizing responses from keyservers that add mailback verification during key registration (although this currently not supported by many keyservers).
 
 Users are not websites
 ==============================
@@ -55,7 +55,7 @@ Most attacks on a FWOT can be mitigated with a simple "network perspectives" app
 
 **Attack 3 - Association Mapping:** A provider tracks all the requests for key discovery in order to build a map of association.
 
-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?"
+To prevent these attacks, Nicknym will support independent notaries who sole purpose is to answer a single question: "Do you see the same key that I see?"
 
 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).