Resumen

  • DASS describió la revocación como un problema abierto de certificados: una firma seguía verificándose aunque la clave privada pudiera haber caído en manos ajenas.
  • RFC 1507 ofreció una salida lenta por expiración y renovación, y otra potencialmente más rápida basada en mantener solo certificados vigentes en el servicio de nombres. La segunda trasladaba la dependencia al directorio y a sus copias.
  • La propuesta estaba marcada como Experimental. El RFC permite analizar el diseño, pero no afirmar cuántas máquinas llegaron a ejecutarlo.

Cuando la firma seguía siendo correcta

La compromisión de una clave no borra el certificado que la vincula con un nombre. Mientras un servidor crea que ese certificado sigue vigente, un tercero con la clave privada puede presentar una firma que supere la comprobación criptográfica. El RFC 1507 empieza el problema de revocación en ese punto: no basta con crear certificados; el sistema tiene que comunicar cuándo dejan de servir como prueba de identidad.

DASS, el Distributed Authentication Security Service de Charles Kaufman, se publicó en septiembre de 1993. Su pregunta sobre las claves estaba ligada a otra ambición: que una identidad pudiera pasar de una máquina a otra. Si cada persona aparecía como una colección de cuentas locales, los servicios debían mantener asociaciones para cada una. DASS quería asignar un nombre global a cada usuario y permitir que la máquina de acceso se acreditara por separado.

La diferencia entre persona y máquina era importante. Un recurso podía permitir que cierto usuario actuara solo desde un nodo concreto. En las credenciales DASS, los secretos de usuario y nodo podían viajar juntos y firmar una misma petición. El destino podía comprobar ambos principales, en vez de adivinar si el nombre local pertenecía a la persona esperada o al equipo que intermediaba.

El nombre global tampoco pretendía eliminar de inmediato las cuentas del sistema operativo. El RFC esperaba que cada host siguiera mapeando el principal remoto a una cuenta local, con reglas parecidas a .rhosts. El cambio se producía en la forma de autenticar al usuario antes de ese mapeo.

Un directorio que podía sacar certificados de circulación

La arquitectura vinculaba los nombres a claves mediante certificados firmados por autoridades de certificación. DASS asociaba la jerarquía de CA con la de nombres X.500: cada autoridad respondía por las claves de su parte del árbol, y certificados de parentesco o certificaciones cruzadas conectaban ramas distintas. Una CA comprometida podía suplantar nombres dentro de su ámbito; la estructura ayudaba a delimitar ese ámbito, no a evitar por completo el abuso.

Esa misma infraestructura podía mantener el estado de validez. La opción más ágil propuesta por DASS era que el servicio de nombres publicara solo certificados que no se hubieran revocado. Un verificador aceptaría la clave únicamente mientras el certificado siguiera presente. El RFC considera que el retraso podía ser casi inmediato, aunque reconoce demoras de propagación y caché.

La frase «casi inmediato» encierra una condición importante. Para que la retirada surtiera efecto, el verificador tenía que consultar una copia actualizada y confiar en ella. El propio documento señala que la disponibilidad de la autenticación quedaba limitada por la del servicio de nombres, y que la seguridad de la revocación dependía de la seguridad del mismo servicio. Si la copia local no recibía a tiempo la actualización, el certificado retirado podía seguir apareciendo como válido para esa consulta.

El directorio no era solo un lugar donde buscar una clave. Se convertía en el canal que decía qué claves aún debían aceptarse. Eso concentra una tarea delicada: publicar el estado, propagar cambios, controlar quién puede modificarlo y conservar coherencia entre réplicas. La verificación de la firma no sustituyó esa tarea.

La alternativa barata podía tardar meses

La otra opción era programar vencimientos y renovar los certificados antes de que expiraran. En el uso ordinario, el RFC esperaba duraciones cercanas a un año. Para evitar demasiadas operaciones de las CA y avisos constantes a los usuarios, los ciclos de renovación podían medirse en meses.

Ese intervalo reducía la carga de administración, pero complicaba una respuesta urgente. Si una clave se perdía o se copiaba, el certificado antiguo podía seguir siendo aceptado hasta su vencimiento, salvo que el sistema también aplicara la retirada mediante el directorio. La precisión del reloj importaba: el documento advierte que una hora incorrecta podía aceptar mensajes o certificados vencidos.

