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

keyids to users: 1:1 or 1:N ? #41

Open
philpennock opened this issue May 14, 2020 · 2 comments
Open

keyids to users: 1:1 or 1:N ? #41

philpennock opened this issue May 14, 2020 · 2 comments

Comments

@philpennock
Copy link

Folks.

With Keybase, we would have multiple proofs for our Keybase identity, so keyid:public-identifier was a 1:many relationship. With Keys.pub, I am getting an error when I try to add any key after the first.

I can find no clear statement in the docs as to whether or not we should be creating a new keyid for each public identity (1:1) or including multiple public identifiers in the sigchain for one keyid. Which is it supposed to be, please?

.cache/Keys/keysd.log time="2020-05-14T05:43:19.583252809Z" level=error msg="finished unary call with code Unknown" error="failed to generate user statement: user set in sigchain already" grpc.code=Unknown grpc.method=UserAdd grpc.service=service.Keys grpc.start_time="2020-05-14T05:43:19Z" grpc.time_ms=148.718 peer.address="127.0.0.1:37084" span.kind=server system=grpc

In this case, the keyid is kex1g4x72y80l8vhtzsy9fchpj4fx4nzyzcrmmukmm37lz02cvavm9mshq6gx5 and I've tried adding a Reddit proof https://old.reddit.com/r/keyspubmsgs/comments/gjg2p9/syscomet/ and had tried a Twitter proof before that (since deleted, since it didn't work).

Am I doing something very wrong?

keys is 0.0.45 2a859beaec195f67b14448f9c7a6edec1dada32c on Linux, and I just tried a keys/keysd built from source at git revision 60eff28aa8d0920def33f474f7c622ae3bcaa5bc which did not help.

I'm running keys inside a Docker container setup I threw together, at https://github.com/PennockTech/keyspub-docker.

Thanks.

@gabriel
Copy link
Contributor

gabriel commented May 15, 2020

Yeah I am explicitly enforcing that only 1 user statement links to a single key but we will probably open that up at some point hopefully soon?

I also want to allow for new ("sub"?) keys (like device keys) to be created/published in the sigchain, and allow for revoking them as well, for example, if a device was lost or unprovisioned.

@notpushkin
Copy link

Thank you so much for this project @gabriel!

Is the plan to still keep the one master key and only allow it to sign subkeys / device keys, or any device will be able to provision another one as well (Keybase-style)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants