Ce RFC normalise le format des
adresses du protocole de messagerie
instantanéeXMPP, protocole également connu sous son ancien nom de
Jabber. Il remplace l'ancien avec
notamment un changement important sur l'internationalisation de ces adresses, le passage
au nouveau système PRECIS (décrit dans le ), qui
remplace stringprep. Les adresses XMPP peuvent
en effet être entièrement en Unicode.
Le protocole XMPP est le standard actuel de
messagerie instantanée de
l'IETF
(il est normalisé dans le ). Les utilisateurs sont identifiés par
une adresse également connue, pour des raisons
historiques, sous le nom de JID (Jabber
IDentifier). Ces adresses ont une forme qui ressemble aux
adresses de courrier électronique mais elles
sont en fait complètement différentes. Ainsi, j'ai personnellement
deux adresses XMPP, bortzmeyer@gmail.com (le
service de messagerie Google Talk utilise en
effet la norme XMPP), qui me sert surtout pour la distraction, et
bortzmeyer@dns-oarc.net qui me sert pour le
travail (j'utilise aussi le service XMPP de la Quadrature du
Net mais plus rarement). Mais rien ne dit qu'un courrier envoyé à ces adresses
fonctionnera : adresses XMPP et de courrier vivent dans des mondes différents.
Le format des adresses XMPP était spécifié à l'origine dans le
document XEP-0029. Puis il a été
normalisé dans la
section 3 du . La norme XMPP ayant subi une refonte
complète, qui a mené entre autres à un nouveau RFC, le , se posait la question du format d'adresses,
dont l'internationalisation, compte tenu de la
nouvelle norme IDN, suscitait des
débats. Ces débats n'étant pas terminés, la décision a été prise de
sortir le format d'adresses du RFC principal, et d'en faire le , jusqu'à ce qu'un consensus apparaisse sur le format
« définitif ». Ce format final est celui de notre , qui utilise pour Unicode le
cadre PRECIS, normalisé dans le .
Donc, quels sont les points essentiels des adresses XMPP (section
3) ? Une adresse (ou JID) identifie une entité (un humain mais peut-être aussi
un programme automatique). Elle comprend trois parties (dont une
seule, le domaine,
est obligatoire), la partie locale, le
domaine et une
ressource. Ainsi, dans
bortzmeyer@gmail.com/Home,
bortzmeyer est la partie locale,
gmail.com le domaine et Home
la ressource. Le @ et le
/ servent de séparateurs. Chacune des trois
parties peut être composée de caractères
Unicode, qui doivent être encodés en
UTF-8. La partie locale doit être canonicalisée
avec PRECIS et son profil UsernameCaseMapped
(voir ), le domaine avec les méthodes
IDN des et . Seul le domaine est obligatoire et
bot.example.org est donc un JID valide.
Les adresses XMPP (ou JID) sont souvent représentées sous forme
d'un IRI, selon le . En gros, un IRI XMPP est un JID préfixé par
xmpp:. Mais ces IRI ne sont pas utilisés par le
protocole XMPP. Dans les champs to et
from des strophes (stanzas) XMPP, on
ne trouve que des JID (sans le xmpp: devant). Les
IRI ne servent que dans les liens dans les pages Web, comme (attention, ce lien ne marchera pas
avec tous les navigateurs).
Le RFC détaille ensuite chaque partie. Le domaine, seule partie
obligatoire, est dans la section 3.2. On peut le voir comme une
identification du service auquel on se connecte
(gmail.com = Google Talk), et la création de
comptes et l'authentification se font typiquement en fonction de ce
service. En théorie, une adresse IP est
acceptable pour cette partie mais, en pratique, c'est toujours un
FQDN. Ce nom de domaine peut être un
IDN donc
instantanée.nœud.example est un nom
acceptable pour former un JID. Auquel cas, ce doit être un IDN légal
(ce qui veut dire que toute chaîne de caractères Unicode n'est pas
forcément un nom légal pour la partie domaine d'un JID). À noter que
XMPP n'utilise pas l'encodage en
ASCII des IDN (le Punycode).
Et la partie locale, celle avant le @ ? La
section 3.3 la couvre. Elle est optionnelle et identifie en général
une personne (mais peut aussi indiquer un programme ou bien un salon de
conversation à plusieurs). Si elle est en Unicode, elle doit être
canonicalisée avec le profil UsernameCaseMapped
de PRECIS, profil décrit dans le . Cette partie locale est donc insensible à
la casse. Certains caractères normalement autorisés par ce
profil sont explicitement interdits en XMPP comme les séparateurs
/ ou @ mais aussi comme
" ou <. (Voir XEP-0106 pour un
mécanisme d'échappement permettant de mettre quand même ces caractères.)
Quant à la ressource, troisième partie du JID (après le
/), également optionnelle, elle sert à
distinguer plusieurs sessions par le même utilisateur (par exemple
/Home et /Office). La
section 3.4 la décrit en détail. Également en Unicode, elle est
canonicalisée par le profil OpaqueString de la
classe FreeformClass de PRECIS (, section 4.3). Elle n'a pas de structure
officielle. Un / dans une ressource (par exemple
example.com/foo/bar) n'implique donc pas une hiérarchie.
De même, si on y trouve quelque chose ressemblant à une adresse (par
exemple joe@example.net/nic@host), cette ressource
nic@host doit être traitée comme un identificateur
opaque (et pas être analysée en « nom (at) machine »).
La section 3.5 contient quelques exemples de JID. Si certains sont
« ordinaires » (le classique juliet@example.com/foobar,
reprenant la tradition XMPP des noms tirés de Roméo et
Juliette), d'autres sont plus déroutants à première vue
comme juliet@example.com/foo@bar (le domaine est
example.com, la ressource
foo@bar),
foo\20bar@example.com (avec un échappement pour
l'espace), π@example.com (partie locale en
Unicode), king@example.com/♚ (ressource en
Unicode), example.com (juste le nom de
domaine)...
Il y a aussi des exemples de JID illégaux,
qu'il ne faut pas utiliser, comme
"juliet"@example.com (les guillemets),
foo bar@example.com (l'espace),
henriⅣ@example.com (le caractère Unicode à
la fin de la partie locale a un équivalent canonique et n'est donc pas
autorisé), ♚@example.com (la partie locale
doit obéir aux règles restrictives du ,
qui n'autorise pas les symboles dans les identificateurs, seulement
les lettres et chiffres), juliet@ (domaine
absent)...
En parlant d'adresses illégales, qui doit vérifier qu'elles sont
légales ? Évidemment, l'émetteur devrait le faire. Mais notre RFC va
plus loin en recommandant (section 4) que le récepteur jette les
messages XMPP (les strophes, stanzas en anglais)
contenant de telles adresses. C'est donc plus strict que le
traditionnel principe de robustesse.
Quelles sont les conséquences de sécurité de ces adresses ? Il n'y
en a guère mais, bon, il y a toujours des inquiets donc la section 7
examine en détail tous les risques, même très théoriques. Bien sûr,
les adresses XMPP héritent des questions de sécurité de
PRECIS mais le RFC mentionne surtout les risques de triche
sur les
adresses. Il y en a de deux sortes, les usurpations et les
imitations. Les usurpations (section 7.3.1) sont les cas où un méchant
arrive à envoyer un message XMPP en trichant sur
l'origine, par exemple si jean@example.net, une
fois authentifié auprès de son propre serveur, arrive
à transmettre un message prétendant venir de
jeanne@jabber.example. Normalement, le protocole
XMPP empêche cela, par l'authentification mutuelle des serveurs (sauf
attaques un peu sophistiquées, par exemple sur le DNS). Cela
dit, cette authentification n'empêche pas un serveur d'annoncer une
autre partie locale (jeanne@example.net au lieu
jean@example.net).
L'autre risque est celui d'imitation (section 7.3.2). Cette fois,
il s'agit d'utiliser des JID légitimes et authentiques mais qui ressemblent à celui de la victime,
par exemple fric@paypa1.com au lieu de
fric@paypal.com (si vous ne voyez pas la
différence, regardez mieux). Cette technique est souvent connue sous
le nom de typejacking. Comme le montre l'exemple du RFC ou bien celui cité plus haut,
le problème arrive même en se limitant à ASCII. Si vous voulez un joli
exemple avec Unicode (mais le résultat dépend de l'environnement avec
lequel vous lisez cet article), regardez ᏚᎢᎵᎬᎢᎬᏒ qui ressemble à
STPETER mais est écrit en
Cherokee. Comme un JID peut contenir à peu près
n'importe quel caractère Unicode, il n'y a pas vraiment de prévention technique
possible contre ce problème. Il est peu probable que cela ait des conséquences en pratique.
La liste complète des changements par rapport au figure en annexe A. Rappelons que le s'appuyait, pour les parties en
Unicode, sur des profils
Stringprep () comme Nameprep. Ce Nameprep, décrit dans le , ayant été supprimé à l'occasion de la
réforme IDNA bis, le grand changement
dans ce nouveau RFC est l'abandon complet de stringprep et
l'utilisation de PRECIS pour les identificateurs (comme la partie
locale d'un JID) et d'IDN pour le nom de domaine.
Vu les changements entre stringprep et PRECIS, on ne peut pas
garantir à 100 % que les JID autrefois valides le seront
toujours. Mais, dans la plupart des cas, les anciens JID Unicode
resteront légaux et utilisables.