[soatok]

> Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements?

I'm not sure the wording here is helpful.

Let's start with a simple diagram: https://github.com/fedi-e2ee/public-key-directory-specificat... (see the first one)

A single Public Key Directory will serve many hosts. (You can further add replication and cross-directory checkpointing between directories, to ensure the whole network is transparent, but that's not our concern right now.)

If a host decides to misbehave, there's an independently hosted record of every change to the state machine that maps Actor IDs to public keys. This state machine is backed by a Merkle tree, which includes a proof of inclusion for every change to its state, thereby making it an append-only ledger.

In my design, you don't have to trust the hosts' admins to behave, because the directory keeps them honest.

You also don't have to trust as single directory to behave, since its primary purpose is to be transparent and independently auditable.

If a user wants to revoke their key, they can, but it's an additional protocol message appended to the directory's transparency log.

If a user loses all their secret keys, one of two things can happen:

1. Their instance admin issues a BurnDown, which allows the user to enroll a new public key as if they were a new user.

2. If the user has issued a Fireproof message, the instance admin cannot issue a BurnDown, and the user is locked out of the protocol. This is a trade-off.

Users can move hosts. Users can publish auxiliary data (e.g., SSH public keys), if the extension for that key type is defined and enabled by the directory. Even an attacker with root access to the host cannot arbitrarily or selectively replace a user's public key with their own. With your suggestion, this substitution is trivial.

And that's basically how the system works. But that's not the focus of this blog post.

This blog post is how to solve the seemingly incompatible design goals of:

1. Offer userbase consistency verification for users' public keys.

2. Don't cryptographically inhibit an EU citizen's rights under Article 17 of the GDPR.

3. Don't introduce backdoors to the transparency log that allow them to perform the same trivial attack that your suggestion enables.

[MadsRC]

Totally unrelated to the thread, just a comment on something I noticed: You seem to be posting from 2 different accounts: soatok and some_furry. Dunno if that’s on purpose, but in the off chance that it is not: Now you know.

Love you blog, it’s nice to read something written by an actual human being nowadays. I keep several of you articles bookmarked for reference.

[soatok]

Thanks, happy to help!

> You seem to be posting from 2 different accounts: soatok and some_furry. Dunno if that’s on purpose, but in the off chance that it is not: Now you know.

When folks have interesting comments that warrant a response (or answer, if it contains a question), I very quickly stumble over HN's rate limit. Using this second account works around it.

As a rule, I only use this fallback account when my main (some_furry) is unable to respond to someone's questions.

[michaelt]

Hmm, I guess that mostly makes sense.

If a user has to call into your keyserver to get a key before they can start a conversation with a new friend, as you're the sole authority who can decrypt the Merkle tree entries - does that introduce any problems?

And how will you authenticate shredding requests? Does that just happen out-of-band?

[soatok]

> If a user has to call into your keyserver to get a key before they can start a conversation with a new friend, as you're the sole authority who can decrypt the Merkle tree entries - does that introduce any problems?

It would, but they're addressed by the total design.

> And how will you authenticate shredding requests? Does that just happen out-of-band?

Essentially, yes, it's out-of-band. The actual shredding isn't part of the protocol.

The way I see it is, this only matters when the requestor's lawyers issue a takedown for their client's Personal Data (previously referred to erroneously as PII, though the distinction between the two jargony terms wasn't something I ever needed to care about).

If I didn't take the steps outlined in this blog post, the director's operator would be in a precarious legal situation.

But with this specification, the operator just queries their database for the in-scope records and deletes the stored key.

How that's actually implemented in software, and how the operator verifies that the legal notice for the takedown is authentic, aren't problems I have a readily available solution for. There may not even be a one-size-fits-all solution here.

As I've said, my goal isn't "GDPR Compliance". That's not a property I'm advertising. My goal is to create Key Transparency and a PKI without Authorities for the Fediverse.

I simply don't want to make it logistically impossible for someone else to deploy this in the EU.

[Niluge_KiWi]

How is the following risk mitigated: a Directory operator selectively lies about a record being erased?

Maybe the act of erasure should also be publicly recorded?