El RFC plantea así una tensión reconocible en el propio diseño, sin resolverla con una única regla universal. La expiración exige renovar con frecuencia y mantener el tiempo razonablemente correcto. La lista positiva en el directorio puede acelerar el retiro, pero convierte la disponibilidad y la integridad del servicio de nombres en parte de la seguridad del certificado. Una lista de revocación X.509 habría sido otra alternativa; DASS no la admitía en esa versión.

El árbol de nombres distribuía la confianza

Para entender quién podía publicar un certificado, hay que seguir la jerarquía. DASS no proponía que cada servidor conociera de antemano la clave de cada usuario. Una CA local podía certificar las claves de su directorio; certificados parentales y certificaciones cruzadas permitían verificar una cadena hacia otros dominios de nombres.

El diseño buscaba que una falla local no se convirtiera automáticamente en una falla global. La autoridad de una CA debía corresponder a la rama que administraba. La promesa era de contención, no de ausencia de riesgo: la autoridad comprometida todavía podía inventar identidades dentro del área que su certificado le permitía certificar.

Ese límite dependía de decisiones de estructura y de administración. Alguien tenía que validar la relación entre persona, nombre y clave en el registro inicial. Alguien tenía que operar cada CA y proteger sus claves. Y los servidores receptores debían recorrer el camino correcto. La criptografía permitía verificar firmas en una cadena; no certificaba que el proceso de alta hubiera sido fiable.

El problema de revocación también afecta a la delegación. DASS quería que un proceso pudiera llevar credenciales a un servicio remoto, para que este llamara a otro recurso sin pedir otra contraseña. La autorización delegada era limitada por tiempo, pero en esta versión no estaba reducida a los derechos mínimos de una tarea. Si el secreto seguía vigente, un servicio comprometido podía tener margen para actuar durante el intervalo restante.

El tiempo podía impedir o permitir el acceso

DASS usaba marcas de tiempo para limitar la repetición de mensajes firmados. El verificador rechazaba mensajes fuera de una ventana de minutos y conservaba los autenticadores recibidos para detectar copias. Esto evitaba algunos intercambios adicionales de un esquema desafío-respuesta, pero introducía requisitos distintos de los usados para revisar la fecha de un certificado.

La sincronización para detectar repeticiones debía ser más estrecha, y el reloj necesitaba avanzar de forma monotónica. Una diferencia excesiva podía descartar una petición auténtica; un retroceso podía permitir que volviera a aceptarse un mensaje expirado. El estado de los autenticadores recientes también debía sobrevivir lo suficiente para que reiniciar el servidor no reabriera la ventana de repetición.

La autenticación, por tanto, combinaba más que una clave y una firma. El verificador necesitaba un nombre, una cadena de certificados, estado de revocación actual, hora razonable, memoria anti-repetición y una regla local para decidir qué hacer con el principal autenticado. El fallo de cualquiera de estas partes podía cambiar la respuesta aunque el resto funcionara correctamente.

Lo que la fecha del RFC sí demuestra

RFC 1507 lleva la etiqueta Experimental y dice que no especifica un estándar de Internet. Su anexo propone encajar DASS con el Generic Security Service API. El RFC 1508 definía la interfaz general que podía apoyarse en distintos mecanismos; el RFC 1509 describía sus enlaces para C. El RFC 1510 documentaba Kerberos V5 y el RFC 1704, publicado en 1994, repasaba distintos sistemas de autenticación.

Ese conjunto refleja que en los primeros años de la década se escribían varias respuestas a la autenticación distribuida. No permite concluir que DASS se desplegara, que ganara frente a Kerberos o que desapareciera por una carencia concreta. El estado del documento mide su posición normativa cuando se publicó, no las decisiones posteriores de cada operador.

La idea que deja el RFC 1507 es más acotada: una identidad portátil necesita un mecanismo para retirar claves antiguas. Si el retiro se apoya en el directorio, ese directorio pasa a formar parte del plano de seguridad. Si se apoya solo en la expiración, la rapidez de respuesta queda limitada por la duración del certificado. DASS nombró las dos opciones y expuso el precio de cada una.

Fuentes