Resumen

  • ical-sched:mailto identifica un destino para transportar objetos de planificación iTIP por correo mediante iMIP. No identifica una colección CalDAV ni concede permiso para leer o cambiar un calendario.
  • ical-access:http y ical-access:https descubren una superficie de acceso, pero tampoco prueban autenticación, autorización, disponibilidad, creación de un evento o aceptación de un participante. Cada resultado necesita su propio recibo.

El error nació al borrar una palabra

RFC 5333 registra dos familias de enumservices para calendarios. Una se llama ical-sched; la otra, ical-access. La primera puede producir una URI mailto: para intercambiar mensajes de planificación. La segunda produce una URI HTTP o HTTPS para trabajar con recursos CalDAV de calendario o disponibilidad.

Cuando una base guarda ambas como calendar_endpoint, parece haber simplificado el modelo. En realidad, ha eliminado el verbo. Ya no sabe si debe enviar una solicitud de reunión o consultar una colección. Tampoco sabe qué seguridad, identidad y prueba de éxito corresponde a la operación.

Los tipos existen para limitar acciones. Una URI válida para un flujo no es una variante degradada de la otra. Una dirección de correo no se transforma en un recurso web porque esté asociada al mismo número, y una URI CalDAV no es un buzón para mensajes iMIP.

Planificar por correo no equivale a tocar el estado del calendario

iTIP define objetos y métodos de planificación; iMIP permite transportarlos a través del correo de Internet. Un cliente puede enviar una petición a la dirección descubierta. Ese acto inicia una cadena, no la termina.

El MTA emisor puede aceptar el mensaje. Otro servidor puede rechazarlo después, ponerlo en cuarentena o entregarlo. Un cliente de calendario puede reconocer el objeto, asociarlo a una persona, mostrarlo, deduplicarlo o descartarlo. El participante puede aceptar, rechazar, responder provisionalmente o guardar silencio.

Ninguno de esos estados aparece en el NAPTR. Tampoco aparece en una respuesta SMTP aislada. Por eso un agente automático no debe convertir “mensaje enviado” en “reunión confirmada”. El recibo de transporte y el estado de participación pertenecen a sistemas y momentos distintos.

Acceder tampoco significa recibir todos los derechos

ical-access ofrece un camino para intentar el protocolo CalDAV. El servidor de destino puede exigir credenciales y aplicar permisos diferentes según el principal, la colección y el método. Puede mostrar free/busy sin revelar títulos, permitir lectura sin escritura o denegar por completo la operación.

La URI solo descubre la superficie. No contiene una ACL. No nombra necesariamente al propietario actual. No demuestra que el recurso siga donde estaba cuando se publicó el DNS. Una redirección puede llevar a otra frontera administrativa; una reasignación del número puede dejar una asociación antigua.

La telemetría debería escribir por separado target_resolved, server_authenticated, client_authenticated, method_authorized, response_received y state_committed. Si una interfaz necesita una síntesis, debe poder volver a esos hechos en lugar de ocultarlos bajo “calendario conectado”.

El número de teléfono tampoco autentica a la persona

ENUM comienza con un número E.164 y lo transforma en un nombre DNS. Esa relación no convierte el número en una identidad universal. Quien controla hoy una línea puede no ser quien publicó ayer el record. La URI resultante puede representar un rol, una organización, un servicio compartido o una dirección que ya cambió de dueño.

Tratar el resultado como identidad del asistente agrava el error de tipo. Un destinatario de correo puede recibir el objeto sin ser la persona imaginada por el emisor. Un servicio CalDAV puede autenticar una cuenta distinta de la inferida desde el número. Las aplicaciones deben resolver la identidad dentro de su propio contexto y conservar la procedencia de esa resolución.

El campo útil es “mapping observado entre este número y esta URI a esta hora”. La afirmación “esta persona controla la agenda” exige evidencia adicional y no puede heredarse del mecanismo de descubrimiento.

DNSSEC responde una pregunta más estrecha

La manipulación de DNS puede llevar al cliente hacia una URI falsa. DNSSEC permite que un validador autentique los datos DNS cuando la cadena y el procesamiento correspondientes tienen éxito. Esa garantía es fundamental para no aceptar una respuesta alterada como si proviniera de la zona.

