Jerarquía de autoridades y raíz fuera de línea

Una PKI empresarial suele tener dos o tres niveles. Arriba está la raíz: su certificado se instala como ancla de confianza en cada consumidor (terminales, servidores, portátiles). Debajo, las intermedias, que son las que emiten todos los días. El perfil de certificado de internet que fija el RFC 5280 da las herramientas para encadenarlas: la extensión de restricciones básicas dice si un certificado puede actuar como autoridad y cuántos niveles puede tener debajo, y la de restricciones de nombres limita para qué dominios puede emitir una intermedia.

La razón de los niveles es el radio de impacto. Si una intermedia se compromete, la raíz la revoca y se emite otra; los consumidores no cambian nada porque siguen confiando en la misma raíz. Si se compromete la raíz, no hay nadie por encima que la revoque: hay que retirar el ancla de cada consumidor y poner otra. En una cadena de supermercados eso significa tocar miles de cajas.

Por eso la raíz se guarda fuera de línea: un equipo sin red, su clave en un módulo de hardware que solo se activa con varias personas presentes, y un uso limitado a ceremonias con acta. En ellas firma intermedias y su propia lista de revocación. Separar las intermedias por población (tiendas, servicios, personas) añade otra frontera: un problema en una no obliga a tocar a las otras.

El documento de diseño dice qué puede firmar cada autoridad. El acta de cada ceremonia dice qué firmó de verdad. El arquitecto lee las dos y busca la diferencia, porque una excepción hecha en una ceremonia queda viva durante toda la vida del certificado.

Un certificado de entidad final (un servidor, un dispositivo) emitido directamente por la raíz es una mala idea por partida doble. Solo se puede revocar en la lista de la raíz, que se publica una vez al año. Y quien confía en él lo hace sin la frontera de una intermedia, así que su clave queda tan protegida como la de un servidor cualquiera, no como la de la raíz.

Abre el laboratorio y compara autoridades.txt con registro-de-la-raiz.txt.

Toda lista de revocación lleva una fecha de próxima actualización. Pasada esa fecha, un validador que comprueba la cadena completa ya no puede saber si alguna intermedia fue revocada, y si está configurado para rechazar ante la duda, rechaza. Con una raíz en línea, la lista se renueva sola. Con una raíz sin red, cada lista nueva exige una ceremonia, y la vigencia de la lista tiene que cubrir el tiempo entre ceremonias con margen.

Es el precio de la raíz fuera de línea, y no se paga con dinero sino con calendario: alguien tiene que agendar la ceremonia, las custodias tienen que estar disponibles y el equipo tiene que estar en la caja fuerte. Si una de esas cosas falla, la medida que protegía la raíz se convierte en un apagón.

Lee ceremonias.txt y compara la fecha en que vence la última lista con la fecha de la próxima ceremonia.

La ceremonia no se aplazó por descuido: se aplazó porque el quórum exige a las dos únicas custodias. Un esquema de M de N (por ejemplo, dos de tres) mantiene la regla de que nadie activa la raíz solo y a la vez tolera una ausencia. Se completa con una ceremonia de fecha fija, agendada con margen antes de que venza la lista.

Las salidas fáciles debilitan la raíz o la revocación. Conectar la raíz a una red para publicar su lista sin ceremonia la expone todo el año. Alargar mucho la vigencia de la lista tiene un costo menos visible: los validadores no vuelven a descargarla hasta que vence, así que la revocación urgente de una intermedia tardaría años en llegarles.