Resumen

  • La política actual de Mozilla separa el mantenimiento del almacén de raíces y el aseguramiento periódico de las prácticas de validación que una AC debe aplicar antes de incluir datos en un certificado.
  • Ni una política ni una auditoría de período reconstruyen una solicitud determinada, una observación de validación, una emisión, un estado posterior de revocación o un resultado de cliente.

La versión 3.1 de Mozilla Root Store Policy, efectiva desde el 1 de julio de 2026, reúne varias afirmaciones verdaderas sin convertirlas en sinónimos. Mozilla distribuye certificados de AC con bits de confianza para fines específicos. Exige ciertas auditorías antes de la inclusión y al menos anualmente después para raíces e intermedias técnicamente capaces dentro de su alcance. También exige verificar con fuente independiente o canal alternativo la información que un suscriptor aporta antes de incorporarla al certificado.

Para certificados TLS, la AC debe asegurar autorización sobre dominios y control de direcciones IP mediante métodos documentados.

Cada afirmación es relevante. Ninguna sirve de comprobante automático de las demás.

Una auditoría tiene una frontera de aseguramiento: sistema cubierto, criterios, período, métodos, evidencia probada, hallazgos y límites. La política exige información de auditoría de período actualizada al menos cada año. Para períodos anuales que comiencen el 1 de julio de 2027 o después, exige además un Detailed Controls Report para determinadas AC con bit de confianza web. El informe se orienta a límites del sistema, controles, implementación, pruebas y eficacia operativa. Es evidencia de gobernanza valiosa; no es un registro de cada solicitud de certificado ni la prueba contemporánea de una sola emisión.

La diferencia se ve al mirar un certificado. Número de serie, emisor, vigencia y nombres alternativos describen un objeto. No muestran qué solicitud llegó, qué versión de procedimiento regía, qué persona o control automatizado tenía autoridad, qué fuente independiente se consultó, si la observación aún estaba dentro de su ventana permitida, ni por qué se vinculó esa clave a esos nombres. Una opinión de auditoría no crea esos enlaces ausentes solo por haber sido emitida por un auditor competente.

La sustitución inversa también falla. Un registro de emisión puede acreditar que se creó un objeto, pero no que todo el entorno de controles funcionó a lo largo de un período, que todas las ubicaciones estaban cubiertas, que no existió un hecho posterior, o que cada distribución derivada mantuvo el mismo tratamiento de raíces. La propia política de Mozilla indica que quienes distribuyen software basado en el suyo pueden añadir, retirar o cambiar certificados y bits de confianza. La política gobierna el conjunto predeterminado distribuido por Mozilla, no toda versión imaginable.

Tampoco emitir equivale a aceptar después. La documentación de NSS diferencia bloques de certificado y de confianza; una raíz es el certificado junto con sus ajustes de confianza. El cliente todavía debe construir y evaluar una cadena con su software y condiciones locales. Nombre de host, hora, extensiones, cadena, información de revocación, uso de aplicación y servicio observado al conectar son preguntas distintas. No es una acusación contra ningún cliente; es un límite a lo que un archivo de auditoría o emisión puede demostrar sin evidencia del cliente.

La respuesta práctica es un recibo de evidencia de emisión acotado. Debe conservar protegidos un identificador de solicitud; nombres pedidos y huella de la clave; versión de la regla y procedimiento; actor autorizado o control automático; observación independiente y ventana temporal; y luego serie, emisor, vigencia, extensiones relevantes e instante de emisión. La revocación posterior debe guardarse aparte con hora de consulta y contexto de respuesta. El resultado del cliente debe conservarse de nuevo por separado, con versión, nombre de host, cadena y hora, sin acumular datos innecesarios del usuario.

No se propone publicar pruebas de control de dominio, expedientes de clientes ni detalles defensivos. Se propone no usar una afirmación como sustituto de otra. La evidencia sensible puede revisarse con autoridad adecuada. Lo duradero debe ser el mapa de enlaces: qué decisión respaldó qué objeto, bajo qué regla y qué observación posterior se invoca realmente.

Límites de la evidencia

Las fuentes no identifican una AC, suscriptor, certificado, opinión de auditoría, DCR, incidente ni evento de parte confiada. No prueban incumplimiento alguno. El recibo propuesto es análisis editorial, no requisito de Mozilla, CA/Browser Forum, NSS o RFC.

Fuentes

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS: Updating NSS’s Root Store
  3. RFC 5280