Specifying an email address should display only UID(s) containing that address #81

Open
opened 1 year ago by ethan · 4 comments
ethan commented 1 year ago

Related to #22 and #40 but with a different goal: When queried with /username@domain.org or /hkp/username@domain.org, Keyoxide should display only the user IDs (UID) containing the specified email address (i.e., username@domain.org).

Current behavior

Profile pages for which the key is retrieved from a WKD or using HKP with a specific email address will display all identities (email addresses and notations) found on the key. Email addresses without any associated claims are also shown.

By requesting the page for yarmo at yarmo.eu for example, I will also see his email addresses under keyoxide.org and mackenba.ch. As expected, the browser will also send requests to validate the associated claims.

Context and potential problems with the current model

Unless I misunderstood his comment, @yarmo was not a fan of a similar concept in #40. He wrote that "adding this feature [given an email address, use the claim verification to search by fingerprint] would easily tip that balance towards privacy infringement."

As someone distributing a key

  • #22 recognizes that different UIDs can hold different notations (e.g., personal social media). The Keyoxide FAQ likewise notes that "a person can have multiple personas, or online identities." With greater isolation of online identities in mind, then, I might want to link to different Keyoxide profile pages (e.g., /hkp/personal@example.com and /hkp/professional@example.com) based on the context.

  • @wiktor wrote in #40 that "Keyoxide doesn't store any of this data and the key source - keys.openpgp.org has (by design) a limited search system." While it is true that both keys.openpgp.org and Keyoxide require a full email address, the goal at keys.openpgp.org is that "a normal user [...] cannot discover any new email addresses." The goal at keys.openpgp.org seems a reasonable one. By displaying all user IDs, even when queried for a specific address, Keyoxide enables "a normal user" to easily discover new addresses.

  • Someone who doesn't need or want multiple primary keys will only have one fingerprint. That being said, searching by fingerprint should continue displaying all identities and claims. Compared to a key's fingerprint, it is often easier to find and verify a person's email address on a website, within an organization, etc.

As someone verifying proofs or using cryptographic operations

  • People using a fingerprint on Keyoxide might not be surprised to find multiple email addresses associated with it. Someone who specified an email address might expect results linked only to that address.

  • Someone who specified an email address might want to send an encrypted message to that person. Given that the first time someone encounters the terms "fingerprint" (in this context) and "OpenPGP" could be on Keyoxide, listing additional addresses might be confusing.

Considerations

  • Signature profiles solve this problem for situations in which at least one of the following is true:
  1. The WKD is reliable and configured to serve only the specific user ID.
  2. Only one identity is verified with keys.openpgp.org.
  3. The key's owner does not want to link directly to a profile page.
  4. The WKD or keys.openpgp.org sends multiple user IDs, but the visitor does not investigate further by downloading the key or going to the full profile page (the email address that signed the message is known).
  • Nothing would need to change for a key published with only one user ID.

  • No one would be required to host their own WKD in order to avoid a listing of all addresses verified with keys.openpgp.org (if applicable).

  • I recognize that, if downloaded from keys.openpgp.org, an imported key would still list all identities verified with their server. Domains using their managed WKD service (i.e., a CNAME record to wkd.keys.openpgp.org) will also continue to send all verified identities.

Hosts who do not export by UID before uploading to their WKD will also send multiple identities.

Note that the OpenPGP Web Key Directory (IETF) draft asks the following of, at a minimum, mail providers:

Other User ID packets and their associated binding signatures MUST be removed before publication. [...] It is further recommended that a client filters a received key or a key send for a publication requests so that only the specific User ID with the mail address of the provider is imported or send.

  • I didn't mention Keybase because we're limited to /username/FINGERPRINT.

While the inclusion of multiple user IDs even when an address is specified is primarily an upstream issue, Keyoxide should hide additional identities from the UI.