Pero DNSSEC no inicia sesión en CalDAV. No autoriza un PUT. No demuestra control del buzón. No comprueba que un mensaje iMIP llegue al calendario correcto. Mucho menos registra la decisión de un participante.

Una plataforma debe conservar el estado de validación como propiedad del RRset. Extenderlo a trusted_calendar = true sería una escalada semántica. Una respuesta auténtica puede señalar un servicio caído, una URI obsoleta o un recurso que niega al usuario, y seguir siendo una respuesta DNS auténtica.

Lo público puede revelar relaciones privadas

RFC 5333 advierte que una URI publicada puede incluir nombre o empleador. En ese caso, la consulta ENUM revela una relación antes de que el servidor de calendario pida credenciales. La confidencialidad del contenido no revierte la exposición del identificador.

Usar una URI opaca reduce el significado visible. No elimina toda correlación. Un token estable, un dominio distintivo, la frecuencia de consultas, una redirección, los registros del servicio y la autenticación posterior pueden volver a unir los datos. Tampoco garantizan que el mapping haya sido revocado tras una salida de la empresa o una reasignación telefónica.

El diseño debe minimizar lo que se publica, definir rotación, retirar objetivos antiguos y auditar el grafo de asociaciones. La privacidad no empieza en la respuesta CalDAV; empieza en el momento en que un número se convierte públicamente en una dirección de servicio.

Order y preference no son sondas de disponibilidad

Los campos de orden y preferencia de NAPTR ayudan a seleccionar records. Un valor preferido indica cómo procesar el conjunto, no que el objetivo esté sano. La selección puede ser normativa y la conexión puede fallar un segundo después.

Un dashboard que interpreta prioridad como SLA fabrica evidencia. También corre el riesgo de usar un record de tipo distinto como fallback: tras fallar un acceso HTTPS, puede enviar correo y presentar el envío como sustituto de una lectura. La operación cambió, aunque el producto mantenga la misma luz verde.

El recibo de selección debe contener el RRset y la regla aplicada. El recibo operativo debe contener resolución de la URI, redirecciones, conexión, identidad, autorización y resultado. Solo su unión explícita permite analizar la cadena sin confundir configuración con salud.

El registro IANA no es un mapa de servicios activos

La entrada en IANA define el significado interoperable de los tokens. Es la autoridad adecuada para el vocabulario. No es una base de instalaciones, números publicados, proveedores activos ni usuarios.

Puede existir un enumservice registrado sin que una organización concreta lo despliegue. Puede existir un NAPTR sin que el objetivo responda. Puede responder el objetivo sin conceder la operación. Puede aceptar una operación sin producir el efecto esperado. Cada paso añade evidencia y también una nueva posibilidad de fallo.

Para medir adopción se necesita un método de observación declarado y acotado en el tiempo. Para medir éxito se necesitan transacciones. Para afirmar aceptación se necesita estado de planificación. La permanencia de un registro no puede llenar esos huecos.

Una arquitectura que conserve los verbos

El esquema más seguro no usa un campo genérico. Conserva enumservice, subtype y scheme, además del número de origen, el nombre de consulta, el RRset, el estado DNSSEC, los campos NAPTR, la expresión de reescritura y la URI resultante.

Después abre una rama. La rama de acceso registra servidor, TLS, principal, recurso, método, autorización, respuesta y mutación. La rama de planificación registra objeto iTIP, identificador de mensaje, entregas, interpretación y respuesta. Los estados desconocidos son válidos; no se rellenan desde el éxito anterior.

Esta separación permite políticas claras. Un agente autorizado para invitar puede no estar autorizado para leer. Un servicio de free/busy puede no permitir escrituras. Un operador DNS puede corregir una URI sin hablar en nombre del participante. El diseño refleja la distribución real de control.

La investigación no demuestra un incidente actual

Las fuentes consultadas describen normas, registros y amenazas. No documentan una intrusión vigente, una víctima, una campaña de invitaciones, una filtración de agenda ni un fallo de proveedor atribuido a RFC 5333. No corresponde inventarlos.

Sí permiten una conclusión operativa: los sistemas que pierden el tipo pueden ejecutar el verbo equivocado y exagerar el resultado. Corregir el esquema, preservar recibos y limitar la publicación son acciones justificadas por el mecanismo, sin convertir un riesgo arquitectónico en una acusación presente.

Fuentes