Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage of SECP256k1 public keys in ENS #619

Closed
wants to merge 4 commits into from

Conversation

@Arachnid
Copy link
Contributor

@Arachnid Arachnid commented May 1, 2017

This EIP defines a resolver profile for ENS that permits the lookup of SECP256k1 public keys. This is necessary in order to facilitate ENS lookup for applications such as Whisper.

@gluk256
Copy link
Contributor

@gluk256 gluk256 commented May 4, 2017

This is not suitable for Whisper as long as there is no mechanism to prevent involuntary loss of key/name.

@Arachnid
Copy link
Contributor Author

@Arachnid Arachnid commented May 4, 2017

@gluk256 Can you expand on that so that people who weren't privy to our conversation have some context?

@gluk256
Copy link
Contributor

@gluk256 gluk256 commented May 5, 2017

It will be a big disaster for Whisper project in general and for individual people in particular, if the key/name would change without consent of the previous owner. The reason for this is quite obvious, but of course I will be happy to answer any specific questions.

@jarradh
Copy link

@jarradh jarradh commented May 5, 2017

In Status we inject a child derived key in a HD wallet into Whisper, so we have the ability to recover. in the Whisper gitter channel there were also discussions and agreement to natively support adding keys into the Whisper memory store.

Nevertheless I'm not sure why storing SECP256k1 public keys in ENS should be blocked by how Whisper currently functions, when this proposals applications are broader?

@Arachnid
Copy link
Contributor Author

@Arachnid Arachnid commented May 5, 2017

As I outlined on our call, I believe this is a red herring:

  • Any name system that requires names to be updated is vulnerable to issues relating to change of ownership.
  • Systems such as Whisper where changes of ownership are important events should handle this appropriately regardless of the system, rather than relying on names never changing ownership.
  • Mechanisms are available in ENS to allow you to react to these changes; the best in my opinion is to store the owner of a name on first lookup, and check that owner each time you look up a user's public key. Any change in owner can be reacted to appropriately by either prompting the user or just removing the contact and requiring them to readd them.
@gluk256
Copy link
Contributor

@gluk256 gluk256 commented May 5, 2017

@Arachnid it seems you are deliberately trying to blur the difference between voluntary and involuntary change of ownership. I am not talking about "issues relating to change of ownership", I am just saying that any possibility of COERSIVE change of ownership is absolutely not acceptible for Whisper.

@Arachnid
Copy link
Contributor Author

@Arachnid Arachnid commented May 5, 2017

@Arachnid it seems you are deliberately trying to blur the difference between voluntary and involuntary change of ownership.

No, not at all; I'm trying to point out that you can't eliminate involuntary transfer of ownership with a name system that has permanent names. No name system will protect someone who loses their laptop on a train, for instance.

I also find it disingenuous that your definition of "coercion" includes "I forgot to renew my domain", but excludes "someone threatened to break my kneecaps unless I gave them my domain".

@gluk256
Copy link
Contributor

@gluk256 gluk256 commented May 5, 2017

By "disingenuous" you probably mean that I pretend not to know about criminals, torture and related risks? You probably wonder, why I am trying to protect users from the vulnerabilities of our system, but do not care so much about criminals and torture? Well, because it is not in my power to protect the users from criminals. But it is in my power, and indeed my responsibility to fix the known vulnerabilities in our system.

@Arachnid
Copy link
Contributor Author

@Arachnid Arachnid commented May 5, 2017

No, I'm just critiquing your use of the word "coercion" to mean something that does not mean what most people would associate with the word. When you say "coercive change of ownership" and that includes things such as someone forgetting to renew their name, but excludes things that most people would construe as coercion, that is misleading.

@Arachnid
Copy link
Contributor Author

@Arachnid Arachnid commented Mar 27, 2018

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

  • Frontmatter is now contained between lines with only a triple dash ('---')
  • Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---
EIPS/eip-draft-ens-public-keys.md Outdated Show resolved Hide resolved
@axic
Copy link
Member

@axic axic commented Oct 16, 2018

@Arachnid are you still pursuing this ERC?

@futjrn
Copy link

@futjrn futjrn commented Jan 30, 2019

so what's the status here @Arachnid ? im sure we could lend a hacky hand to pursue as it would be opportune for Herc user experience

@axic
Copy link
Member

@axic axic commented May 9, 2019

@Arachnid are you still considering this to be merged? If not, can you close both this and #620 ?

@@ -0,0 +1,50 @@
---
eip: <to be assigned>

This comment has been minimized.

@axic

axic May 19, 2019
Member

Needs to be filled out.

type: Standards Track
category: ERC
created: 2017-05-01
Requires: 137

This comment has been minimized.

@axic

axic May 19, 2019
Member

Need to be lowercase.

@axic
Copy link
Member

@axic axic commented Dec 16, 2019

@Arachnid are you still pursuing this?

@github-actions
Copy link

@github-actions github-actions bot commented Sep 22, 2020

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Sep 22, 2020
@github-actions
Copy link

@github-actions github-actions bot commented Sep 29, 2020

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

@github-actions github-actions bot closed this Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants