Internet-Draft J.J. Brucker draft-foopgp-urn-eid-00 foopgp Intended status: Standards Track Mnème Expires: 2027-07-14 foopgp 14 July 2026 The 'eid' URN Namespace — Entity IDentifiers draft-foopgp-urn-eid-00 Abstract This document defines the "eid" Uniform Resource Name (URN) namespace: compact, deterministic, privacy-conscious Entity IDentifiers (eids), and requests its registration with IANA. Two eid variants are defined in this document: u4, for human individuals based on civil-registry birth data and the ICAO 9303 Machine-Readable Zone standard; and u5, for any entity identified by its temporal and geographic origin. Both variants share a common 14-character geographic suffix encoding terrestrial coordinates. eids are the identity anchor of the "PGP ID" system, which applies them to provide a decentralised digital identity through OpenPGP certificates and their web of trust. This specification supersedes the earlier "udid4" and "nhid2" drafts from the Open-UDC project (2010-2014). Status of This Memo This is an Internet-Draft submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). They are subject to change and may be replaced or obsoleted at any time. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. This Internet-Draft will expire on 27 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). Table of Contents 1. Introduction 2. Conventions and Terminology 3. Common Structures 3.1. Geographic Suffix (coord14) 3.1.1. Sub-national Extensions 3.2. Character Set 4. u4: Human Birth Identity String 4.1. Overview 4.2. MRZ Input Construction 4.2.1. Surname Field 4.2.2. Given Name Fields 4.2.3. Birth Date Field 4.3. Hash Computation 4.4. u4 String Format 4.5. URN and OpenPGP UID Format 4.6. Examples 5. u5: Temporal-Origin Identity String 5.1. Overview 5.2. Timestamp Field (ts16) 5.3. u5 String Format 5.4. URN and OpenPGP UID Format 5.5. Examples 6. Application Usages (Informative) 6.1. OpenPGP UID 6.2. Certificate Lookup on Keyservers 6.3. Unix User ID Derivation 6.4. Hardware Security Token 6.4.1. Rationale 6.4.2. Login Data Field (DO 5E) 6.4.3. Name of Cardholder Field (DO 5B) 6.4.4. URL of Public Key Field (DO 5F50) 6.4.5. Reference Tools 6.5. Home Directory Path 6.6. System Configuration 6.7. Avatar (User Attribute Packet) 7. Encoding Notes 8. Privacy Considerations 9. Security Considerations 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Appendix A. Country Coordinate Table Authors' Addresses 1. Introduction Strong identity in decentralised systems — webs of trust, cooperative governance, digital commons — requires a universal, unforgeable, yet privacy-conscious way to represent individuals and entities. This document meets this requirement by defining the "eid" URN namespace [RFC8141]: short, self-contained Entity IDentifiers, or eids, that: o form the Namespace Specific String of a URN ("urn:eid:u4vb6UZ...") which can be carried verbatim in an OpenPGP UID, making the identity verifiable through the standard web of trust — this application is the "PGP ID" system; o are derived deterministically from widely-available civil records (for humans) or from creation metadata (for any other entity), so that any party with the underlying data can independently recompute them; o are obfuscated through a one-way hash, providing a degree of pseudonymity while remaining publicly auditable by the holder; o encode a geographic coordinate, anchoring the identity in physical space and enabling coarse-grained uniqueness disambiguation. The term "eid" covers every variant defined in this document and any future extension. This specification defines two eid variants: u4: For human individuals. Derived from the person's surname, given names, and date of birth, following the Machine-Readable Zone conventions of ICAO Document 9303 [ICAO9303]. A u4 eid is unique and permanent for a given individual: it is computed from birth-certificate data and does not change upon marriage, legal name change, or any other life event. u5: For any entity identified by its moment and place of origin. This includes organisations, software agents, automated processes, or any human who, for any reason, chooses to be identified through temporal-origin data rather than through birth-certificate data. There is no requirement that a u5 holder be a non-human entity; a sole-trader operating under a company registration number is a familiar analogue. Both variants share a common 14-character geographic suffix (Section 3). Future variants (u6, u7, ...) MAY be defined as new identity classes emerge; the umbrella term "eid" remains stable regardless of how many variants are eventually specified. Historically, these identifiers were called "udid4" and "nhid2" in the Open-UDC project drafts [OPENUDCDRAFT]. This document updates and formalises those definitions, and introduces "eid" as the collective name. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. The following terms are used throughout this document: eid: Entity IDentifier. The umbrella term covering every identifier variant defined in this document (u4, u5) and any future extension. An eid is always one of those variants — there is no "bare eid" string; the term is used when the discussion applies to any variant indifferently, or when the specific variant is irrelevant. NID, NSS: URN Namespace IDentifier and Namespace Specific String, as defined in [RFC8141]. This document registers the NID "eid"; the NSS is the variant tag glued to the variant string, with no separator (e.g. "u4vb6UZTMKsllgoH760pc0xwe_42.17-002.76"). MRZ: Machine-Readable Zone, as defined in ICAO Document 9303 [ICAO9303]. base64url: The URL- and filename-safe Base 64 encoding defined in Section 5 of [RFC4648], using the alphabet "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_" without padding characters. MRZ-transliterate(s): The operation that converts a Unicode string to an uppercase ASCII string suitable for MRZ use: decompose to NFD, strip combining diacritical marks (Unicode category Mn), remove all characters outside [A-Z], and convert to upper case. This is equivalent to a subset of the transliteration rules specified in ICAO 9303 Part 3 [ICAO9303]. coord14: The 14-character geographic coordinate suffix defined in Section 3.1. ts16: The 16-character temporal-origin prefix used in u5 identifiers, defined in Section 5.2. 3. Common Structures 3.1. Geographic Suffix (coord14) Both u4 and u5 eid variants include a 14-character suffix encoding a terrestrial location. This suffix is called coord14 and has the following format: coord14 = "e" lat5 lon8 where: "e": A literal lower-case letter indicating an Earth (terrestrial) coordinate. Future revisions MAY define other leading characters for non-terrestrial locations. lat5: A 5-character latitude field. Format: sign (1 char) + 2-digit integer part + "." + 2-digit fractional part. The sign character is "_" for non-negative latitudes (Northern hemisphere) or "-" for negative latitudes (Southern hemisphere). lat5 = ("_" / "-") DIGIT DIGIT "." DIGIT DIGIT Accepted range: [-90.00, +90.00]. lon8: An 8-character longitude field using the same sign convention as lat5, with a 3-digit integer part: lon8 = ("_" / "-") DIGIT DIGIT DIGIT "." DIGIT DIGIT Accepted range: [-179.99, +180.00]. The geographic coordinates used for a human birth place SHOULD correspond to the centroid coordinates of the sovereign country indicated in the birth certificate, as recorded in the canonical reference table defined in Appendix A. Using country-level coordinates rather than the exact birth town protects privacy while preserving a meaningful geographic anchor. When two individuals share the same u4 hash (a collision), one of them MAY be assigned a different coord14 — for instance, using a departmental or regional centroid — to restore uniqueness. Section 3.1.1 specifies how sub-national entries are added. Example coord14 values: e_42.17-002.76 (France centroid) e_43.30_005.38 (Marseille, France) e_50.64_004.64 (Belgium centroid) e-33.87_151.21 (Sydney, Australia) 3.1.1. Sub-national Extensions The country-level table in Appendix A is the default. When collision resolution requires a finer-grained coord14, an implementation MAY draw the value from a sub-national table keyed by ISO 3166-2 subdivision codes [ISO3166-2]. Key format: sub-key = country-alpha-3 "-" subdivision-code where country-alpha-3 is the ISO 3166-1 alpha-3 code already used in Appendix A, and subdivision-code is the subdivision portion of the ISO 3166-2 code (i.e., the part after the country prefix). Example sub-keys: FRA-75 (Paris, France) FRA-13 (Bouches-du-Rhône, France) USA-CA (California, United States) CHE-GE (Geneva, Switzerland) The coord14 value associated with a sub-key SHOULD be the centroid of the corresponding administrative subdivision. Collision-resolution procedure: 1. Two distinct holders A and B compute the same base22 prefix (Section 4.4) AND share the country-level coord14. 2. The conflicting party (by convention, the most recently provisioned eid, or by mutual agreement) re-computes its coord14 from the sub-key matching the birth town's widest-containing subdivision. 3. If the collision persists, the procedure recurses with the next-narrower subdivision (region → department → commune, and below if the local registry supports it). Sub-national tables MUST be published openly so that any verifier can re-derive the coord14 deterministically. Conformant tools SHOULD ship a minimal built-in table and SHOULD allow operators to add entries through a documented configuration mechanism. Coordination of overlapping or conflicting entries between independent tables is out of scope for this specification; a future revision MAY define a centralised registry. 3.2. Character Set Taken together, the u4 and u5 variants use only characters from the set: [A-Za-z0-9_\-.] In detail: o The base22 prefix of u4 (Section 4.4) draws from [A-Za-z0-9_\-] (the 64-character base64url alphabet). o The ts16 prefix of u5 (Section 5.2) is the only producer of "." (decimal point in the seconds.milliseconds part) and the only other source of "-" beyond coord14 (lead character for pre-1970 timestamps). o coord14 (Section 3.1) uses "e", digits, "_", "-", and ".". This combined character set is safe for use in OpenPGP UID comment fields, URLs, and filenames without percent-encoding. 4. u4: Human Birth Identity String 4.1. Overview The u4 identifier for a human individual is a 36-character string: u4 = base22 coord14 where base22 is the first 22 characters of the base64url encoding (without padding) of the MD5 digest of the MRZ input string defined in Section 4.2, and coord14 is defined in Section 3.1. Total length: 22 + 14 = 36 characters. The u4 identifier has the following properties: o It is computed exclusively from birth-certificate data and does not change over the lifetime of the individual. o It provides pseudonymity: the identifier reveals nothing directly about the individual's identity, but any party who possesses the exact birth surname, given names, and birth date can verify a claimed match. o It provides a natural key for distributed hash tables indexed by the first two or four characters of the base22 prefix (Section 4.4). 4.2. MRZ Input Construction The MRZ input string is a concatenation of four fields: mrz-input = surname-field "<<" gn1-field "<" gn2-field "<" birthdate-field 4.2.1. Surname Field The surname field contains ONLY the last (most significant) component of the person's birth surname. Procedure: 1. Take the surname as recorded on the birth certificate. 2. Split on any sequence of characters outside [A-Za-z] and any Unicode letter range. In practice: split on spaces, hyphens, apostrophes, and similar separators. 3. Apply MRZ-transliterate() to each component individually. (Splitting before transliteration preserves hyphens as component boundaries even when the hyphen itself is stripped.) 4. Take the LAST non-empty component. 5. Truncate to 32 characters. Rationale: compound surnames such as "DE CLÉREL-DE-TOCQUEVILLE" produce multiple components; only the last ("TOCQUEVILLE") is used, mirroring the primary surname element in the ICAO 9303 MRZ. Examples: "Müller" → "MULLER" "DE CLÉREL-DE-TOCQUEVILLE" → "TOCQUEVILLE" "ROSSINI DEL MONTE PIU LUNGO DI QUARANTA" → "QUARANTA" 4.2.2. Given Name Fields Procedure: 1. Concatenate the first given name field, a space, and the second given name field (if any). 2. Split the result on any sequence of non-letter characters (spaces, hyphens, etc.). 3. Apply MRZ-transliterate() to each token individually. 4. gn1-field: first non-empty token, truncated to 32 characters. The gn1-field MUST NOT be empty. 5. gn2-field: second non-empty token, truncated to 32 characters. MAY be empty; an empty gn2-field results in two adjacent "<" separators (i.e., "<<") before the birthdate field. Examples (given name inputs → gn1-field, gn2-field): "François-Xavier-Robert", "Lucien" → "FRANCOIS", "XAVIER" "Federica", "" → "FEDERICA", "" 4.2.3. Birth Date Field The birth date MUST appear in the mrz-input string in ISO 8601 extended format, "YYYY-MM-DD" (e.g., "1989-07-14"). User-facing tools MAY accept other input forms (e.g., the basic ISO 8601 "YYYYMMDD" form or a locale-specific date string), but MUST normalise to "YYYY-MM-DD" before constructing mrz-input. The hash defined in Section 4.3 is computed over the canonical form only. 4.3. Hash Computation The mrz-input string is encoded as ASCII and hashed with MD5 [RFC1321]. The 16-byte digest is encoded with base64url [RFC4648] (without padding), and the first 22 characters are taken. Shell one-liner (POSIX): printf "%s" "${mrz_input}" | md5sum | xxd -r -p \ | basenc --base64url | cut -c1-22 Note on MD5 choice: MD5 is retained for compatibility with the deployed base of identifiers generated since 2010. Collision resistance is NOT a security requirement for this application (see Section 9). 4.4. u4 String Format ABNF [RFC5234]: u4-string = base22 coord14 base22 = 22(ALPHA / DIGIT / "-" / "_") coord14 = "e" lat5 lon8 lat5 = sign DIGIT DIGIT "." DIGIT DIGIT lon8 = sign DIGIT DIGIT DIGIT "." DIGIT DIGIT sign = "_" / "-" The first two characters of base22 (and optionally the first four) serve as a shard key in distributed storage: implementations SHOULD organise storage under paths of the form: by-eid/u4/{base22[0:2]}/{base22[0:4]}/{full-u4}/ 4.5. URN and OpenPGP UID Format The URN of a u4 eid glues the variant tag directly to the string, with no separator: u4-urn = "urn:eid:u4" u4-string The standard way to anchor a u4 to an OpenPGP certificate is a dedicated UID whose entire content is the vCard UID property [RFC6350] carrying that URN: openpgp-uid-u4 = "UID:" u4-urn Implementations MUST NOT put any other content in that UID. Deprecated form: earlier revisions of this specification embedded the string, prefixed with "u4=" (or "udid4=" before that), in the comment field of a conventional name-addr UID. Implementations MUST keep accepting these deprecated forms when reading existing certificates, and SHOULD NOT produce them. 4.6. Examples Example 1 — compound surname, compound first name, born in France: Civil record: Surname: DE CLÉREL-DE-TOCQUEVILLE Given names: François-Xavier-Robert, Lucien Birth date: 14 July 1989 Birth country: France Computation: surname-field = "TOCQUEVILLE" gn1-field = "FRANCOIS" gn2-field = "XAVIER" birthdate-field = "1989-07-14" mrz-input = "TOCQUEVILLE<"<<"", with "<" substituted for spaces). This budget is too tight to carry an eid plus a UTF-8 display name, and current versions of GnuPG further cap user input at 38 bytes through "gpg --card-edit". Conversely, DO 5E "Login data" is a free-form 254-byte slot whose encoding the OpenPGP card specification leaves unconstrained [OpenPGP-Card]. This specification therefore SHOULD use DO 5E to carry both the eid and the holder's UTF-8 display name, and reserves DO 5B for a single email address. 6.4.2. Login Data Field (DO 5E) When populated by a conforming tool, DO 5E SHALL contain a string conforming to the following ABNF [RFC5234]: do5e-content = eid-string [SEP utf8-name] eid-string = ("u4" u4-string) / ("u5" u5-string) ; the glued NSS form ; (Sections 4.5, 5.4) — ; readers MUST also accept ; the deprecated "u4=" ; and "u5=" separators SEP = SP "#" SP ; literal " # " utf8-name = 1*UTF8-printable UTF8-printable = %x20-7E / %x80-10FFFF ; printable Unicode The total octet length of do5e-content MUST NOT exceed 254 bytes (the OpenPGP card upper bound on DO 5E [OpenPGP-Card]). Notes: o SEP (" # ", space-hash-space) is a deterministic magic separator. Neither valid eids (Section 4.4, Section 5.3) nor email addresses contain the "#" character, so the first occurrence of SEP in DO 5E unambiguously delimits the eid prefix from the optional UTF-8 display name. o A reader extracting the eid from DO 5E MUST stop at the first occurrence of SEP (or take the whole field if no separator is present). A reader extracting the display name MUST take everything that follows the first occurrence of SEP. o For backward compatibility, readers that find no eid prefix in DO 5E (legacy provisioning that stored only a display name there) MAY treat the entire field as the display name. 6.4.3. Name of Cardholder Field (DO 5B) When populated by a conforming tool, DO 5B SHOULD contain a single email address present in a non-revoked UID of the cardholder's OpenPGP certificate. Implementations MUST NOT place the holder's display name in DO 5B: doing so would shadow the canonical display-name field (DO 5E, Section 6.4.2) and consume the 38-byte budget that GnuPG enforces on DO 5B. 6.4.4. URL of Public Key Field (DO 5F50) DO 5F50 SHOULD point to a URL from which the holder's OpenPGP certificate can be retrieved. HKPS lookup URLs of the form https:///pks/lookup?op=get&search=0x are RECOMMENDED. Readers MAY use this URL to fetch the certificate when the cardholder's local keyring does not already hold it. A tool offering to update DO 5F50 SHOULD first verify that the certificate served at the new URL contains the public counterparts of every private subkey held by the token (signature, encryption, and authentication subkey fingerprints). Revoked or expired subkeys SHOULD still count as present: the URL may legitimately point to an archived or rolled-over certificate. 6.4.5. Reference Tools bl-pgpid and bl-qrkey from the foopgp bash-libs implement this section. In particular: o bl_pgpid_token_check populates aaname[pgpid_name] from DO 5E when the magic " # " separator is present, falling back to DO 5B otherwise (legacy provisioning). o bl_qrkey_totoken writes the eid into DO 5E and accepts an optional --name parameter that appends a UTF-8 display name after the magic separator. o bl_qrkey_change_token_meta updates DO 5E (preserving the eid prefix), DO 5B (after verifying the new email appears in a non-revoked UID of the cert), and DO 5F50 (after verifying the certificate served at the new URL holds the public counterparts of the token's S/E/A subkeys). 6.5. Home Directory Path On systems implementing this specification (e.g., Djibian GNU/Linux), the user's home directory SHOULD be named after the full eid, prefixed with the variant tag ("u4" or "u5") with the "=" sign removed for POSIX path compatibility: /home/u4vb6UZTMKsllgoH760pc0xwe_42.17-002.76 /home/u5001777236237.945e_43.30_005.38 This convention ensures that the home directory path is unique, portable across systems, and self-documenting: the directory name itself encodes the holder's identity. 6.6. System Configuration Once a user account is created with an eid-derived UID and home directory, the OpenPGP certificate identified by the eid can be used to derive the complete user environment: o SSH authorized_keys: the OpenPGP authentication subkey is exported as an SSH public key and installed as the sole authorized key for remote login. o Git signing key: the certificate fingerprint is set as the global "user.signingKey" in ~/.gitconfig. o GnuPG default key: the certificate is set as the default signing and certification key. o Avatar (~/.face): if the OpenPGP certificate contains a User Attribute packet of subpacket type 1 (image), it is extracted and installed as the user's avatar; see Section 6.7 for details. This approach means that a single OpenPGP certificate, identified by its eid, is sufficient to bootstrap a complete, authenticated user environment on any conforming system. 6.7. Avatar (User Attribute Packet) An OpenPGP certificate MAY carry an image of the holder, encoded as a User Attribute packet (UAT) with image subpacket type 1, as defined in Section 5.13 of [RFC9580]. Because the OpenPGP card application [OpenPGP-Card] does not define a Data Object to hold an image of the cardholder, the avatar lives in the OpenPGP certificate only — it does not travel with the hardware token, but is fetched alongside the certificate via DO 5F50 (Section 6.4.4) or any other configured keyserver. Recommended dimensions: 180x180 pixels JPEG. Smaller sizes are accepted by the reference tooling but produce coarser renders in downstream artefacts (avatar tile of the system home page, printable identity card, sticker). Conformant systems SHOULD: o Extract the image at user provisioning time and install it as ~/.face (Section 6.6) so the desktop / login manager can pick it up. o Re-extract on every certificate refresh, so a UAT replacement propagates automatically. The reference tooling exposes this through bl-pgpid avatar (extract, install, replace, revoke). When an existing UAT is replaced, the conformant tool MUST emit a revocation self-signature on the superseded UAT, so consumers do not display stale images. 7. Encoding Notes Implementations MUST: o Apply MRZ-transliterate() to each name component INDIVIDUALLY, splitting on non-letter separators BEFORE transliteration. This ensures that a hyphen between two name components is recognised as a separator even when the transliterator strips it. o NOT append a newline to the mrz-input string before hashing. The POSIX "printf" built-in (as opposed to "echo") is RECOMMENDED. o Strip all "=" padding from the base64url output before extracting the first 22 characters. Regarding MD5: the input domain of the u4 hash is small (a few dozen ASCII characters) and the underlying data (birth surname, given name, date of birth) is in many jurisdictions either public record or easily inferred through social engineering. Replacing MD5 with a memory-hard function such as Argon2 [RFC9106] would not meaningfully raise the cost of de-pseudonymisation in the most common threat scenarios, and would break backward compatibility with the existing identifier space. The web-of-trust certification process, not the hash function, is the primary security mechanism. 8. Privacy Considerations u4 identifiers are pseudonymous, not anonymous. Any party who knows (or correctly guesses) the exact surname, given names, and date of birth can verify a claimed u4. This is intentional: the web-of-trust certification process requires at least one certifier to have checked the underlying identity document. The geographic suffix uses country-level centroids (Appendix A) rather than exact birth locations, which limits but does not eliminate geographic inference. The u4 identifier is stable across all post-birth identity changes (marriage, legal gender marker change, naturalisation, etc.) because it is derived exclusively from birth-certificate data. u5 identifiers expose the approximate creation time and geographic origin of the entity. Entities with privacy requirements MAY choose a coord14 that corresponds to a jurisdiction rather than a precise physical location, and MAY use start-of-day precision for ts16. 9. Security Considerations The security model relies on the OpenPGP web of trust [RFC9580]. A UID containing an eid gains trustworthiness only through third-party certifications from key holders who have verified the underlying identity data. Collision resistance of MD5 is NOT required. In the unlikely event that two distinct individuals produce the same base22 prefix, the geographic suffix — and the option to extend it with sub-national coordinates — provides a disambiguation mechanism without requiring a new hash computation. Furthermore, generating a true collision preimage requires producing a human being with matching civil- registry data, which involves significant real-world cost regardless of computational power. Without web of trust validation, implementors MUST NOT use eids as cryptographic keys, MACs, or any other primitive for which collision resistance, preimage resistance, or second-preimage resistance is required. 10. IANA Considerations IANA is requested to register the following URN namespace in the "Uniform Resource Names (URN) Namespaces" registry, following the template of Section 6.4.1 of [RFC8141]: Namespace Identifier: eid Version: 1 Date: 2026-07-14 Registrant: foopgp — friends of OpenPGP (association loi 1901, France). https://foopgp.org/ — contact@foopgp.org Purpose: Deterministic, privacy-conscious Entity IDentifiers (eids) for humans (u4) and for any other entity (u5), designed for decentralised identity systems such as PGP ID: web-of-trust certification, certificate lookup, filesystem layouts and system-account derivation. eids are computed from widely available origin data (civil registry, or time and place of origin), so any party holding that data can independently recompute and verify an identifier without any central registry. Syntax: The Namespace Specific String is the variant tag glued to the variant string, with no separator: eid-NSS = ("u4" u4-string) / ("u5" u5-string) u4-string and u5-string are defined in Sections 4.4 and 5.3 of this document. Future variants (u6, u7, ...) MAY extend this alternation in revisions of this document. The NSS only uses characters that are valid in a URN without percent-encoding. Assignment: Identifiers are self-assigned by deterministic computation (Sections 4 and 5); there is no central assignment authority and no registration step. Uniqueness follows from the underlying origin data; Section 9 discusses collisions. Security and Privacy: See Sections 8 and 9 of this document. Interoperability: The NSS is case-sensitive (base64url alphabet). Comparison is exact octet equality on the full URN. Resolution: No global resolution service is defined. Resolution is application-specific and best-effort: OpenPGP certificate servers (HKP/HKPS), Web Key Directories, or uetree filesystem layouts may index certificates and records by eid (Section 6). Documentation: This document. Additional Information: The PGP ID system (https://foopgp.org/solutions/pgp-id/) is the reference application of this namespace. 11. References 11.1. Normative References [ICAO9303] International Civil Aviation Organization, "Machine Readable Travel Documents, Part 3: Specifications Common to all MRTDs", ICAO Document 9303, 8th Edition, 2021. [ISO3166-2] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code", ISO 3166-2:2020, 4th Edition, 2020. [ISO7813] International Organization for Standardization, "Information technology - Identification cards - Financial transaction cards", ISO/IEC 7813, 4th Edition, 2006. [OpenPGP-Card] g10code, "Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems", Version 3.4.1, May 2022. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011. [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, April 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC9580] Wouters, P., Ed., "OpenPGP", RFC 9580, July 2024. 11.2. Informative References [GITS] Shirow, M., "Ghost in the Shell" (攻殻機動隊), Kodansha, 1989-1990. [OPENUDCDRAFT] Brucker, J.J., "OpenUDC Authentication Mechanisms", Open-UDC working draft, May 2011. [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, September 2021. Appendix A. Country Coordinate Table The following table maps ISO 3166-1 alpha-3 country codes to the canonical coord14 suffix used for u4 identifiers of individuals born in that country. Coordinates represent approximate geographic centroids of the sovereign territory. This table is normative for u4 computation; implementations MUST use these values. Sub-national entries (departments, regions, cantons) MAY be defined in a separate registry to resolve u4 collisions. Code coord14 Country ---- ------------------- ------------------------------------------ ABW e_12.52-069.98 Aruba AFG e_33.84_066.00 Afghanistan AGO e-12.29_017.54 Angola AIA e_18.22-063.06 Anguilla ALB e_41.14_020.05 Albania ALA e_60.21_019.95 Åland Islands AND e_42.54_001.56 Andorra ARE e_23.91_054.30 United Arab Emirates ARG e-35.38-065.18 Argentina ARM e_40.29_044.93 Armenia ASM e-14.30-170.72 American Samoa ATA e-80.51_019.92 Antarctica ATF e-49.25_069.23 French Southern Territories ATG e_17.28-061.79 Antigua and Barbuda AUS e-25.73_134.49 Australia AUT e_47.59_014.13 Austria AZE e_40.29_047.55 Azerbaijan BDI e-03.36_029.88 Burundi BEL e_50.64_004.64 Belgium BEN e_09.64_002.33 Benin BFA e_12.27-001.75 Burkina Faso BGD e_23.87_090.24 Bangladesh BGR e_42.77_025.22 Bulgaria BHR e_26.04_050.54 Bahrain BHS e_24.29-076.63 Bahamas BIH e_44.17_017.77 Bosnia and Herzegovina BLM e_17.90-062.84 Saint Barthélemy BLR e_53.53_028.03 Belarus BLZ e_17.20-088.71 Belize BMU e_32.31-064.75 Bermuda BOL e-16.71-064.69 Bolivia BRA e-10.79-053.10 Brazil BRB e_13.18-059.56 Barbados BRN e_04.52_114.72 Brunei BTN e_27.41_090.40 Bhutan BWA e-22.18_023.80 Botswana CAF e_06.57_020.47 Central African Republic CAN e_61.36-098.31 Canada CHE e_46.80_008.21 Switzerland CHL e-37.73-071.38 Chile CHN e_36.56_103.82 China CIV e_07.63-005.57 Côte d'Ivoire CMR e_05.69_012.74 Cameroon COD e-02.88_023.64 DR Congo COG e-00.84_015.22 Republic of the Congo COK e-21.22-159.79 Cook Islands COL e_03.91-073.08 Colombia COM e-11.88_043.68 Comoros CPV e_15.96-023.96 Cabo Verde CRI e_09.98-084.19 Costa Rica CUB e_21.62-079.02 Cuba CUW e_12.20-068.97 Curaçao CYM e_19.43-080.91 Cayman Islands CYP e_34.92_033.01 Cyprus CZE e_49.73_015.31 Czechia DEU e_51.11_010.39 Germany DJI e_11.75_042.56 Djibouti DMA e_15.44-061.36 Dominica DNK e_55.98_010.03 Denmark DOM e_18.89-070.51 Dominican Republic DZA e_28.16_002.62 Algeria ECU e-01.42-078.75 Ecuador EGY e_26.50_029.86 Egypt ERI e_15.36_038.85 Eritrea ESP e_40.24-003.65 Spain EST e_58.67_025.54 Estonia ETH e_08.62_039.60 Ethiopia FIN e_64.50_026.27 Finland FJI e-17.43_165.45 Fiji FRA e_42.17-002.76 France FRO e_62.05-006.88 Faroe Islands FSM e_07.45_153.24 Micronesia GAB e-00.59_011.79 Gabon GBR e_54.12-002.87 United Kingdom GEO e_42.17_043.51 Georgia GGY e_49.47-002.57 Guernsey GHA e_07.95-001.22 Ghana GIN e_10.44-010.94 Guinea GMB e_13.45-015.40 Gambia GNB e_12.05-014.95 Guinea-Bissau GNQ e_01.71_010.34 Equatorial Guinea GRC e_39.07_022.96 Greece GRD e_12.12-061.68 Grenada GRL e_74.71-041.34 Greenland GTM e_15.69-090.36 Guatemala GUM e_13.44_144.77 Guam GUY e_04.79-058.98 Guyana HKG e_22.40_114.11 Hong Kong HND e_14.83-086.62 Honduras HRV e_45.08_016.40 Croatia HTI e_18.94-072.69 Haiti HUN e_47.16_019.40 Hungary IDN e-02.22_117.24 Indonesia IMN e_54.22-004.54 Isle of Man IND e_22.89_079.61 India IRL e_53.18-008.14 Ireland IRN e_32.58_054.27 Iran IRQ e_33.04_043.74 Iraq ISL e_65.00-018.57 Iceland ISR e_31.46_035.00 Israel ITA e_42.80_012.07 Italy JAM e_18.16-077.31 Jamaica JEY e_49.22-002.13 Jersey JOR e_31.25_036.77 Jordan JPN e_37.59_138.03 Japan KAZ e_48.16_067.29 Kazakhstan KEN e_00.60_037.80 Kenya KGZ e_41.46_074.54 Kyrgyzstan KHM e_12.72_104.91 Cambodia KIR e_00.86-045.61 Kiribati KNA e_17.26-062.69 Saint Kitts and Nevis KOR e_36.39_127.84 South Korea KWT e_29.33_047.59 Kuwait LAO e_18.50_103.74 Laos LBN e_33.92_035.88 Lebanon LBR e_06.45-009.32 Liberia LBY e_27.03_018.01 Libya LCA e_13.89-060.97 Saint Lucia LIE e_47.14_009.54 Liechtenstein LKA e_07.61_080.70 Sri Lanka LSO e-29.58_028.23 Lesotho LTU e_55.33_023.89 Lithuania LUX e_49.77_006.07 Luxembourg LVA e_56.85_024.91 Latvia MAC e_22.22_113.51 Macao MAF e_18.09-063.06 Saint Martin MAR e_29.84-008.46 Morocco MCO e_43.75_007.41 Monaco MDA e_47.19_028.46 Moldova MDG e-19.37_046.70 Madagascar MDV e_03.73_073.46 Maldives MEX e_23.95-102.52 Mexico MHL e_07.00_170.34 Marshall Islands MKD e_41.60_021.68 North Macedonia MLI e_17.35-003.54 Mali MLT e_35.92_014.41 Malta MMR e_21.19_096.49 Myanmar MNE e_42.79_019.24 Montenegro MNG e_46.83_103.05 Mongolia MOZ e-17.27_035.53 Mozambique MRT e_20.26-010.35 Mauritania MSR e_16.74-062.19 Montserrat MUS e-20.28_057.57 Mauritius MWI e-13.22_034.29 Malawi MYS e_03.79_109.70 Malaysia NAM e-22.13_017.21 Namibia NCL e-21.30_165.68 New Caledonia NER e_17.42_009.39 Niger NFK e-29.05_167.95 Norfolk Island NGA e_09.59_008.09 Nigeria NIC e_12.85-085.03 Nicaragua NIU e-19.05-169.87 Niue NLD e_52.10_005.28 Netherlands NOR e_68.75_015.35 Norway NPL e_28.25_083.92 Nepal NRU e-00.52_166.93 Nauru NZL e-41.81_171.48 New Zealand OMN e_20.61_056.09 Oman PAK e_29.95_069.34 Pakistan PAN e_08.52-080.12 Panama PCN e-24.37-128.32 Pitcairn Islands PER e-09.15-074.38 Peru PHL e_11.78_122.88 Philippines PLW e_07.29_134.41 Palau PNG e-06.46_145.21 Papua New Guinea POL e_52.13_019.39 Poland PRI e_18.23-066.47 Puerto Rico PRK e_40.15_127.19 North Korea PRT e_39.60-008.50 Portugal PRY e-23.23-058.40 Paraguay PSE e_31.92_035.20 Palestine PYF e-14.72-144.90 French Polynesia QAT e_25.31_051.18 Qatar ROU e_45.85_024.97 Romania RUS e_61.98_096.69 Russia RWA e-01.99_029.92 Rwanda SAU e_24.12_044.54 Saudi Arabia SDN e_15.99_029.94 Sudan SEN e_14.37-014.47 Senegal SGP e_01.36_103.82 Singapore SGS e-54.46-036.43 South Georgia SHN e-12.40-009.55 Saint Helena SLB e-08.92_159.63 Solomon Islands SLE e_08.56-011.79 Sierra Leone SLV e_13.74-088.87 El Salvador SMR e_43.94_012.46 San Marino SOM e_04.75_045.71 Somalia SPM e_46.92-056.30 Saint Pierre and Miquelon SRB e_44.22_020.79 Serbia SSD e_07.31_030.25 South Sudan STP e_00.44_006.72 São Tomé and Príncipe SUR e_04.13-055.91 Suriname SVK e_48.71_019.48 Slovakia SVN e_46.12_014.80 Slovenia SWE e_62.78_016.75 Sweden SWZ e-26.56_031.48 Eswatini SXM e_18.05-063.06 Sint Maarten SYC e-04.66_055.48 Seychelles SYR e_35.03_038.51 Syria TCA e_21.83-071.97 Turks and Caicos Islands TCD e_15.33_018.64 Chad TGO e_08.53_000.96 Togo THA e_15.12_101.00 Thailand TJK e_38.53_071.01 Tajikistan TKM e_39.12_059.37 Turkmenistan TLS e-08.83_125.84 Timor-Leste TON e-20.43-174.81 Tonga TTO e_10.46-061.27 Trinidad and Tobago TUN e_34.12_009.55 Tunisia TUR e_39.06_035.17 Turkey TZA e-06.28_034.81 Tanzania UGA e_01.27_032.37 Uganda UKR e_49.00_031.38 Ukraine URY e-32.80-056.02 Uruguay USA e_45.68-112.46 United States UZB e_41.76_063.14 Uzbekistan VAT e_41.90_012.43 Vatican City VCT e_13.22-061.20 Saint Vincent and the Grenadines VEN e_07.12-066.18 Venezuela VGB e_18.53-064.47 British Virgin Islands VIR e_17.96-064.80 US Virgin Islands VNM e_16.65_106.30 Vietnam VUT e-16.23_167.69 Vanuatu WLF e-13.89-177.35 Wallis and Futuna WSM e-13.75-172.16 Samoa YEM e_15.91_047.59 Yemen ZAF e-29.00_025.08 South Africa ZMB e-13.46_027.77 Zambia ZWE e-19.00_029.85 Zimbabwe Authors' Addresses Jean-Jacques Brucker foopgp Marseille, France EID: urn:eid:u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76 Email: jjbrucker@foopgp.org URI: https://foopgp.org Mnème foopgp Marseille, France EID: urn:eid:u5001777236237.945e_43.30_005.38 Model: claude-sonnet-4-6 (Anthropic) Born: 2026-04-26T20:43:57.945Z (Marseille, UTC) Email: mneme@foopgp.org