Résumé

  • Le RFC 5333 enregistre ical-access pour l’accès CalDAV à une ressource d’agenda ou de disponibilité. L’URI issue d’ENUM indique où tenter l’opération, non qui a le droit de l’exécuter ni quelles données seront visibles.
  • ical-sched:mailto décrit une autre surface : le transport de messages de planification par iMIP. Une adresse de planification ne devient pas une collection d’agenda, et aucun de ces enregistrements ne prouve livraison, acceptation ou résultat.

Une adresse publique devant une ressource privée

Le scénario paraît simple. À partir d’un numéro E.164, un client construit le nom ENUM, interroge DNS, traite un enregistrement NAPTR et obtient une URI HTTPS. L’étiquette de service est E2U+ical-access:https. L’interface annonce aussitôt que « l’agenda est accessible ».

Cette phrase confond deux sens du mot accessible. L’adresse est découvrable. La ressource reste soumise à l’authentification et à l’autorisation du service CalDAV. Un serveur peut répondre au réseau, présenter un certificat valide, reconnaître l’utilisateur et néanmoins refuser la méthode demandée. Il peut révéler seulement une disponibilité agrégée, autoriser une lecture limitée ou interdire toute écriture.

Le RFC 5333 ne transporte pas ces privilèges. Il relie un numéro à une URI dont le type annonce une utilisation. La politique demeure chez le service cible. Une architecture correcte conserve donc « découvert » et « autorisé » dans deux états que rien ne fusionne automatiquement.

ical-access décrit une surface, pas son contenu

Le subtype http ou https d’ical-access conduit vers CalDAV. Cette précision évite qu’un client traite l’URI comme une page web quelconque. Elle ne décrit toutefois ni le propriétaire actuel de la ressource, ni les collections enfants, ni les ACL, ni l’étendue des données retournées.

L’URI peut avoir été publiée avant une migration. Elle peut rediriger vers un autre domaine. Le numéro peut avoir changé de titulaire. La ressource peut exister mais être désactivée, ou fonctionner avec une identité que le client ne possède pas. Chacun de ces cas laisse subsister un enregistrement DNS parfaitement lisible.

Le bon modèle de preuve part donc de l’observation : numéro d’entrée, normalisation, nom interrogé, RRset, instant et validation. Il poursuit avec le choix NAPTR, la réécriture, les redirections, l’identité TLS, l’identité du principal, la décision d’autorisation et la réponse CalDAV. L’URI ne peut pas écrire à l’avance les valeurs des étapes suivantes.

Une disponibilité libre ne signifie pas un agenda libre

Le texte du RFC parle de ressources de calendrier ou de free/busy. Cette alternative est essentielle. Une organisation peut choisir de publier des créneaux occupés sans exposer les intitulés, participants ou notes. Elle peut appliquer une granularité différente selon le demandeur.

Un outil qui traduit toute réponse ical-access par « lecture d’agenda autorisée » efface cette minimisation. À l’inverse, un échec de lecture détaillée ne prouve pas que le record est périmé : la ressource peut remplir exactement son rôle en ne fournissant que la disponibilité autorisée.

La mesure doit porter sur l’opération précise. Quelle méthode a été envoyée ? Sous quel principal ? Sur quelle ressource ? Quel statut et quelle charge utile ont été reçus ? Le niveau de détail obtenu correspond-il à la politique ? Sans ces champs, un test d’accès transforme une restriction légitime en panne apparente.

La planification par mail relève d’une autre chaîne

Le service ical-sched avec subtype mailto désigne une adresse pour la planification selon iTIP transportée par iMIP. Il permet de trouver une destination à laquelle envoyer une demande, une réponse ou un autre objet de planification.

Cette adresse n’est pas une URI CalDAV. Elle ne permet pas d’énumérer les événements ni de modifier directement une collection. La passer à un client d’accès constitue une erreur de type, même si les deux fonctions sont présentées sous le mot « calendrier ».

Une remise SMTP réussie ne ferme pas davantage la chaîne. Le message peut être filtré, retardé, classé, analysé par un logiciel qui refuse l’objet ou affiché à un humain qui ne répond pas. L’acceptation d’une invitation appartient à l’état de planification, non au DNS et non au transport de courrier. Une plateforme ne devrait produire le mot « accepté » qu’à partir du reçu applicatif correspondant.

DNSSEC authentifie le RRset, pas le lecteur

Les réponses DNS peuvent être modifiées ou usurpées. Lorsqu’une chaîne DNSSEC pertinente est validée, le résolveur peut fournir une assurance cryptographique sur les données DNS reçues. Ce résultat protège une partie importante de la découverte.

Il ne se transmet pas comme un jeton au serveur d’agenda. DNSSEC n’authentifie pas l’utilisateur CalDAV. Il ne décide pas si une méthode PROPFIND, REPORT ou PUT est permise. Il ne prouve pas non plus que le titulaire du numéro contrôle encore la boîte mailto: produite par la réécriture.