Related to #22 and #40 but with a different goal: When queried with `/username@domain.org` or `/hkp/username@domain.org`, Keyoxide should display only the user IDs (UID) containing the specified email address (i.e., `username@domain.org`). ## Current behavior Profile pages for which the key is retrieved from a [WKD](https://keyoxide.org/yarmo@yarmo.eu) or using [HKP](https://keyoxide.org/hkp/yarmo@yarmo.eu) with a specific email address will display all identities (email addresses and notations) found on the key. Email addresses without any associated claims are also shown. By requesting the page for `yarmo at yarmo.eu` for example, I will also see his email addresses under `keyoxide.org` and `mackenba.ch.` As expected, the browser will also send requests to validate the associated claims. ## Context and potential problems with the current model Unless I misunderstood his comment, @yarmo was not a fan of a similar concept in #40. He wrote that "adding this feature [given an email address, use the claim verification to search by fingerprint] would easily tip that balance towards privacy infringement." **As someone distributing a key** * #22 recognizes that different UIDs can hold different notations (e.g., personal social media). [The Keyoxide FAQ](https://keyoxide.org/faq/) likewise notes that "a person can have multiple personas, or online **identities.**" With greater isolation of online identities in mind, then, I might want to link to different Keyoxide profile pages (e.g., `/hkp/personal@example.com` and `/hkp/professional@example.com`) based on the context. * @wiktor wrote in #40 that "Keyoxide doesn't store any of this data and the key source - keys.openpgp.org has (by design) a limited search system." While it is true that both `keys.openpgp.org` and Keyoxide require a full email address, the goal at `keys.openpgp.org` is that ["a normal user [...] cannot discover any new email addresses."](https://keys.openpgp.org/about/faq#search-substring) The goal at `keys.openpgp.org` seems a reasonable one. By displaying all user IDs, even when queried for a specific address, Keyoxide enables "a normal user" to easily discover new addresses. * Someone who doesn't need or want multiple primary keys will only have one fingerprint. That being said, searching by fingerprint should continue displaying all identities and claims. Compared to a key's fingerprint, it is often easier to find and verify a person's email address on a website, within an organization, etc. **As someone verifying proofs or using cryptographic operations** * People using a fingerprint on Keyoxide might not be surprised to find multiple email addresses associated with it. Someone who specified an email address might expect results linked only to that address. * Someone who specified an email address might want to send an encrypted message to that person. Given that the first time someone encounters the terms "fingerprint" (in this context) and "OpenPGP" could be on Keyoxide, listing additional addresses might be confusing. ## Considerations * Signature profiles solve this problem for situations in which at least one of the following is true: 1. The WKD is reliable and configured to serve only the specific user ID. 2. Only one identity is verified with `keys.openpgp.org`. 3. The key's owner does not want to link directly to a profile page. 3. The WKD or `keys.openpgp.org` sends multiple user IDs, but the visitor does not investigate further by downloading the key or going to the full profile page (the email address that signed the message is known). * Nothing would need to change for a key published with only one user ID. * No one would be required to host their own WKD in order to avoid a listing of all addresses verified with `keys.openpgp.org` (if applicable). * I recognize that, if downloaded from `keys.openpgp.org`, an imported key would still list all identities verified with their server. Domains using their managed WKD service (i.e., a CNAME record to `wkd.keys.openpgp.org`) will also continue to send all verified identities. Hosts who do not export by UID before uploading to their WKD will also send multiple identities. Note that the [OpenPGP Web Key Directory (IETF) draft](https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-11#section-5) asks the following of, at a minimum, mail providers: > Other User ID packets and their associated binding signatures MUST be removed before publication. [...] It is further recommended that a client filters a received key or a key send for a publication requests so that only the specific User ID with the mail address of the provider is imported or send. * I didn't mention Keybase because we're limited to `/username/FINGERPRINT`. While the inclusion of multiple user IDs even when an address is specified is primarily an upstream issue, Keyoxide should hide additional identities from the UI.

I might want to link to different Keyoxide profile pages (e.g., /hkp/personal@example.com and /hkp/professional@example.com) based on the context.

If keys.openpgp.org returns the same data for these two endpoints I don't see why Keyoxide should do the filtering. Maybe you should ask the upstream project? The same goes for their WKD-as-a-Service thingy.

The solution is quite easy if you control your own domain: just use WKD and provide filtered keys for both personal@ and professional@ keys.

Changing this now could be quite surprising as people usually think of WKD or per-email lookup as just discovery mechanism not filtering one and usually there is no harm in showing more e-mail addresses. For example if I saw on your /personal@example.com an e-mail saying professional@company.com I'd immediately know that you probably work for company.com or you're associated in some way with them.

