Resumen

  • RFC 5105 considera válida la firma como condición necesaria, no suficiente, de un token válido. El Registro aún debe comprobar el elemento firmado, transformaciones, algoritmo, certificado, acreditación de la VE, registrador, número, método, fechas y reglas contra repetición.
  • El token es una declaración de validación. No equivale a autorización del Registro, ejecución EPP, delegación publicada, respuesta DNS ni servicio completado.

Un atacante escucha una solicitud y copia el token XML. No cambia un solo byte. Más tarde lo presenta mediante otro registrador. La firma verifica, el resumen coincide y el certificado es el mismo. Precisamente por eso, el intento no debe pasar inadvertido.

El campo registrarID firmado identifica al registrador para quien se realizó la validación. RFC 5105 ordena al Registro comparar el contenido del token con la solicitud de delegación. Una firma válida para el Registrador A es evidencia de que la petición del Registrador B no coincide.

Esta escena resume la arquitectura: la autenticidad no es autorización.

ENUM vincula un nombre de dominio con un número E.164. RFC 4725 exige que el nombre corresponda a un número asignado, que el número esté dentro de un rango aprobado, que el titular autorice el registro y que el registrante coincida con ese titular. Una Validation Entity verifica esa relación. Un Registrar tramita la petición. El Registry administra las delegaciones y la zona autoritativa.

Los papeles pueden recaer en algunas de las mismas organizaciones, pero las funciones siguen siendo distintas. La VE afirma que aplicó una validación. El Registrar presenta. El Registro evalúa su política. Un proveedor DNS sirve la zona. Una aplicación utiliza después el resultado. El documento firmado no absorbe la autoridad de los sistemas posteriores.

RFC 5105 da forma portable al resultado de la VE. El elemento obligatorio incluye una serie única dentro de esa VE, el número E.164, un posible límite final de bloque, el identificador de la VE, el del Registrar, el de la metodología, la fecha de ejecución y una fecha de vencimiento opcional. Puede añadirse información de contacto, pero todo ese bloque es facultativo.

La serie necesita su espacio de nombres. 000001 no identifica globalmente un token. Hay que unir VE y serie, y para decidir también el hash exacto, el Registrador, el alcance E.164, el método y las fechas. Un panel que elimina esas dimensiones transforma una clave local en una falsa identidad universal.

El bloque numérico también es exacto. E164Number señala el inicio y lastE164Number, si existe, el final inclusivo. Ambos deben tener la misma longitud. No corresponde a un importador ampliar el intervalo, eliminar estructura o reinterpretar prefijos. La firma cubre una representación; la comparación con el dominio solicitado sigue siendo trabajo del Registro.

La protección utiliza XML-DSIG envolvente y canonicalización XML exclusiva. La canonicalización evita que declaraciones de espacios de nombres tomadas del contenedor EPP alteren el material firmado. Es una regla de representación, no una regla de negocio. No demuestra que el documento respete el esquema adecuado ni que el método descrito sea aceptable.

La referencia es decisiva. El token debe llevar Id="TOKEN", y la firma debe referirse a #TOKEN. RFC 5105 advierte que mover el identificador a tokendata haría inútil la firma para este fin. Un verificador genérico podría aceptar la firma sobre las coordenadas mientras dejaba fuera el número y los datos de validación.

Por eso el Registro no puede limitarse a preguntar si XML-DSIG devolvió éxito. Debe verificar transformaciones y algoritmos aprobados, la referencia al elemento completo y que la clave pertenezca a una VE acreditada. El ejemplo del RFC lo formula sin ambigüedad: una firma válida es necesaria, pero no suficiente, para un token válido.

El certificado incorporado tampoco se acredita a sí mismo. El Registro puede actuar como autoridad, confiar en una CA pública o aceptar claves preinscritas. La elección es política local. El certificado aporta una clave y una posible cadena; no escoge el ancla de confianza ni demuestra por sí solo que la VE seguía acreditada cuando se tomó la decisión.

Un registro forense útil conserva el estado de acreditación y el almacén de confianza de aquel momento. La validez criptográfica del certificado puede sobrevivir a la relación institucional. Una revocación posterior puede cambiar la evaluación actual sin borrar lo que un sistema histórico observó. Ambas temporalidades deben quedar visibles.

Las fechas del token tampoco son un permiso automático. La fecha de ejecución dice cuándo se practicó la validación. La fecha de expiración opcional delimita su duración; si falta, el formato la considera infinita. Aun así, el Registro debe comprobar que esa ausencia cumple su política y debe definir cuánto tiempo después de la ejecución puede emplearse el token.

