Resumen

  • La pull request 679 añadiría ML-DSA-44, ML-DSA-65 y ML-DSA-87 a los TLS Baseline Requirements y regularía claves, firmas, certificados de CA y suscriptor, CRL y respuestas OCSP.
  • El texto declara que no obliga a ningún root store a confiar en ML-DSA ni modifica el algoritmo con el que un log firma los SCT. Entre sus beneficiarios incluye clientes basados en SDK, sistemas integrados e IoT, middleware y aplicaciones que usan almacenes del sistema operativo.
  • La carta del SCWG cubre certificados TLS para servidores accesibles por Internet, pero la condición para votar como Certificate Consumer es producir software destinado a navegar la Web de forma segura. La condición del emisor también se prueba mediante aceptación en un navegador de esa clase.
  • La exclusión de PKI internas es explícita y limitada. No autoriza a afirmar que todo uso no Web está fuera, ni que cualquier cliente de una raíz pública está automáticamente representado.
  • Al corte del 2 de septiembre de 2026, SC-106 seguía siendo una PR Draft y no aparecía en la página oficial de ballots. Las intervenciones públicas son posiciones atribuibles, no una decisión del grupo.
  • Un recibo de mandato debe unir población destinataria, cláusula de carta, vía de representación, invariante técnico, límites de raíces y CT, prueba de ejecución, foro alternativo y revisión.

El sujeto de la necesidad no coincide con el sujeto del voto

La parte políticamente más importante de la PR 679 es una enumeración técnica. La propuesta sostiene que numerosas partes usuarias carecen de una vía práctica para obtener autenticación poscuántica dentro de la infraestructura X.509 de confianza pública. No se limita a decir “Internet”: nombra clientes de servicio construidos con SDK, equipos integrados e IoT, middleware empresarial y aplicaciones que dependen de almacenes de confianza administrados por sistemas operativos.

La carta constitutiva del Server Certificate Working Group construye la clase consumidora con otro criterio. Para votar como Certificate Consumer, una organización debe producir para el público un producto destinado a navegar la Web de manera segura, actualizarlo y documentar su uso de raíces y el cumplimiento de los BR. Para votar como Certificate Issuer, sus certificados deben ser aceptados por un navegador creado por un miembro consumidor.

No hay contradicción lógica en que una empresa de navegadores entienda también las necesidades de un sistema operativo o una biblioteca. Pero entender, participar y ser afectado son relaciones distintas de representar. En la doctrina de Lu Heng, una parte interesada puede aportar conocimiento, objeciones y disciplina técnica sin convertirse por ello en el mandante de quienes sufrirán el coste.

Por eso la propuesta necesita escoger públicamente una de varias descripciones. Puede ser un mínimo Web que además resulte útil fuera del Web. Puede ser una actividad auxiliar dentro de una carta centrada en navegación. Puede ser un perfil general de confianza pública para varias clases de software. Cada descripción tiene una base institucional y un alcance distintos.

El perfil congela decisiones concretas

El diff entre 92b8115… y eefc670… no es una declaración abstracta sobre ordenadores cuánticos. Incorpora los tres conjuntos de parámetros de FIPS 204, exige comprobar la codificación de las claves y establece el uso de firma digital en certificados de suscriptor. Los parámetros del identificador deben estar ausentes; HashML-DSA queda prohibido.

El borrador exige correspondencia entre la clave certificada y la firma. Una clave pública ML-DSA solo podría aparecer bajo una firma ML-DSA. Una firma ML-DSA de certificado o precertificado solo podría certificar una clave ML-DSA. La segunda prohibición no alcanza a CRL u OCSP porque esos objetos no certifican una clave pública.

Esa “pureza” no describe por sí sola la confianza obtenida. El propio preámbulo reconoce que un root program decide si acepta la jerarquía. También reconoce que el algoritmo de la firma SCT queda bajo control del operador de Certificate Transparency. Un perfil puede permitir a una CA emitir bytes conformes sin que ningún cliente de producción acepte la raíz o construya el camino.

La separación protege contra una inferencia demasiado grande, pero deja abierta la pregunta de necesidad. ¿Qué impide hoy al SDK o dispositivo citado avanzar: el BR, el programa raíz, la biblioteca, el almacén, el servidor, la negociación o el auditor? Ninguna fuente revisada cuenta implementaciones, mide el bloqueo o demuestra que todas requieren la misma regla de pureza.

“SC-106” era un nombre de proyecto, no un resultado

En GitHub, la propuesta estaba abierta, marcada Draft y formada por un solo commit. La página oficial del SCWG no la mostraba en votación, revisión IPR, discusión ni “Draft / Under Consideration”. Tampoco había un aviso público que fijara proponentes, endorsers o fechas.

