Summary

  • El borrador publicado el 23 de octubre propone usar DNSSEC y un nuevo tipo de registro, OPKEY, para comprobar claves y retiradas de credenciales de origen de contenidos.
  • El editor puede publicar una lista opcional de entidades autorizadas a expedir su perfil principal; un verificador rechazaría perfiles de emisores ajenos a una lista autenticada.

Que una entidad sepa fabricar carnés no significa que pueda repartir carnés de nuestra redacción. Esa diferencia, bastante comprensible fuera de Internet, aparece en el borrador de Shigeya Suzuki del 23 de octubre. La ficha oficial lo identifica como propuesta individual activa, sin respaldo formal de IETF. El autor busca una especificación experimental; todavía hay que probarla.

El esquema parte de un perfil de origen. Un emisor entrega al creador de contenidos un perfil principal con sus claves públicas; el creador firma lo que publica. Otros emisores pueden añadir anotaciones con atributos validados. Esas firmas cuentan quién firmó una pieza, pero el lector necesita saber si la clave y las credenciales siguen vigentes. El borrador coloca huellas de claves en registros OPKEY bajo _op, mantiene los documentos completos fuera del DNS y contempla un TXT para marcar la revocación de una anotación. El emisor del perfil principal publica el estado de sus perfiles.

La propuesta adquiere filo político en la zona DNS del propio editor. Un registro SVCB en _op.<originator> puede enumerar los emisores de perfiles principales aceptados por ese dominio. Si la respuesta está validada mediante DNSSEC, el verificador contrasta el emisor de la credencial con esa lista. Una entidad reconocida por el marco general podría quedar fuera de la puerta de una publicación concreta. El registro es voluntario: cuando no se exige y falta una lista segura, el editor queda sin esa restricción. Su mera posibilidad ya cambia la pregunta de «¿quién acredita?» a «¿quién permitió acreditarlo?».

No basta con poner nombres en una casilla. OPKEY exige respuestas DNSSEC seguras; una zona sin firma, una prueba inválida o un fallo de resolución hacen fracasar la verificación. No equivalen a una retirada demostrada. Para la lista SVCB opcional, una ausencia demostrada puede dejar al editor sin fijación de emisor, mientras que un fallo o una respuesta corrupta detienen el proceso. La diferencia impide que una avería se disfrace de decisión editorial.

Una credencial retirada tampoco desaparece de todos los ojos al pulsar borrar. El borrador toma una hora de vida de registros y caché negativa como hipótesis operativa. Una respuesta antigua puede seguir circulando hasta su vencimiento; una firma DNS capturada y respuestas servidas como obsoletas pueden prolongar ciertos efectos. En una prueba de laboratorio configurada a 60 segundos, altas y bajas se hicieron visibles a través de un resolutor validador en un máximo de 63 segundos. Ese experimento no establece un plazo universal de revocación.