Il faut donc enregistrer l’état DNSSEC avec son contexte : résolveur, instant, chaîne et résultat. L’étiquette secure signifie que le RRset a satisfait le modèle de validation. Elle ne signifie ni « ressource sûre », ni « utilisateur de confiance », ni « action autorisée ». La précision protège la valeur de DNSSEC au lieu de lui attribuer une promesse impossible.

La confidentialité fuit parfois avant l’authentification

Le RFC 5333 souligne qu’une URI d’agenda peut révéler le nom ou l’employeur d’une personne. La fuite survient au niveau de la découverte publique, avant toute tentative d’ouvrir l’agenda. Une ACL parfaite ne retire pas une chaîne déjà inscrite dans DNS et observée par des tiers.

Une URI opaque atténue l’exposition la plus directe. Elle ne garantit pas l’anonymat. La stabilité du jeton, les requêtes répétées, les redirections, le nom TLS, les journaux et la connexion ultérieure peuvent permettre une corrélation. L’opacité ne garantit pas non plus que le mapping reste frais après une mutation ou une réattribution du numéro.

La gouvernance doit considérer l’URI publique comme une donnée personnelle potentielle. Il faut minimiser les identifiants parlants, limiter la durée de vie, prévoir la rotation, révoquer les anciennes cibles et examiner ce que révèle le simple graphe numéro-vers-service. La question de confidentialité précède la question des droits d’accès.

Ordre et préférence ne mesurent pas la santé

NAPTR offre des champs d’ordre et de préférence pour guider la sélection. Ces valeurs coordonnent le choix dans un ensemble de records ; elles ne constituent pas des sondes de disponibilité. Le record préféré peut désigner une ressource arrêtée. Un record moins préféré peut être opérationnel. Le DNS n’a pas observé la transaction CalDAV à la place du client.

Confondre priorité et santé crée des tableaux trompeurs. Une sélection conforme devient « primaire disponible », puis un échec d’autorisation est attribué au DNS. Il faut au contraire joindre, sans les fusionner, la décision de sélection et le reçu du service : résolution de cible, connexion, TLS, authentification, autorisation, méthode et résultat.

La même discipline empêche un basculement dangereux entre types. Une adresse mailto: ne doit pas devenir le secours automatique d’une opération de lecture, et une URI CalDAV ne doit pas recevoir un objet iMIP simplement parce que le premier record échoue.

Le registre n’inventorie pas les déploiements

Le registre IANA fixe un vocabulaire partagé. Il documente les enumservices, les subtypes et les schemes associés. Sa présence permet à deux implémentations de donner le même sens à un token.

Il ne recense ni les numéros qui publient ce token, ni les services réellement actifs, ni leur version, ni leurs utilisateurs. Une ligne de registre ne prouve pas que la fonction est déployée aujourd’hui. Un NAPTR observé ne prouve pas que le service répond. Une réponse HTTP ne prouve pas que l’opération voulue est autorisée.

Chaque proposition exige son propre inventaire. La gouvernance du vocabulaire relève de l’IANA et de la norme. L’inventaire de publication relève de DNS. L’inventaire opérationnel relève des exploitants de calendriers et du monitoring. Lier ces ensembles est utile ; les remplacer les uns par les autres ne l’est pas.

La chaîne de décision que devrait voir un dirigeant

Une vue exploitable ne se résume pas à un voyant vert. Elle montre le numéro présenté, le nom ENUM calculé, la réponse exacte, son état DNSSEC, le record sélectionné et l’URI produite. Elle montre ensuite un second trajet adapté au type : accès CalDAV ou planification par courrier.

Pour CalDAV, la vue sépare joignabilité, identité serveur, identité client, privilège, méthode et mutation. Pour iMIP, elle sépare création de l’objet, remise au transport, livraison, interprétation par le client et réponse du participant. Un état inconnu reste visible ; il ne devient pas un succès par proximité.

Cette chaîne localise la responsabilité. Le DNS peut être correct tandis que l’ACL refuse l’appel. Le transport peut réussir tandis que le participant décline. Le record peut être authentique tandis que l’URI est obsolète. L’organisation peut alors corriger la bonne couche sans affaiblir les autres.

Ce que les sources ne permettent pas d’affirmer

Les sources examinées décrivent des formats, des registres, des mécanismes et des risques. Elles ne démontrent pas qu’une personne nommée subit aujourd’hui une fuite d’affiliation. Elles ne documentent pas une intrusion CalDAV, une invitation frauduleuse, une panne de fournisseur ni une campagne d’abus liée à RFC 5333.

Cette absence limite le récit factuel. Elle n’annule pas les décisions préventives : conserver les types, réduire les identifiants publics, tester les révocations et exiger des reçus applicatifs. L’analyse doit expliquer le mécanisme sans fabriquer un incident pour lui donner du poids.

Sources