La formulación responsable al 2 de septiembre es “pull request de borrador”. El hecho de que el título y el preámbulo usen la palabra ballot expresa la intención del autor, no el estado institucional.

La cadena procedimental añade autoridad por etapas: identidad inmutable del texto; inicio formal de discusión; denominadores y votos de ambas clases; resultado; revisión IPR; versión final y fecha efectiva. Después llegan las decisiones de emisión, raíces, CT y clientes. El primer commit no puede heredar todas esas autoridades por anticipado.

Este límite no vuelve inútil el borrador. Al contrario, su comparación inmutable permite saber qué restricciones se debatían y distinguirlas de cualquier versión futura.

La carta contiene una amplitud y una estrechez reales

Quien quiera demostrar que el SCWG es únicamente un club de navegadores tendrá problemas con la sección de alcance. Esa sección autoriza requisitos para emitir y gestionar certificados TLS que autentican servidores accesibles desde Internet, cambios para amenazas emergentes y actividades auxiliares. La función técnica no se reduce a una marca o a una interfaz de navegador.

Quien quiera demostrar que cualquier uso TLS pertenece al SCWG tendrá problemas con las definiciones de voto. La clase consumidora está expresamente vinculada a navegar la Web. La clase emisora se califica mediante aceptación en un navegador. La autoridad para decidir y el universo que puede reutilizar un certificado no son coextensivos.

El párrafo fuera de alcance excluye PKI de empresas que operan solo para fines internos cuando la raíz no se distribuye por ningún Certificate Consumer. También excluye usos primarios como S/MIME y firma de código. Esa redacción deja espacios intermedios: una aplicación no navegador puede usar una raíz del sistema, y una infraestructura no puede convertirse sin más en “Web” porque su servidor sea alcanzable.

La conclusión probatoria es una tensión interpretativa. No una infracción. Una decisión colectiva debería citar la cláusula que autoriza el perfil, el órgano que resuelve la interpretación y el tratamiento dado a los usuarios sin voto propio.

La discusión de Tokio sigue sin cierre

Las actas de la reunión presencial 64, celebrada en marzo de 2025, contienen una sección completa sobre el alcance de los TLS BR. Allí aparecen exactamente los problemas que SC-106 vuelve visibles: navegadores frente a otros consumidores, sistemas operativos, conexiones servidor-a-servidor, PKI privadas, agilidad y la posibilidad de otro working group.

Una perspectiva ligaba los BR a la realidad de las raíces de navegador y advertía que los usos menos ágiles podían frenar el Web. La otra señalaba que las mismas raíces sirven a aplicaciones y plataformas, que esos usuarios no tienen otro estándar reconocido y que separar certificados puede fragmentar la operación.

Las actas resumen las dos perspectivas sin resolverlas. No son una enmienda de carta. Sí son evidencia de conocimiento previo: el grupo sabía que la definición del consumidor y la base instalada no coincidían perfectamente.

La PR de 2026 reproduce la disputa. Un participante calificó los casos centrales como no WebPKI. Ben Wilson sostuvo que la seguridad depende del camino que la parte usuaria construye y acepta, y que una ruta clásica alternativa no degrada matemáticamente otra ruta completamente poscuántica. Una intervención posterior de un participante de Chrome separó dos direcciones de cadena mixta, cuestionó la competencia del SCWG para los casos no Web y sugirió un nuevo grupo.

Ninguna de esas voces es el Working Group. Sus comentarios son pruebas de desacuerdo y propuestas de diseño, no votos.

Dos direcciones mixtas, cinco propietarios

La discusión técnica no puede comprimirse en “cadena mixta sí o no”. Una CA clásica que firma una clave de suscriptor ML-DSA introduce objetos grandes debajo de una raíz ya atendida por logs clásicos y deja la autoridad final en una firma clásica. Una CA ML-DSA que firma temporalmente una clave clásica puede servir a una transición y a una señal contra downgrade. Las consecuencias de CT, el camino y el cliente son distintas.

RFC 5280 establece el marco mínimo: el camino prospectivo y la información del trust anchor son entradas de la validación. Elegir el ancla es una política local. Pueden existir caminos diferentes para el mismo objetivo. El perfil de emisión controla lo que la CA crea; el relying party controla qué camino acepta.

Eso no impide que un requisito común prohíba una construcción. Obliga a nombrar el invariante. Puede ser limitar la carga de CT en el Web, asegurar que una etiqueta “PQ” corresponda a todas las firmas del camino aceptado, o impedir un downgrade en una fase determinada. Cada objetivo tiene dueño, población y prueba distintos.