> I might want to link to different Keyoxide profile pages (e.g., /hkp/personal@example.com and /hkp/professional@example.com) based on the context. If keys.openpgp.org returns the same data for these two endpoints I don't see why Keyoxide should do the filtering. Maybe you should [ask the upstream project](https://gitlab.com/hagrid-keyserver/hagrid/-/issues)? The same goes for their WKD-as-a-Service thingy. The solution is quite easy if you control your own domain: just use WKD and provide filtered keys for both personal@ and professional@ keys. Changing this now could be quite surprising as people usually think of WKD or per-email lookup as just discovery mechanism not filtering one and usually there is no harm in showing more e-mail addresses. For example if I saw on your /personal@example.com an e-mail saying professional@company.com I'd immediately know that you probably work for company.com or you're associated in some way with them.
Poster

From my original post

With greater isolation of online identities in mind, then, I might want to link to different Keyoxide profile pages (e.g., /hkp/personal@example.com and /hkp/professional@example.com) based on the context.

I should have used /personal@example.com and /professional@example.com without /hkp/ to make it clear that example.com hosts a WKD ignoring the Internet-Draft. This situation would involve someone with two accounts or aliases from the same mail provider (e.g., a custom domain).

From Wiktor's response

For example if I saw on your /personal@example.com an e-mail saying professional@company.com I'd immediately know that you probably work for company.com or you're associated in some way with them.

I didn't describe this situation (a key with UID from multiple domains) explicitly, but I should have done so. It's more likely to be the case using /hkp/ and keys.openpgp.org (assuming a WKD host has at least filtered for domain name).

The owner of personal@example.com might want to post /hkp/personal@example.com (thus sourcing their key from keys.openpgp.org) without someone also finding out the owner works at company.com or has an account from organization.org (e.g., Riseup).

From Wiktor's response

Changing this now could be quite surprising as people usually think of WKD or per-email lookup as just discovery mechanism not filtering one and usually there is no harm in showing more e-mail addresses.

In terms of thinking of WKD or per-email lookup as a discovery mechanism, it might be that this issue is also along the lines of #51. I see the Keyoxide web interface as a way for people who don't use OpenPGP to verify the identity (digital signature, social media, etc.) of someone who does have an OpenPGP key. In this case, the person with an OpenPGP key is sharing a Keyoxide profile page elsewhere (e.g., email signature, social media, website). This person does not necessarily expect visitors to use the page beyond verification; the link to download their key is secondary. Discovery is limited to claims made for a specific email address (if applicable).

Your response suggests that Keyoxide is intended more as a web-based substitute for importing a key with GPG. The assumption then is that a visitor would have imported the key using OpenPGP software and found all UID anyway.

Again, I wouldn't expect Keyoxide's current behavior to change when using /FINGERPRINT -- only when queried with a specific address using /me@example.com or /hkp/me@example.com.

The solution is quite easy if you control your own domain: just use WKD and provide filtered keys for both personal@ and professional@ keys.

Not everyone will have this option, but if someone sees this issue and wants to set up a WKD as specified, replace the export command given in most guides with:

gpg -o 32characterHash --no-armor --export --export-options export-minimal --export-filter keep-uid=mbox=local-part@example.com

