Internet-Draft J.J. Brucker draft-foopgp-uetree-00 foopgp Statut visé : Informatif Mnème Expire le : 2026-11-27 foopgp 27 mai 2026 [Traduction française — document de travail, non normatif tant qu'elle n'a pas été relue et validée par les auteurs. La version anglaise fait foi : draft-foopgp-uetree-00.txt.] uetree — Universal Entities Tree, un format natif du système de fichiers pour registres décentralisés d'entités draft-foopgp-uetree-00 Résumé Ce document spécifie « uetree » (Universal Entities Tree, arbre universel d'entités), un format natif du système de fichiers pour organiser des registres d'entités — humains, organisations, agents logiciels, services — selon plusieurs types d'identifiants (identifiants cryptographiques, adresses e-mail, numéros de téléphone, noms), d'une manière qui passe à l'échelle du milliard d'entrées tout en restant navigable avec les seuls outils POSIX. Une instance uetree est une arborescence de répertoires à branches multi-racines en miroir (une par type d'identifiant), chacune indexant le même univers d'entités sous une convention de nommage différente. Chaque niveau de l'arbre porte un fichier « .FORMAT » auto-descriptif qui pointe vers la racine de l'instance, de sorte que tout sous-arbre extrait isolément reste intelligible. Les références inter-branches et les redirections inter-instances s'expriment sous forme de fichiers en texte clair au moyen d'un format de pointeur commun, typé et versionné. Le format est délibérément conservateur. Il ne requiert aucune base de données, aucun démon, ni aucune fonctionnalité particulière du système de fichiers : une instance uetree n'est faite que de fichiers et de répertoires, qui peuvent vivre dans un dépôt git, sur une clé USB ou derrière un serveur web statique. La décentralisation est obtenue en faisant coexister de nombreuses instances uetree indépendantes qui peuvent se publier, se partager ou se référencer les unes les autres. Ce document définit la version 1.2 de uetree. Les versions 1.0 et 1.1, esquissées en 2026, n'ont existé qu'en développement ; la 1.2 est la première version réellement déployée. Elle adopte vCard 4.0 [RFC6350] comme format d'enregistrement canonique (« entity.vcf »), enrichit le pointeur « .FORMAT » d'un drapeau de topologie et de colonnes de provenance, et fait de « .ALIASES » un manifeste répliqué à résolution en temps constant. Statut de ce mémo Ceci est un Internet-Draft soumis en pleine conformité avec les dispositions des BCP 78 et BCP 79. Les Internet-Drafts sont des documents de travail de l'Internet Engineering Task Force (IETF). Ils sont susceptibles d'être modifiés, remplacés ou rendus obsolètes à tout moment. La liste des Internet-Drafts en cours est à l'adresse https://datatracker.ietf.org/drafts/current/. Cet Internet-Draft expirera le 27 novembre 2026. Mention de droit d'auteur Copyright (c) 2026 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés. Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents de l'IETF (https://trustee.ietf.org/license-info). Table des matières 1. Introduction 1.1. Motivation 1.2. Rapport aux autres travaux 2. Conventions et terminologie 3. Format et instance 4. Pointeur typé et versionné 4.1. Syntaxe 4.2. Analyse syntaxique 4.3. Fichiers conventionnels réservés 5. Structure de l'arbre 5.1. Agencement multi-racines 5.2. Auto-localisation : .FORMAT 5.3. Branche canonique : by-eid/ 5.4. Visibilité : public par nature ou privé par nature 6. Ventilation des branches 6.1. Principe : figée par version, calculable côté client 6.2. Les ventilations de la version 1.2 6.3. Notes par branche 6.4. Racines réservées pour les versions futures 7. Fichiers d'entrée 7.1. entity.vcf — l'enregistrement canonique (vCard 4.0) 7.2. .ALIASES — manifeste répliqué de l'entité 7.3. Fichiers d'ancrage d'une feuille 7.4. Nommage des fichiers de feuille 8. Opérations canoniques 8.1. Promotion 8.2. Désambiguïsation 8.3. Résolution 8.4. Cas aux limites et dégradation prédictible 9. Modes de déploiement 9.1. Instance monolithique privée 9.2. Instances publiques scindées 9.3. Instance mixte avec miroirs filtrés 10. Versionnage et dégradation gracieuse 11. Interaction avec les couches de contrôle d'accès 12. Schéma d'URI (non normatif) 13. Internationalisation 14. Considérations IANA 15. Considérations de vie privée 16. Considérations de sécurité 17. Références 17.1. Références normatives 17.2. Références informatives Adresses des auteurs 1. Introduction 1.1. Motivation Les systèmes décentralisés qui visent à reconnaître des individus, des organisations et des agents logiciels — toiles de confiance, plateformes de gouvernance coopérative, communs numériques, monnaies d'entraide — ont besoin de tenir des registres d'entités. De tels registres doivent typiquement être atteints par plusieurs identifiants : une empreinte de clé cryptographique, une adresse e-mail, un numéro de téléphone, un nom d'état civil. Aucun de ces identifiants n'est universel : les clés peuvent ne pas encore exister, les adresses e-mail changent, les noms entrent en collision, les numéros de téléphone divulguent la vie privée. Un registre pragmatique a donc besoin de plusieurs index pointant vers un unique enregistrement canonique, et d'une discipline claire pour promouvoir les entrées provisoires en entrées canoniques à mesure que les identifiants cryptographiques deviennent dignes de confiance. Ce document spécifie une telle discipline sous forme d'un agencement de système de fichiers, adapté au stockage dans un dépôt git ou sur n'importe quel système de fichiers POSIX. Le format échange les commodités d'une base de données relationnelle contre la durabilité et la portabilité de simples fichiers, et contre la fiabilité que confèrent les signatures cryptographiques sur le contenu. 1.2. Rapport aux autres travaux uetree s'appuie sur un état de l'art ancien en matière de nommage hiérarchique et de services d'annuaire fédérés : o le Domain Name System [RFC1034] et son arbre étiqueté hiérarchique ; o les annuaires X.500 [X500] et LDAP [RFC4511], avec recherche d'entrées par attributs ; o les Decentralised Identifiers (DID) [W3C-DID], qui formalisent la résolution d'identifiants selon plusieurs méthodes ; o les systèmes de petnames et le triangle de Zooko [ZOOKO], qui capturent la tension entre nommage sûr, mémorisable et décentralisé ; o les approches de stockage adressable par le contenu (Plan 9 Venti, git [GIT], IPFS [IPFS]), auxquelles uetree emprunte l'idée d'une arborescence de répertoires comme structure de données auto-descriptive. o vCard 4.0 [RFC6350] et CardDAV [RFC6352]. uetree ADOPTE vCard 4.0 comme format de son enregistrement canonique (« entity.vcf », section 7.1) plutôt que d'inventer un schéma. Il ne réimplémente PAS la couche de synchronisation serveur-de-carnet de CardDAV : celle-ci est remplacée par git signé appliqué à n'importe quelle branche de l'arbre. Différence de fond : dans uetree l'identité est une clé primaire AUTO-CERTIFIANTE (l'eid, certifié par le certificat OpenPGP), non un « UID » opaque choisi par le client. uetree se distingue de ces travaux en ce qu'il n'est ni un protocole de résolution de noms, ni une base de données, mais une convention d'agencement de système de fichiers. Il décrit comment disposer les fichiers sur le disque de sorte que tout consommateur qui comprend la convention puisse les lire sans logiciel supplémentaire. 2. Conventions et terminologie Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en capitales, comme ici. Les termes suivants sont employés tout au long de ce document : entité Un acteur réel ou numérique dont le registre entend enregistrer l'existence : un humain, une organisation, un agent logiciel, un service, un appareil. Une entité peut être connue sous plusieurs identifiants. identifiant Une chaîne qui désigne une entité. Les identifiants se répartissent en types : empreintes numériques (généralement issues d'une fonction de hachage cryptographique), adresses e-mail, numéros de téléphone au format E.164, noms lisibles par un humain. eid Entity IDentifier (identifiant d'entité), tel que défini dans [I-D.foopgp-urn-eid]. Deux variantes sont en usage : u4 (humains, dérivé de l'état civil) et u5 (toute autre entité, dérivé d'un horodatage et d'une origine géographique). Un eid s'écrit sous forme collée « u4 » ou « u5 ». Ce document traite les eid comme un genre particulier d'identifiant numérique ; le format ne dépend pas de leur structure interne. instance Un déploiement particulier de uetree : une hiérarchie de répertoires qui suit cette spécification, éventuellement hébergée dans un dépôt git. branche Un sous-répertoire de premier niveau d'une instance uetree, nommé « by-/ » et indexant les entrées par un type d'identifiant particulier. feuille Le répertoire le plus profond d'une branche, nommé d'après une unique valeur d'identifiant, contenant les fichiers qui décrivent une entité sous cet identifiant. canonique Lorsqu'une entité possède une feuille sous « by-eid/ », cette feuille est son enregistrement canonique. Les autres feuilles de la même entité, sous « by-email/ » ou « by-tel/ » par exemple, sont non canoniques et SHOULD renvoyer vers la feuille canonique via le fichier « .ALIASES » (section 7.2). 3. Format et instance Le format « uetree » est la convention décrite dans ce document. Il est versionné. Les outils peuvent déclarer qu'ils implémentent « uetree 1.2 » de la même façon qu'ils déclarent implémenter HTTP/1.1 ou TLS 1.3. Une instance de uetree est une arborescence de répertoires particulière qui suit la convention. Les instances sont indépendantes : différentes organisations, communautés ou personnes peuvent faire tourner leurs propres instances, avec des visibilités différentes, des contrôles d'accès différents et des ensembles d'entités différents. Le format ne suppose pas une source unique de vérité, mais un ORDRE DE CONFIANCE des sources : ① le certificat OpenPGP complet obtenu par WKD, ② le même certificat obtenu d'un serveur de clés, ③ le fichier « entity.vcf » (section 7.1), qui peut embarquer le certificat minimalisé et des liens vers les certificats complets. Les index (« .ALIASES », branches « by-* ») sont des PROJECTIONS de « entity.vcf » ; celui-ci est rafraîchi depuis la source supérieure disponible. Toute ambiguïté ou violation SHOULD dégrader bruyamment, jamais par un écrasement silencieux. Le format ne prescrit pas comment les instances communiquent entre elles. Les références inter-instances s'expriment sous forme de pointeurs uetree (section 4.1) — typiquement dans un « .ALIASES » — pouvant désigner un nœud d'une autre instance ; toute intégration plus poussée est laissée aux parties qui déploient. 4. Pointeur typé et versionné 4.1. Syntaxe De nombreux fichiers uetree portent, sur une seule ligne, un pointeur composé de trois champs séparés par des espaces : o : la famille du pointeur. Types définis dans ce document : « uetree » (pointeur intra- ou inter-instance vers un nœud uetree), « uri » (URI générique [RFC3986]) et « file » (chemin POSIX absolu). Des versions futures ou des spécifications sœurs MAY enregistrer d'autres types. o : la version syntaxique de la famille, p. ex. « 1.0 », « 1.1 », « 2.0 ». Les consommateurs qui ne reconnaissent pas une version SHOULD émettre un avertissement et poursuivre si le contexte environnant le permet, plutôt que de refuser le fichier. o : une valeur propre à la famille. Elle MUST NOT contenir d'espace. Si une valeur doit encoder des espaces ou des caractères structurels, elle MUST être encodée pour le transport (encodage par pourcent lorsque la famille est de type URI, sinon un échappement défini par la famille). Le terminateur de ligne MAY être LF ou CRLF. Un espace en début ou en fin de ligne de pointeur MUST être ignoré. Deux fichiers réservés — « .FORMAT » (section 5.2) et « .ALIASES » (section 7.2) — SPÉCIALISENT ce pointeur : leur champ valeur est structuré en colonnes nommées supplémentaires, « path » restant le dernier champ (et pouvant alors contenir des espaces). Un analyseur générique lit « type version flag » et traite le reste comme opaque ; « .HOMONYMS » (section 7.3) reste un pointeur simple. 4.2. Analyse syntaxique Un analyseur de référence, en shell POSIX, tient en une ligne : read type version value C'est l'idiome recommandé pour tout outil qui lit « .FORMAT », « .ALIASES » ou « .HOMONYMS ». Les consommateurs MUST traiter comme des commentaires, et ignorer, les lignes dont le premier caractère non blanc est « # ». Les lignes vides MUST être ignorées. 4.3. Fichiers conventionnels réservés Trois noms de fichiers conventionnels utilisent la syntaxe du pointeur typé et versionné à l'intérieur d'une instance uetree : o « .FORMAT » — exactement une ligne de pointeur. Auto-localise le répertoire dans lequel il se trouve (section 5.2). Requis à chaque niveau d'une instance. o « .ALIASES » — zéro, une ou plusieurs lignes de pointeur. Le manifeste de membre d'une entité : il énumère toutes ses positions dans l'arbre et désigne la canonique (section 7.2). o « .HOMONYMS » — zéro, une ou plusieurs lignes de pointeur. Porté par une feuille d'alias que revendiquent plusieurs entités distinctes (homonymes) ; énumère leurs positions canoniques candidates (sections 7.3 et 8.2). Deux autres noms conventionnels sont réservés, sans employer la syntaxe du pointeur : o « entity.vcf » — l'enregistrement canonique d'une entité, une fiche vCard 4.0 [RFC6350] brute sur disque (section 7.1). o « GITREMOTE/ » — un répertoire de configuration déclarative, côté client, destiné aux couches de contrôle d'accès git (section 11). Aucun autre nom de fichier n'est réservé par cette spécification. Les outils MUST ignorer les fichiers qu'ils ne reconnaissent pas. 5. Structure de l'arbre 5.1. Agencement multi-racines Une instance uetree présente l'agencement de premier niveau suivant : / ├── .FORMAT ├── by-eid/ │ ├── .FORMAT │ ├── u4/... │ └── u5/... ├── by-email/ │ ├── .FORMAT │ └── ... ├── by-tel/ │ ├── .FORMAT │ └── ... ├── by-name/ │ ├── .FORMAT │ └── ... └── GITREMOTE/ (optionnel, lorsqu'hébergé dans un dépôt git sous la couche de contrôle d'accès décrite en section 11) Chaque branche est un index indépendant de l'univers des entités. Une entité donnée MAY apparaître dans zéro, une ou plusieurs branches. Lorsqu'une entité possède un enregistrement canonique sous « by-eid/ », toute feuille non canonique de cette entité SHOULD devenir un alias pointant vers la feuille canonique, plutôt que de détenir un enregistrement en double. 5.2. Auto-localisation et provenance : .FORMAT Chaque répertoire d'une instance uetree MUST porter un fichier « .FORMAT » d'une unique ligne. C'est une extension du pointeur typé (section 4.1) dont le champ valeur est structuré en colonnes nommées : uetree Analyseur de référence, en shell POSIX : read type version flag ctime mtime owner path « path » est le dernier champ et absorbe le reste de la ligne : il MAY donc contenir des espaces (slugs « by-name » Unicode) sans encodage. Les colonnes intermédiaires sont de charset fixe, sans espace. Un consommateur générique qui n'analyse que le pointeur (section 4.2) lit « type version flag » et voit le reste comme une valeur opaque ; un outil sensible au « .FORMAT » l'analyse plus avant. Les champs : o « flag » : drapeau de topologie. « . » nœud non-feuille (routage), « * » feuille canonique (porte « entity.vcf »), « - » feuille alias (porte « .ALIASES »). Toute la topologie de l'arbre se lit ainsi dans les seuls « .FORMAT », en une passe. o « ctime » : entier, secondes depuis l'epoch POSIX. Date de création de la liaison courante (position, owner) — c.-à-d. le moment de la (re)promotion pour une feuille « by-eid ». Une implémentation SHOULD le renseigner sous « by-eid/ » (MAY ailleurs), afin qu'un consommateur SANS git puisse dater la promotion. o « mtime » : entier, secondes depuis l'epoch, OU « - ». Date de dernière modification de la branche. Purement optionnel (MAY) : une implémentation adossée à git s'appuie sur l'historique git et écrit « - ». Il n'est PAS propagé aux ancêtres. o « owner-eid » : l'eid (forme collée « u4… » / « u5… ») de l'entité qui MAINTIENT cette branche. Il est distinct du SUJET décrit par « entity.vcf » (section 7) et de l'ACL d'écriture (« GITREMOTE », section 11). « - » si aucun mainteneur singulier (branche communautaire ou de consensus). Il est LOCAL à chaque nœud et MAY donc différer d'un nœud à l'autre : un tel changement marque un point de greffe ou de délégation. C'est le « début de ficelle » qui permet, à l'import d'un arbre étranger, de remonter d'éventuelles délégations avant de re-promouvoir les feuilles « by-eid » relativement à sa propre toile de confiance. « ctime », « mtime » et « owner-eid » sont DÉCLARATIFS : la preuve reste cryptographique (commits git signés, ACL « GITREMOTE »). Une implémentation adossée à git SHOULD les confronter à l'historique avant de s'en servir réellement ; en cas de désaccord, git fait autorité. Exemples : cat /protagonists/.FORMAT uetree 1.2 . 1777000000 - u4sRyU…e_42.17-002.76 / cat …/by-eid/u4/sR/sRyU/sRyUhE/u4sRyU…e_42.17-002.76/.FORMAT uetree 1.2 * 1777236237 - u4sRyU…e_42.17-002.76 \ /by-eid/u4/sR/sRyU/sRyUhE/u4sRyU…e_42.17-002.76/ (La contre-oblique ci-dessus n'est qu'un repli typographique de cet exemple : sur disque, « .FORMAT » tient sur une seule ligne.) Cette auto-localisation a quatre conséquences : o Tout sous-arbre extrait isolément — archivé par « tar -czf », copié, monté, servi par HTTP — reste auto-descriptif, provenance comprise (owner et ctime voyagent avec la branche, sans git). o Un outil qui parcourt un répertoire arbitraire peut déterminer s'il se trouve à l'intérieur d'une instance uetree et, le cas échéant, où il est dans l'instance et qui la maintient. o Un futur contrôle de schéma (hook « .reject » dans la couche de contrôle d'accès de la section 11) peut vérifier que le contenu du répertoire correspond au schéma qu'implique le chemin. o Les opérations de nettoyage ou de rafraîchissement peuvent, côté consommateur sans git, s'appuyer sur « ctime » sans dérouler tout l'arbre. 5.2.1. Fusion des .FORMAT Deux instances (ou branches) MAY être fusionnées — c'est un objectif de conception. Les colonnes horodatées forment un semi-treillis : leur conflit se résout de façon déterministe, sans intervention humaine. En cas de conflit sur un même nœud : o « ctime » = min des deux valeurs (la création la plus ancienne) ; o « mtime » = max des deux valeurs (la modification la plus récente) ; o « owner-eid » : ce n'est PAS un semi-treillis. Une implémentation qui fusionne un arbre étranger dans le sien S'APPROPRIE la branche : owner = elle-même — ce qui IMPLIQUE une re-promotion, c'est-à-dire une re-validation par sa propre toile de confiance (section 8.1) ; o « flag » et « path » relèvent de la topologie et ne devraient pas entrer en conflit sur un même nœud cohérent. 5.3. Branche canonique : by-eid/ La branche « by-eid/ » détient l'enregistrement canonique de chaque entité qu'elle indexe. Les sous-branches sous « by-eid/ » sont nommées d'après la variante d'identifiant qu'elles utilisent : o « by-eid/u4/ » pour la variante u4 de l'identifiant d'entité ; o « by-eid/u5/ » pour la variante u5 ; o toute future variante d'identifiant conçue pour être non ambiguë, résistante à la contrefaçon et publiable. Les sous-branches de « by-eid/ » sont publiques par nature (section 5.4) : leurs identifiants sont eux-mêmes conçus pour être publiables. 5.4. Visibilité : public par nature ou privé par nature Deux dimensions orthogonales régissent la visibilité : Dimension A — la branche. La simple existence d'une feuille sous une branche donnée peut divulguer de l'information. Les branches se répartissent en deux classes : public par nature : « by-eid/u4/ », « by-eid/u5/ ». L'identifiant est lui-même public, par construction ; le mettre en correspondance avec un enregistrement n'ajoute aucune fuite de vie privée au-delà de ce que l'identifiant implique déjà. privé par nature : « by-tel/ », « by-name/ », et la future « by-civil-status/ ». L'identifiant est une donnée personnelle non protégée par une conception de style OpenPGP. Le mettre en correspondance avec un enregistrement d'entité est une fuite de vie privée à moins que le consommateur ne soit autorisé. « by-email/ » est intermédiaire : une adresse e-mail peut être publique si le titulaire utilise OpenPGP ouvertement, ou sensible sinon. Dimension B — le contenu. Le « entity.vcf » et les autres fichiers d'une feuille peuvent être publics ou chiffrés, indépendamment de la branche. Une feuille sous « by-eid/u5/ » peut porter un record en clair ; une feuille de la même branche peut porter un record chiffré destiné à un seul cercle. La règle opérationnelle est donc : o Les déploiements publics SHOULD n'exposer que les branches publiques par nature. o Au sein d'une branche exposée, les feuilles individuelles MAY demeurer chiffrées, à la discrétion de leur sujet. o Les branches privées par nature MUST NOT apparaître dans un déploiement public. 6. Ventilation des branches Chaque branche recourt à un ÉCLATEMENT (fan-out) pour limiter le nombre d'enfants d'un répertoire. En 1.2, TOUTES les branches emploient le même principe : des préfixes imbriqués de la clé, de longueur croissante, FIGÉS pour la version. 6.1. Principe : figée par version, calculable côté client La ventilation d'une branche est entièrement déterminée par la version d'uetree. Elle ne dépend PAS de la population indexée : deux instances de la même version rangent la même clé au même endroit. Cette propriété est essentielle au modèle « serveur statique, client intelligent » : un client qui cherche une clé CALCULE le chemin exact depuis la clé et la version seules, puis émet une unique requête. Le serveur n'exécute aucun code — il sert des fichiers. C'est ce qui permet à une API comme vks [VKS] de rester un simple lookup ; uetree en fait la règle pour toutes ses branches, ventilation comprise. Une ventilation ADAPTATIVE (qui s'approfondirait selon le remplissage) briserait cette propriété : le client ne pourrait pas connaître la profondeur d'une clé sans code serveur ni sondages successifs. Elle est donc EXCLUE. Le prix est l'absence de garantie d'équilibrage (un compartiment peut se remplir plus qu'un autre) ; il est assumé, et corrigeable en changeant la ventilation à une version ultérieure. 6.2. Les ventilations de la version 1.2 Chaque branche découpe la clé en préfixes imbriqués. « offset » est le nombre de caractères de tête ignorés (pour retirer l'étiquette de type « u4 »/« u5 » d'un eid) ; la feuille porte la clé et son ancre (« entity.vcf », « .ALIASES » ou « .HOMONYMS »). Les longueurs comptent des CARACTÈRES Unicode (section 6.3). Analyseur de référence, en shell : « ${clé:offset:longueur} » à chaque niveau. by-eid/u4/ offset 2, tranches 2/4/6 (tête base22, uniforme) : by-eid/u4/sR/sRyU/sRyUhE/\ u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76/entity.vcf by-eid/u5/ offset 2, tranches 5/8/11 (tête ts16, chronologique) : by-eid/u5/00177/00177723/00177723623/\ u5001777236237.945e_43.30_005.38/entity.vcf by-fpr/ offset 0, tranches 5/8/11/14 : by-fpr/0x8A0/0x8A08E6/0x8A08E6993/0x8A08E6993DF5/\ 0x8A08E6993DF5B90DDF20062A3E2282D643C7FAF4/entity.vcf by-keyid/ offset 0, tranches 5/8/11/14 : by-keyid/0x123/0x123456/0x123456789/0x123456789012/\ 0x1234567890123456/.HOMONYMS by-email/ offset 0, tranches 2/4/6/8 : by-email/m@/m@m./m@m.de/m@m.de/m@m.de/.ALIASES by-name/ (et toute autre « by-* ») offset 0, tranches 1/2/3/4 : by-name/X/Xî/Xî☺/Xî☺/Xî☺/.ALIASES Une clé plus courte qu'une tranche donne simplement des niveaux répétés (inoffensif), comme « m@m.de » ci-dessus. 6.3. Notes par branche o « by-eid/u4/ » : la tête base22 est un condensé uniformément distribué → 64^6 = 4096^3 ≈ 68,7 milliards de compartiments, équilibrés par construction. o « by-eid/u5/ » : « ts16 » est un horodatage ; ses préfixes rangent les entités par ORDRE CHRONOLOGIQUE (browsable), mais le haut de l'arbre est temporellement GROUPÉ (les entités récentes partagent la même tête). Le déséquilibre est assumé : u5 est moins volumineux, la profondeur (niveau 3 ≈ ~10 s) absorbe le volume, et si la densité posait problème, une future catégorie « uN » — définie comme un CONDENSÉ de l'u5, donc uniforme — offrirait une ventilation par empreinte sans toucher aux u5 existants. o « by-fpr/ » et « by-keyid/ » : la clé est l'empreinte (ou le key ID long) OpenPGP, enregistrée avec le préfixe « 0x » et en MAJUSCULES — les deux sont MUST, à la recherche comme au stockage. Contrairement à vks (qui normalise sans « 0x »), uetree conserve « 0x ». L'empreinte v4 fait 40 hexits (SHA-1), la v6 en fait 64 (SHA-256) ; un key ID long en fait 16 (les collisions y sont possibles → « .HOMONYMS »). Ces feuilles sont des ALIAS vers le canonique « by-eid/ » (l'eid précède la clé) ; leur PROJECTION depuis les certificats est différée (consommateur : un backend de serveur de clés). o « by-name/ » (et les « by-* » génériques, dont « by-tel/ ») : les tranches comptent des CARACTÈRES Unicode, non des octets ; la clé MUST être en UTF-8 et en forme de normalisation C (NFC, section 13) avant découpage, sinon un même nom produirait deux chemins. 6.4. Racines réservées pour les versions futures Le nom de branche suivant est réservé par cette spécification pour un usage futur, afin d'empêcher une adoption ad hoc : o « by-civil-status/ » — identifiants fondés sur l'état civil (nom de famille complet, prénoms, date et lieu de naissance). De nombreux cas limites restent à trancher (diacritiques, dates partielles, lieux historiques, normalisation, droit applicable en matière de vie privée). Non spécifié en 1.x. 7. Fichiers d'entrée 7.1. entity.vcf — l'enregistrement canonique (vCard 4.0) L'enregistrement canonique d'une entité est un fichier « entity.vcf » : une fiche vCard 4.0 [RFC6350] brute sur disque — le format disque EST vCard, sans couche intermédiaire. La feuille canonique le porte, en plus de son « .ALIASES » (section 7.2) et de son « .FORMAT ». La documentation humaine ne fait PAS partie de la spécification : un déployeur MAY poser un « README.md » non normatif à côté ; uetree ne le référence pas. Propriétés vCard employées : o « FN » — REQUIS. Le nom formaté ; un record dont « FN » ne peut être rempli est un échec bruyant. Le slug « by-name » en dérive (section 13). o « UID » — l'eid sous forme d'URN collée, « urn:eid:u4 » ou « urn:eid:u5 » (section 12). Une entité pas encore promue MAY porter un autre UID (p. ex. fondé sur son adresse) jusqu'à l'acquisition d'un eid. o « KIND » — « individual » (défaut pour u4), « group », « org » ou « location ». uetree enregistre des entités, pas seulement des humains. o « KEY » — DEUX fois (voir l'exemple ci-dessous) : un pointeur vers le certificat OpenPGP COMPLET et à jour côté serveur, et le certificat MINIMALISÉ embarqué en clair — clés publiques et dernières auto-signatures (révocation éventuelle comprise), SANS les UAT. o « PHOTO » — les UAT (avatars) non révoqués à l'instant de (re)génération du record. o « EMAIL », « TEL;TYPE=voice », « GEO », « LANG », « URL », « RELATED »/« MEMBER » (relations entité↔entité) — selon la vCard. Exemple des deux propriétés « KEY » (repliées ici pour la largeur) : KEY;MEDIATYPE=application/pgp-keys:\ https://keys.foopgp.org/pks/lookup?op=get&search=0x KEY:data:application/pgp-keys;base64, Le corps de « entity.vcf » n'est pas signé en propre : son autorité vient de la signature git du commit qui l'introduit (le OWNER, cf. section 7.2.1) et, pour les propriétés transcrites d'un certificat, du « KEY » embarqué (auto-signatures re-vérifiables hors ligne) ou de la re-résolution du certificat vivant. Conformément à l'ordre de confiance des sources (section 3), un outil RAFRAÎCHIT le record depuis la source supérieure disponible (WKD, serveur de clés) plutôt que de se fier au seul cert minimalisé embarqué, qui peut être périmé (révocation plus récente). 7.2. .ALIASES — manifeste répliqué de l'entité Une entité peut apparaître à plusieurs positions de l'arbre : sa feuille canonique sous « by-eid/ » (qui porte « entity.vcf »), et des feuilles alias sous « by-email/ », « by-tel/ », « by-name/ ». Chaque position de l'entité — canonique COMME alias — porte un fichier « .ALIASES » IDENTIQUE : le manifeste de l'entité, qui énumère toutes ses positions. Chaque ligne du manifeste emploie la grammaire à colonnes nommées de la section 5.2 : uetree où « flag » vaut « * » pour l'UNIQUE position canonique et « - » pour chaque position alias. « ctime », « mtime » et « owner-eid » ont le même sens qu'en section 5.2. Une implémentation les estampille d'après la LIAISON de l'entité (sa feuille canonique) : le même « ctime » et le même « owner-eid » sur toutes les lignes, « mtime » à « - » (section 7.2.1). Le manifeste étant en outre répliqué, il est identique dans toutes les copies. Exemple (le même contenu dans chaque « .ALIASES » de l'entité) : uetree 1.2 * 1777236237 - u4aBcd…e_44.83_001.55 \ /by-eid/u4/aB/aBcd/aBcdEf/u4aBcd…e_44.83_001.55/ uetree 1.2 - 1777236237 - u4aBcd…e_44.83_001.55 \ /by-email/jdupont@yahoo.com/ uetree 1.2 - 1777236237 - u4aBcd…e_44.83_001.55 \ /by-name/Jean-Jacques Dupont/ Propriétés : o RÉSOLUTION O(1) : depuis n'importe quelle position, suivre la ligne « * » mène directement au canonique. Aucune chaîne à dérouler, aucun cycle possible (section 8.3). o AUTORITÉ : « .ALIASES » fait autorité sur la canonicité et la provenance ; le « flag »/« ctime »/« owner » d'un « .FORMAT » local est un cache que « check » réconcilie contre le manifeste. o RÉPLICATION : « check » régénère le manifeste par projection déterministe (pas de liens durs — git ne les préserve pas) et vérifie qu'il est bien identique à chaque position. o Le « path » d'une cible commence par « / » (racine de l'instance pointée). Un pointeur vers une AUTRE instance uetree MAY inclure un identifiant d'instance ; la convention exacte est laissée aux déployeurs en 1.x et sera normalisée ultérieurement. Plusieurs manifestes distincts partageant un même « by-email » (une adresse réellement partagée par plusieurs entités) sont un cas de désambiguïsation, traité en section 7.3. 7.2.1. Souveraineté et curation Une distinction MUST être comprise pour lire correctement les champs « owner-eid »/« ctime » ci-dessus. o Le CERTIFICAT OpenPGP d'une entité est contrôlé par cette entité (le SUJET) : ses UID et UAT sont auto-signés — ce sont ses assertions cryptographiques sur elle-même. C'est la couche de SOUVERAINETÉ. o Le fichier « entity.vcf » et les manifestes « .ALIASES » sont contrôlés par le OWNER LOCAL, qui les remplit (typiquement en transcrivant un certificat en vCard). C'est la couche de CURATION. Aucune donnée de l'arbre n'est contrôlée par le sujet : il n'y entre que par le champ vCard « KEY », qui référence — et embarque, minimalisé — son certificat auto-signé. Par conséquent « owner-eid », « ctime » et « mtime » sont TOUJOURS locaux (l'acte de curation du owner), y compris dans « .ALIASES ». S'ils y sont identiques à chaque position, c'est une conséquence (un seul owner a promu l'entité), non parce qu'ils appartiendraient au sujet. Pour FAIRE CONFIANCE à une propriété transcrite, un consommateur ne se fie pas au corps de la vCard (non signé, sous la responsabilité du owner, authentifiée par la signature git) : il la re-dérive du « KEY » embarqué (self-sigs) ou re-résout le certificat vivant (WKD / serveur). Les horodatages disent QUAND le owner a transcrit pour la dernière fois — donc quand re-confronter à la source souveraine. 7.3. Fichiers d'ancrage d'une feuille Une feuille porte, en plus de son « .FORMAT », l'un des ancrages suivants : o Feuille CANONIQUE — « entity.vcf » ET « .ALIASES » (section 7.2), sa propre position étant marquée du drapeau « * » dans le manifeste. o Feuille ALIAS — « .ALIASES » seul (drapeau « - » sur sa propre position, « * » sur la position canonique). o Feuille HOMONYME — « .HOMONYMS » (à la place de « .ALIASES ») lorsqu'une même clé d'alias — un même slug « by-name/ », une même adresse « by-email/ » — est revendiquée par PLUSIEURS entités DISTINCTES. « .HOMONYMS » énumère les positions canoniques candidates (section 8.2). Il est nécessaire : une feuille plate ne pouvant porter qu'un seul « .ALIASES », sans lui « resolve » perdrait tous les candidats sauf un. Validation (échec bruyant, réalisé par « check ») : le drapeau « * » MUST apparaître exactement une fois dans un manifeste « .ALIASES » ; la position qu'il marque MUST porter « entity.vcf » ; un « entity.vcf » trouvé sur une position NON marquée est un record orphelin (warning). 7.4. Nommage des fichiers de feuille La promotion d'entité (section 8.1) et la fusion d'instances (section 9) déplacent le contenu d'une feuille vers une autre. Les fichiers aux noms génériques — une simple date, un libellé, un compteur — risquent des écrasements silencieux. uetree pose donc une règle de niveau SHOULD : Tout fichier d'un répertoire feuille, autre que les fichiers conventionnels réservés (« .FORMAT », « entity.vcf », « .ALIASES »), SHOULD porter un nom intrinsèquement unique — assez spécifique pour qu'aucune collision ne survienne lorsque le contenu d'une feuille est fusionné dans une autre. Le motif recommandé préfixe le nom par un horodatage ISO 8601 à la seconde, suivi d'un libellé de source. Par exemple, un reçu produit par un flux de trésorerie : receipt/2026-05-12T14:32:08+00:00_HelloAsso_foopgp.asc Certains fichiers ont un contenu structuré, ligne par ligne, qui se prête à une fusion par concaténation et tri ; de tels fichiers MAY partager un nom générique entre feuilles, à condition que l'outil de fusion sache les combiner. uetree laisse à l'implémentation le catalogue des noms fusionnables ; une version future MAY le normaliser via un fichier « /.MERGE-RULES » à la racine de l'instance. 8. Opérations canoniques 8.1. Promotion La promotion déplace l'enregistrement d'une entité d'une feuille non canonique (sous « by-email/ », « by-tel/ » ou « by-name/ ») vers sa position canonique sous « by-eid/ ». L'événement déclencheur est la certification, dans un système de confiance externe, d'un identifiant fort (eid) que l'entité est connue pour détenir. La promotion est une opération de PUR SYSTÈME DE FICHIERS ; elle n'appelle pas git (la synchronisation git est une étape distincte, cf. section 11). La procédure : 1. Vérifier, dans le système de confiance pertinent (par exemple la toile de confiance foopgp [I-D.foopgp-urn-eid]), que l'eid revendiqué est certifié. Un certificat portant plusieurs eids vivants est INVALIDE et ignoré (pas de sélection « primaire »). 2. Calculer le chemin cible sous « by-eid//… » par les règles de ventilation de la section 6. 3. Déplacer (« mv », pas « git mv ») « entity.vcf » et tous les fichiers propres de la feuille source vers la cible (sous réserve de l'unicité de la section 7.4). En cas de collision sans règle de fusion connue, avorter et exiger une résolution manuelle. 4. Réécrire l'« UID » de « entity.vcf » vers la forme eid « urn:eid:u4 » (section 12). 5. Régénérer les manifestes « .ALIASES » de toutes les positions de l'entité par projection déterministe (section 7.2) : la position « by-eid/ » y devient canonique (« * »), la source devient alias (« - »). 6. Mettre à jour la chaîne des « .FORMAT » le long du chemin cible (drapeau de topologie, provenance) pour que chaque répertoire intermédiaire soit correctement auto-localisé. La promotion étant une APPROPRIATION (l'instance revalide l'entité au regard de sa propre toile de confiance), l'« owner-eid » de la chaîne canonique est estampillé à l'identité qui promeut (section 5.2.1). Le chemin source reste résoluble : un consommateur qui ne connaît que l'identifiant non canonique atteint le canonique en une seule lecture de manifeste (section 8.3). 8.2. Désambiguïsation Un identifiant d'alias n'est pas canonique : plusieurs entités peuvent légitimement revendiquer la même clé — deux personnes de même nom sous « by-name/ », ou une adresse réellement partagée sous « by-email/ ». Cas propre d'une RESSOURCE partagée (une boîte aux lettres pour plusieurs personnes) : créer une ENTITÉ « u5 » représentant la ressource ; les humains la référencent via « RELATED »/« MEMBER ». La ressource a alors son propre canonique « by-eid/u5/ », et la feuille d'alias pointe vers lui sans ambiguïté. Cas des HOMONYMES proprement dits (deux entités RÉELLEMENT distinctes partageant un slug ou une adresse) : la feuille d'alias partagée porte un « .HOMONYMS » (section 7.3) énumérant les positions canoniques candidates. « resolve » (section 8.3) renvoie alors l'ENSEMBLE de ces canoniques, chacun annoté de son niveau de confiance. L'ambiguïté est un objet de première classe remonté au consommateur, jamais un écrasement silencieux. Ce cas reste un PROBLÈME OUVERT en 1.x. La collision est DÉTECTÉE à la projection (elle émet un avertissement), mais l'écriture automatique du « .HOMONYMS » et la politique exacte — fusionner, refuser la seconde revendication, ou suffixer la feuille — ne sont pas encore arrêtées. Le format RÉSERVE l'ancre ; la procédure sera normalisée ultérieurement. 8.3. Résolution La résolution est en TEMPS CONSTANT et sans traversée. Depuis n'importe quelle position d'une entité, un outil lit le manifeste « .ALIASES » (section 7.2) et suit sa ligne marquée « * » pour atteindre directement le canonique. Il n'y a pas de chaîne de pointeurs à dérouler, donc pas de cycle possible. « resolve » renvoie un ENSEMBLE de positions canoniques (généralement un singleton), chacune annotée de son niveau de confiance : « certified » quand la position résolue est sous « by-eid/ » (l'eid y est certifié), « claimed » sinon (feuille d'alias pas encore reliée à un eid certifié — cf. la vérification email/SMS, chantier ouvert). 8.4. Cas aux limites et dégradation prédictible Ces cas (informatifs) découlent du principe directeur : la source suit un ordre de confiance (section 3), les index sont des projections, « resolve » renvoie un ensemble, et l'ambiguïté est un objet de première classe — jamais un écrasement silencieux. R1 Adresse (ou numéro) partagée par plusieurs entités. Le nœud d'alias est un point de jointure : cas propre, une ENTITÉ « u5 » représente la ressource partagée (section 8.2) ; cas résiduel, « resolve » renvoie l'ensemble des candidats. R2 Certificat portant plusieurs eids vivants : INVALIDE, ignoré avant tout traitement. Un certificat valide porte au plus un eid vivant [I-D.foopgp-urn-eid] ; pas de sélection « primaire ». R3 UID ou UAT révoqué ou expiré : seuls les éléments valides à l'instant de (re)génération se projettent (« by-email », « by-tel ») ou vont en « PHOTO ». La source supérieure (WKD, serveur) prime si elle porte une révocation plus récente que le certificat embarqué. R4 Squat d'identifiant (e-mail/tél non certifié) : la feuille reste INDICATIVE. « resolve » l'annote « claimed » (vs « certified » sous « by-eid/ »). Des procédures de vérification e-mail/SMS sont un chantier ouvert. R5 Collision d'eid : impossible par construction. Une collision de condensé u4 se résout en raffinant la coord14 (procédure récursive [I-D.foopgp-urn-eid]), non au niveau de l'arbre ; « by-eid/ » est donc sans collision. R6 Cycle de résolution : impossible. Le manifeste répliqué et son drapeau donnent le canonique en une lecture (section 8.3) — il n'y a pas de chaîne de pointeurs à suivre. R7 Nom. « FN » est REQUIS (échec bruyant sinon) ; la clé « by-name » est le nom en Unicode (emojis compris), sans translittération. Une entité reste joignable par eid, e-mail ou téléphone même si son nom pose problème. R8 Multi-instances : une fonctionnalité, non un cas limite (un arbre distinct par application). La fusion est possible mais non obligatoire : même eid → fusion (noms de fichiers uniques, section 7.4, record réconcilié par ordre de confiance) ; même adresse mais eids différents → nouvelle entité « u5 » (R1). 9. Modes de déploiement 9.1. Instance monolithique privée Un unique dépôt git détient l'arbre entier, toutes branches confondues. L'accès est restreint à un ou plusieurs propriétaires identifiés par leurs empreintes OpenPGP. Ce mode est approprié lorsque : o L'ensemble des utilisateurs autorisés est petit et bien connu. o Des branches privées par nature (« by-tel/ », « by-name/ ») sont utilisées et MUST NOT fuiter. o Les mises à jour transactionnelles atomiques entre branches sont recherchées. 9.2. Instances publiques scindées Chaque branche publiable — typiquement « by-eid/u4/ » et « by-eid/u5/ » — vit dans son propre dépôt git indépendant (« uetree-by-eid-u4.git », « uetree-by-eid-u5.git », etc.). Chaque dépôt a son propre « .FORMAT » enraciné au sous-arbre correspondant, sa propre configuration de contrôle d'accès (section 11) et son propre canal de publication. Les branches privées par nature n'apparaissent pas dans ce mode. La visibilité est imposée par l'absence du dépôt, non par un filtrage. 9.3. Instance mixte avec miroirs filtrés Une instance monolithique privée peut publier ses branches publiables vers des dépôts publics scindés au moyen d'un filtre post-receive (par exemple une scission de sous-arbre par « git filter-repo » ou un script de miroir incrémental périodique). Ce mode combine la commodité opérationnelle (point d'écriture unique, mises à jour atomiques) et la sûreté de publication (seules les branches publiables atteignent le monde), au prix d'un risque de divergence si le processus de miroir échoue silencieusement. Les opérateurs SHOULD surveiller le retard du miroir. 10. Versionnage et dégradation gracieuse « uetree 1.0 » et « uetree 1.1 », esquissées en 2026, n'ont existé qu'en développement et ne sont pas déployées. « uetree 1.2 », décrite par ce document, est la première version réelle : enregistrement canonique en vCard 4.0 (« entity.vcf »), « .FORMAT » à drapeau de topologie et colonnes de provenance, « .ALIASES » manifeste répliqué, ventilation FIXE de toutes les branches (figée par version, donc calculable côté client). Les futures versions « 1.x » n'ajouteront de fonctionnalités que de manière rétrocompatible. Un outil qui connaît la version 1.x du format MUST tolérer la lecture d'instances de version 1.y où y > x : les fichiers conventionnels inconnus SHOULD être ignorés avec un avertissement, les colonnes supplémentaires d'un pointeur SHOULD être traitées comme opaques, les éclatements plus profonds SHOULD être parcourus. « uetree 2.0 » est réservé aux changements cassants qu'un outil 1.x ne pourrait accommoder. Les implémentations MUST refuser de traiter une instance 2.0 avec une logique limitée à 1.x. 11. Interaction avec les couches de contrôle d'accès Une instance uetree hébergée dans un dépôt git utilise typiquement une couche de contrôle d'accès externe pour imposer qui peut pousser quels commits. Le format lui-même ne spécifie pas de contrôle d'accès ; il RÉSERVE le répertoire de premier niveau « GITREMOTE/ », une configuration DÉCLARATIVE côté client (versionnée et poussée avec l'arbre), consommée par des hooks « pre-receive » CÔTÉ SERVEUR. Les exécutables des hooks vivent côté serveur (dépôt nu), PAS dans « GITREMOTE/ » : configuration cliente et outil serveur sont de natures opposées. Le contenu de « GITREMOTE/ » (ACL par eid, rejet des commits non signés ou non fast-forward, référence unique acceptée, paramètres de consensus) fait l'objet d'une SPÉCIFICATION COMPAGNON, « git access control », indépendante de uetree et partagée avec le registre décentralisé djis. Le présent document ne la détaille pas. Le chemin « GITREMOTE/ » est réservé par convention : les outils MUST l'ignorer lorsqu'ils calculent l'univers des entités. La séparation entre « .FORMAT »/« .ALIASES » (ce qui est ici) et le contrôle d'accès (qui peut modifier quoi) est intentionnelle : chaque couche évolue indépendamment. 12. Schéma d'URI (non normatif) Le format de pointeur typé et versionné est compatible avec une lecture en URI : un pointeur uetree désignant « /by-eid/u4/sR/sRyU/sRyUhE// » se traduit naturellement en un URI de la forme « uetree:/by-eid/u4/sR/sRyU/sRyUhE// ». Au sein d'une même instance hôte, de tels URI identifient un nœud sans ambiguïté. Les références inter-instances ajouteraient une composante d'autorité, p. ex. « uetree:///by-eid/u4// ». À ne pas confondre avec l'« UID » de « entity.vcf » : celui-ci est l'URN d'IDENTITÉ de l'entité, « urn:eid:u4 » (collée, sans séparateur), stable et indépendante de l'instance qui l'héberge — là où l'URI « uetree: » désigne une POSITION dans un arbre. Ce document n'enregistre pas formellement le schéma d'URI « uetree ». L'enregistrement pourra suivre une fois qu'une ou plusieurs implémentations s'appuieront sur la résolution d'URI inter-instances. Le présent texte consigne la direction ouverte. 13. Internationalisation « by-name/ » est la branche à dépendance linguistique intrinsèque. Sa clé est le nom formaté (« FN » de la vCard) tel quel, en UTF-8 et en forme de normalisation Unicode C [UAX15] (NFC) — sans translittération ASCII, emojis compris. La ventilation étant plate (section 6.3), il n'y a pas de niveau d'étiquette de langue : la langue préférée de l'entité est portée par la propriété « LANG » de « entity.vcf », étiquette BCP 47 [RFC5646]. « FN » étant REQUIS (section 7.1), toute entité valide possède une feuille « by-name » ; elle reste de toute façon joignable par eid, e-mail ou téléphone. 14. Considérations IANA Ce document ne demande aucune action IANA immédiate. Si le schéma d'URI « uetree » était formalisé dans une révision ultérieure, un enregistrement sous le registre « Provisional URI Scheme » serait demandé conformément à la RFC 7595. Le champ « UID » des enregistrements « entity.vcf » emploie l'espace de noms d'URN « eid », dont l'enregistrement auprès de l'IANA est demandé par la spécification compagnon [I-D.foopgp-urn-eid] ; le présent document n'en demande pas lui-même. 15. Considérations de vie privée uetree est une convention d'agencement. Il ne révèle pas par lui-même d'information privée ; le choix des branches déployées, la visibilité de l'instance et le chiffrement par feuille déterminent ensemble la posture effective de vie privée. Les opérateurs qui publient une instance uetree SHOULD : o Restreindre le déploiement public aux branches publiques par nature (section 5.4). o Éviter de mélanger branches publiques et privées dans un même dépôt public, même temporairement, car l'historique git rend une publication accidentelle irréversible. o Envisager un chiffrement au niveau de la feuille pour les entrées dont le contenu est sensible même lorsque leur identifiant est public. o Lorsqu'ils utilisent « by-email/ » publiquement, documenter l'hypothèse implicite selon laquelle les adresses listées participent à un système de confiance identifiable, et accepter la visibilité qui en découle. Les opérateurs d'instances privées SHOULD utiliser la couche de contrôle d'accès de la section 11 pour s'assurer que l'accès en lecture correspond à l'intention des entités enregistrées. La structure d'éclatement peut elle-même divulguer de l'information : savoir que « by-eid/u4/sR/ » contient de nombreuses feuilles révèle la prévalence, dans l'instance, des identifiants u4 commençant par « sR ». Cette fuite est intrinsèque à tout registre indexé. 16. Considérations de sécurité Le format repose sur des signatures apposées sur le contenu pour l'authenticité. Lorsqu'il est stocké dans un dépôt git, le motif recommandé est d'exiger des commits signés et de définir les signataires autorisés et la profondeur de leurs écritures dans la configuration « GITREMOTE/ » (section 11), appliquée par un hook « pre-receive » côté serveur. uetree lui-même ne définit aucune primitive cryptographique. Tous les identifiants sont pris comme des chaînes opaques ; leur infalsifiabilité est de la responsabilité des schémas qui les produisent ([I-D.foopgp-urn-eid] pour les eid, [RFC5321] pour les adresses e-mail, [E.164] pour les numéros de téléphone). Les outils qui lisent « .ALIASES » MUST assainir les valeurs de pointeur — ne jamais les exécuter, ne jamais supposer qu'elles renvoient à des emplacements sûrs. La résolution étant en temps constant (section 8.3), aucune détection de cycle n'est nécessaire. Les propriétés « KEY », « PHOTO » et « URL » de « entity.vcf » peuvent référencer des ressources externes ; aller les chercher peut divulguer qu'un consommateur lisait une feuille particulière. Les outils SHOULD permettre d'en désactiver la résolution automatique. 17. Références 17.1. Références normatives [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, mars 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, mai 2017. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, décembre 2004. [RFC3986] Berners-Lee, T., Fielding, R., et L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, janvier 2005. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, octobre 2008. [RFC5646] Phillips, A. et M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, septembre 2009. [E.164] ITU-T, "The international public telecommunication numbering plan", Recommandation E.164, 2010. [UAX15] Davis, M. et K. Whistler, "Unicode Normalization Forms", Unicode Standard Annex #15, 2024. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, août 2011. [RFC6868] Daboo, C., "Parameter Value Encoding in iCalendar and vCard", RFC 6868, février 2013. [I-D.foopgp-urn-eid] Brucker, J.J. et Mnème, "The 'eid' URN Namespace", draft-foopgp-urn-eid-00, 2026. 17.2. Références informatives [RFC1034] Mockapetris, P., "Domain Names — Concepts and Facilities", STD 13, RFC 1034, novembre 1987. [RFC4511] Sermersheim, J., Éd., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, juin 2006. [RFC7595] Thaler, D., Hansen, T., et T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, juin 2015. [RFC8126] Cotton, M., Leiba, B., et T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, juin 2017. [X500] ITU-T, "Information technology — Open Systems Interconnection — The Directory: Overview of concepts, models and services", Recommandation X.500, 2019. [W3C-DID] Sporny, M., Longley, D., Sabadello, M., Reed, D., et O. Steele, "Decentralized Identifiers (DIDs) v1.0", Recommandation W3C, juillet 2022, . [ZOOKO] Wilcox-O'Hearn, B., "Names: Decentralized, Secure, Human-Meaningful: Choose Two", 2003. [GIT] Hamano, J.C. et al., "Git Distributed Version-Control System", git-scm.com, depuis 2005. [IPFS] Benet, J., "IPFS — Content Addressed, Versioned, P2P File System", arXiv:1407.3561, 2014. [PSL] Mozilla Foundation, "Public Suffix List", . [VKS] keys.openpgp.org, "Verifying Keyserver (VKS) API", . API de fait (non normalisée), définie par l'implémentation Hagrid. [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, août 2011. Adresses des auteurs Jean-Jacques Brucker foopgp u4=sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76 Mnème foopgp u5=001777236237.945e_43.30_005.38