vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-26 17:42:06 +01:00
Code Issues Projects Releases Packages Wiki Activity

edits to #999549dcc3

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-25 11:51:59 +01:00
parent 02b0785584
commit 10ce55fa77
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
book/source/04-certificates.md
View file

@ -143,13 +143,13 @@ For further conventions on User IDs, refer to the document [draft-dkg-openpgp-us
**Split User IDs**
One proposed variant for encoding identities in User ID is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). This style of User IDs is currently uncommon, but there is no strong technical impediment to using this format right now[^dkg-split].
One proposed variant for encoding identities in User IDs is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). Although currently uncommon, there are currently no significant technical barriers to implementing this format[^dkg-split].
[^dkg-split]: Note that in the past, there were stumbling blocks in the OpenPGP ecosystem, see ["What were Separated User IDs"](https://dkg.fifthhorseman.net/blog/2019-dkg-openpgp-transition.html#what-were-separated-user-ids) from January 2019, by Daniel Kahn Gillmor.
[^dkg-split]: Historically, the OpenPGP ecosystem faced challenges in this context. For further details, refer to Daniel Kahn Gillmor's January 2019 article, ["What were Separated User IDs"](https://dkg.fifthhorseman.net/blog/2019-dkg-openpgp-transition.html#what-were-separated-user-ids).
An argument for split User IDs is that a name and an email address are two distinct identities, which are easier to reason about separately. This is particularly relevant when third parties consider certifying that an identity is legitimately connected to a certificate.
The rationale for split User IDs lies in the distinction between a name and an email address, which represent two separate facets of an individual's identity. Separating these elements simplifies the process for third parties tasked with certifying that an identity is legitimately connected to a certificate.
For example, some third party may be sure about the email identity of a contact, and happy to issue a certification for an email-based identity (such as `<alice@example.org>`). But they may not have any insight into a name-based identity (such as `Alice Adams`), and thus not willing to certify such a name-based identity.
Consider this scenario: A third party is confident about the email-based identity of an individual (e.g.,`<alice@example.org>`) and is willing to certify it. However, they might not have sufficient knowledge about the person's name-based identity (e.g., `Alice Adams`), so are unwilling to extend the same level of certification. Split User IDs address this dichotomy by allowing distinct certification processes for each type of identity.
(primary_user_id)=
### Implications of the Primary User ID