From my original post > With greater isolation of online identities in mind, then, I might want to link to different Keyoxide profile pages (e.g., /hkp/personal@example.com and /hkp/professional@example.com) based on the context. I should have used `/personal@example.com` and `/professional@example.com` without `/hkp/` to make it clear that `example.com` hosts a WKD ignoring the Internet-Draft. This situation would involve someone with two accounts or aliases from the same mail provider (e.g., a custom domain). From Wiktor's response > For example if I saw on your /personal@example.com an e-mail saying professional@company.com I'd immediately know that you probably work for company.com or you're associated in some way with them. I didn't describe this situation (a key with UID from multiple domains) explicitly, but I should have done so. It's more likely to be the case using `/hkp/` and `keys.openpgp.org` (assuming a WKD host has at least filtered for domain name). The owner of `personal@example.com` might want to post `/hkp/personal@example.com` (thus sourcing their key from `keys.openpgp.org`) without someone also finding out the owner works at `company.com` or has an account from `organization.org` (e.g., Riseup). From Wiktor's response > Changing this now could be quite surprising as people usually think of WKD or per-email lookup as just discovery mechanism not filtering one and usually there is no harm in showing more e-mail addresses. In terms of thinking of WKD or per-email lookup as a discovery mechanism, it might be that this issue is also along the lines of #51. I see the Keyoxide web interface as a way for people who don't use OpenPGP to verify the identity (digital signature, social media, etc.) of someone who does have an OpenPGP key. In this case, the person with an OpenPGP key is sharing a Keyoxide profile page elsewhere (e.g., email signature, social media, website). This person does not necessarily expect visitors to use the page beyond verification; the link to download their key is secondary. Discovery is limited to claims made for a specific email address (if applicable). Your response suggests that Keyoxide is intended more as a web-based substitute for importing a key with GPG. The assumption then is that a visitor would have imported the key using OpenPGP software and found all UID anyway. Again, I wouldn't expect Keyoxide's current behavior to change when using `/FINGERPRINT` -- only when queried with a specific address using `/me@example.com` or `/hkp/me@example.com`. > The solution is quite easy if you control your own domain: just use WKD and provide filtered keys for both personal@ and professional@ keys. Not everyone will have this option, but if someone sees this issue and wants to set up a WKD as specified, replace the export command given in most guides with: `gpg -o 32characterHash --no-armor --export --export-options export-minimal --export-filter keep-uid=mbox=local-part@example.com`
Poster

While announcing Keyoxide's launch, the use case is also described by @yarmo in response to the question "Why only encryption and signature verification?"

If you wish to decrypt messages and sign them, you need a keypair. If you have a keypair, you probably have the knowledge to use dedicated tools like the CLI or Kleopatra. And if you do, you probably won’t be using Keyoxide.org directly yourself. Indeed, if you possess a PGP keypair, Keyoxide.org is the tool you send to others to interact with your public key more easily.

[While announcing Keyoxide's launch,](https://yarmo.eu/post/keyoxide#why-only-encryption-and-signature-verification%3F) the use case is also described by @yarmo in response to the question "Why only encryption and signature verification?" > If you wish to decrypt messages and sign them, you need a keypair. If you have a keypair, you probably have the knowledge to use dedicated tools like the CLI or Kleopatra. And if you do, you probably won’t be using Keyoxide.org directly yourself. Indeed, if you possess a PGP keypair, Keyoxide.org is the tool you send to others to interact with your public key more easily.
yarmo added the
enhancement
label 1 year ago
Owner

Thanks for the well-structured and argumented issue.

While I regret that keys.openpgp.org doesn't stick to only returning the provided UID, I think I am siding with @ethan on this one.

From keyoxide/web#81

For example if I saw on your /personal@example.com an e-mail saying professional@company.com I'd immediately know that you probably work for company.com or you're associated in some way with them.

Isn't that exactly what we're trying to avoid? Yes, two identities that should remain separated should not be put into the same key. That is asking for trouble. But that doesn't mean the software shouldn't try: we can do the "right thing" even when given all the stuff needed for the "wrong thing".

Right and wrong are too harsh and extreme in this context. I need to mull this over. My instinct says this would be a good path.

Perhaps we could have notations pointing at "associated identities" if one truly wants the identities linked.

Thanks for the well-structured and argumented issue. While I regret that `keys.openpgp.org` doesn't stick to only returning the provided UID, I think I am siding with @ethan on this one. From https://codeberg.org/keyoxide/web/issues/81#issuecomment-187173 > For example if I saw on your /personal@example.com an e-mail saying professional@company.com I'd immediately know that you probably work for company.com or you're associated in some way with them. Isn't that exactly what we're trying to avoid? Yes, two identities that should remain separated should not be put into the same key. That is asking for trouble. But that doesn't mean the software shouldn't try: we can do the "right thing" even when given all the stuff needed for the "wrong thing". Right and wrong are too harsh and extreme in this context. I need to mull this over. My instinct says this would be a good path. Perhaps we could have notations pointing at "associated identities" if one truly wants the identities linked.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.