Mozilla

Un informe anual de aseguramiento puede mostrar que se examinaron los controles de una autoridad de certificación durante un período delimitado. Por sí solo no contesta la pregunta más concreta que puede importar a quien confía: por qué se emitió este certificado, para este nombre y esta clave, en ese momento, y qué ocurrió después cuando un cliente lo encontró.

La documentación pública de Mozilla separa actuaciones que se suelen comprimir en una palabra: un responsable o par de módulo puede aprobar un cambio para ese módulo; una persona puede recibir acceso a un repositorio; un cambio puede integrarse; y Firefox puede llevarlo, o no, hacia un canal público. La relación entre esos pasos no autoriza a usar cualquiera como prueba de los demás.

El cambio más importante de SC101 cabe en una secuencia: elegir el método de validación, seguir el CNAME cuando ese método lo permita y solo después eliminar etiquetas. Sin embargo, la propia versión que consagra ese orden deja abierta hasta el 15 de noviembre de 2026 la sección equivalente de la v2.2.7. Durante más de tres meses, «cumple los requisitos actuales» puede describir dos recorridos normativos distintos.

Mozilla inició la Public Suffix List y Firefox todavía convierte una de sus versiones en conducta del navegador. El DNS puede mostrar que `whatwg.github.io` está bajo `github.io`, pero no si dos subdominios pertenecen a una administración o a inquilinos que no se confían. Este artículo sigue los dos papeles acotados de Mozilla —iniciador e implementador posterior— para explicar cómo un registro comunitario adquiere autoridad de seguridad sin convertirse en propiedad de Mozilla.

La interrupción de complementos de Mozilla de mayo de 2019 mostró cómo un requisito de seguridad legítimo puede convertirse en una dependencia de disponibilidad de modo común cuando convergen el ciclo de vida del certificado, la recuperación remota, la privacidad y las salvaguardas de datos de usuario.