Además, el certificado, el root store, el log, la biblioteca y el servidor no son un solo sistema. Una regla que intenta controlar los cinco sin registrar la frontera termina atribuyendo a un documento una capacidad que solo existe en la ejecución conjunta.

La realidad de Chrome es plural y acotada

La hoja de ruta de Chromium diseña una migración del Web en etapas. Incluye negociación de certificados, credenciales paralelas, protección contra downgrade y una fase lejana en la que desaparezcan las opciones clásicas. Para la confianza pública, Chrome está probando Merkle Tree Certificates, no una sustitución inmediata por X.509 tradicional con ML-DSA.

Las instrucciones del Chrome Quantum-resistant Root Program separan incluso el ensayo de la producción. Chrome 150 admite certificados ML-DSA tradicionales en jerarquías privadas. El almacén MTC de prueba se habilita aparte y etiqueta sus cosigners como no confiables para validación de producción. El programa define sus propios requisitos de mirroring, logs y algoritmos.

Ese diseño no representa a Mozilla, a un sistema operativo ni a un dispositivo. Sirve como evidencia de que la innovación no espera una única declaración universal. Existen perfiles y conjuntos de compatibilidad distintos, cada uno con señal y límites.

FIPS 204 aporta la definición criptográfica. El BR propuesto aportaría la forma de un certificado. Un programa raíz aporta la confianza. CT aporta transparencia. La biblioteca aporta construcción y validación. El despliegue aporta resultados. Confundir esos verbos transforma estandarización en soberanía técnica.

Qué debe contener el recibo

Primero, identidad y procedimiento: base, commit, estado, proponentes y endorsers cuando existan, ventanas, votos, IPR, versión final y fecha. Segundo, población: navegador, validador del sistema, SDK, equipo integrado, IoT, middleware, PKI privada y servicio público, sin esconderlos bajo una etiqueta única.

Tercero, autoridad: cláusula de la carta, responsable de interpretarla, clase con voto y vías de participación de las demás. Cuarto, invariante: codificación, fuerza del camino, downgrade, capacidad CT y admisión de raíces en filas separadas.

Quinto, evidencia: vectores de prueba, librerías, tamaños, rutas, pilotos y fallos por versión. Sexto, opciones institucionales: SCWG con interpretación publicada, modificación de carta, nuevo grupo o perfiles locales. Séptimo, reversibilidad: fecha de revisión, umbral de adopción y mecanismo para retirar una prohibición transitoria.

El recibo no convierte el proceso en referéndum mundial. Hace más modesta la afirmación: “este órgano decidió esta regla para esta población y dejó estas otras decisiones a sus propietarios”.

Límites de la evidencia

No hay resultado de ballot, guideline efectiva o compromiso de root store. No hay decisión colectiva sobre la carta. No hay censo de SDK, dispositivos o middleware. No hay prueba de que CT falle con un volumen definido ni de que un camino mixto concreto esté desplegado públicamente.

Tampoco hay base para llamar a la propuesta ilegítima o innecesaria. Un borrador puede descubrir un problema real. La precisión exige no convertir esa posibilidad en autoridad ya concedida.

La ventana útil es ahora. Antes de que auditores y compradores citen SC-106 como “estándar de la industria”, el Forum puede dejar visible qué necesidad, qué cláusula y qué implementación lo sostienen.

Un mandato explícito preserva más innovación

Si el SCWG considera suficiente su mandato sobre servidores Internet, puede explicarlo y limitar el alcance representativo. Si la prioridad son clientes no Web con restricciones distintas, un grupo separado puede darles una voz más adecuada. Si los root stores ya pueden pilotar, la regla común puede esperar evidencia.

Ninguna opción es una derrota. La derrota sería que el lugar del documento decidiera el mandato sin que nadie lo registrara.

SC-106 ya reconoce que permiso, confianza y firma de SCT son cosas distintas. Su siguiente mejora debería reconocer que beneficiario y elector tampoco son sinónimos.

Fuentes

  1. Lu Heng, «The Multi-Stakeholder Mirage»
  2. Lu Heng, «Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption»
  3. CA/Browser Forum, pull request 679 — SC-106
  4. Comparación inmutable de SC-106
  5. TLS Baseline Requirements propuestos
  6. Carta del Server Certificate Working Group
  7. Actas de la reunión presencial 64 del SCWG
  8. Bylaws del CA/Browser Forum
  9. Estado de ballots del SCWG
  10. NIST FIPS 204
  11. RFC 5280, sección 6
  12. Chromium, hoja de ruta de autenticación HTTPS poscuántica
  13. Instrucciones de prueba del Chrome Quantum-resistant Root Program