Así aparecen dos relojes: duración declarada y ventana de presentación. Un token puede no haber expirado y llegar demasiado tarde para autorizar una solicitud. Puede ser reciente y contener una expiración prohibida. Puede superar ambos controles y estar ligado a otro registrador. Un booleano signature_valid no contiene estas respuestas.

El método merece su propia decisión. methodID identifica el procedimiento que la VE declara haber usado. RFC 4725 reconoce que los métodos varían según fuentes de datos, parte, elección del titular y requisitos regulatorios. El identificador no demuestra ejecución correcta. La política del Registro decide si ese método satisface el mínimo para el número y la fecha en cuestión.

La validación tampoco queda congelada para siempre. RFC 4725 distingue validación inicial y revalidación. La delegación debe seguir el estado del número E.164. Si la revalidación fracasa, la delegación debe suspenderse mediante una orden o al vencer la validación, con el posible margen que prevea la política local. Una antigua firma exitosa no invalida ese evento posterior.

La repetición es más amplia que copiar bytes por otra red. Un token aceptado una vez podría presentarse de nuevo dentro de su aparente vigencia. La política debe definir uso y ventana. La bitácora debe guardar VE, serie, hash, registrador, alcance, fecha de primera presentación y resultado. Sin ello, el Registro no sabe si observa una continuación legítima, un reintento rechazado o una segunda autorización indebida.

Los datos facultativos de contacto no deben convertirse en sustitutos del núcleo. Pueden facilitar revalidaciones, pero una organización o una dirección de correo no prueba la asignación actual del número. Además, el token no cifra esos datos. Si se exige confidencialidad, debe haber otro mecanismo. Firma, cifrado de transporte y autorización son propiedades separadas.

Los algoritmos muestran por qué la política necesita fecha. RFC 5105 exigía soporte de RSA-SHA1 y RSA-SHA256, aunque ya señalaba dudas criptográficas sobre SHA-1. El Registro define qué acepta. La capacidad de una biblioteca para verificar un algoritmo histórico no obliga a aceptarlo hoy. Compatibilidad, seguridad vigente y selección concreta no son el mismo dato.

Tras aceptar el token comienza otra cadena. RFC 5076 proporciona una extensión EPP para añadir, cambiar, eliminar o consultar información de validación. Una respuesta satisfactoria acredita el intercambio EPP correspondiente. No es prueba automática de que la zona autoritativa se actualizó.

El Registro puede comprometer una fila y fallar al generar la zona. Los servidores pueden publicar y un resolvedor conservar caché anterior. RFC 3761 describe cómo ENUM deriva búsquedas y obtiene URI, pero una respuesta no asegura que el URI sea correcto o que el destino responda. El éxito de una llamada o servicio pertenece todavía a otra capa.

Conviene modelar estos límites como recibos enlazados. El recibo criptográfico registra bytes exactos, hash, parser, esquema, ID resuelto, nodo referenciado, transformaciones, entrada canonicalizada, algoritmos, clave, cadena, anclas y resultado. No debe decir «delegación autorizada».

El recibo de política registra acreditación de la VE, método permitido, coincidencia del Registrador, alcance del número, fechas, ventana de uso, historial de repetición y versión normativa. El Registro emite aparte aceptación o rechazo con causa. EPP, la base de delegaciones, la publicación autoritativa, el resolvedor y la aplicación producen después sus propios comprobantes.

La separación mejora la seguridad y la capacidad de reparación. Si aparece una delegación errónea, se puede saber si la VE firmó el número equivocado, si el token fue usado por otro registrador, si la política aceptó un algoritmo viejo, si EPP falló o si DNS no convergió. Un único estado «validado» sólo dice que la organización perdió la pregunta original.

La disciplina coincide con las capas de realidad de Heng Lu. La firma es una evidencia fuerte de procedencia cuando permanece en su capa. Se convierte en poder simbólico cuando se usa para declarar decisiones o resultados que otros actores aún no produjeron. El código en ejecución debe rendir cuenta de cada transición, no heredar un verde lejano.

Para dirección, la regla práctica es concreta: ningún servicio de firma debe publicar authorized=true sin calificación. Debe describir qué nodo y bytes verificó, con qué clave, algoritmo, confianza y política. Sólo el Registro puede emitir la decisión de delegación; sólo DNS puede demostrar publicación; sólo una observación operacional puede demostrar funcionamiento.

Fuentes