Resumen

  • draft-ietf-tls-trust-anchor-ids-06 propone identificadores compactos para orientar qué ruta de certificados presenta un par TLS, sin convertir la lista del cliente en una declaración completa de confianza.
  • El cliente puede omitir anclas aceptadas, anunciar otras que no acepta o usar grupos mixtos. Si la primera ruta falla, el servidor puede anunciar anclas disponibles y permitir como máximo un nuevo intento dirigido.
  • La organización necesita recibos separados para la señal, el inventario, la selección, la validación, la recuperación, la privacidad y el resultado de servicio.

La escena empieza después de un rechazo. El servidor tenía varias rutas de certificados y eligió una que coincidía con el identificador enviado por el cliente. La cadena llegó completa. Sin embargo, la validación local la descartó. En EncryptedExtensions, el servidor había anunciado qué anclas individuales podía servir. El cliente encuentra una que sí acepta, abre otra conexión y esta vez solicita solo ese identificador.

El segundo handshake puede tener éxito. Lo importante es entender qué cambió: no se añadió una autoridad al almacén de confianza y no se relajó una regla. La segunda solicitud eliminó incertidumbre de la selección. La política que rechazó la primera ruta siguió intacta.

Esa es la frontera central de la revisión 06 del borrador del grupo de trabajo TLS de la IETF. El documento fue actualizado el 30 de septiembre de 2026. Su cabecera apunta a Standards Track, aunque el registro de Datatracker capturado para este análisis mantiene nulos intended_std_level y std_level. Sigue siendo un Internet-Draft, no un RFC. Las fuentes describen una propuesta; no demuestran despliegue, adopción ni interoperabilidad.

Una lista útil precisamente porque no es un juramento

TLS asocia una clave con identidades de aplicación mediante certificados X.509. El servidor puede disponer de varias cadenas válidas en contextos distintos. Para ayudarle a elegir, el cliente ya puede enviar nombres de autoridades en certificate_authorities, pero la enumeración puede ser voluminosa. El borrador añade Trust Anchor IDs cortos, individuales o agrupados.

El cliente envía una RequestedTrustAnchorList sin orden en ClientHello o CertificateRequest. Puede dejarla vacía. También puede omitir una raíz que sí confía, incluir una que no confía o anunciar un grupo que contiene ambas clases. Puede hacerlo para limitar el tamaño del mensaje o para evitar que una lista exacta identifique al dispositivo o al usuario.

La lista no pretende certificar el contenido del almacén local. Su función es aumentar la probabilidad de que el servidor elija una ruta aprovechable. El servidor asocia metadatos a cada cadena: el identificador individual del ancla emisora y los patrones de grupos que la contienen. Compara esos datos con la solicitud y selecciona un candidato. Si también recibió certificate_authorities, el borrador permite guiarse por cualquiera de las dos extensiones. Si no hay coincidencia, puede fallar con handshake_failure o recurrir a un certificado alternativo.

Después llega la decisión soberana. El cliente verifica el ancla real, la identidad esperada, la vigencia, los algoritmos, las restricciones y sus demás requisitos. Una coincidencia de identificador no sustituye RFC 5280 ni la política de la aplicación. Si los metadatos del servidor son erróneos, el resultado puede ser un fallo. Si la lista del cliente era deliberadamente imprecisa, también. En ninguno de los dos casos una cadena no confiable se vuelve confiable.

Ordenar la cadena no equivale a aprobarla

Cuando el certificado seleccionado coincide con un identificador solicitado, el servidor puede incluir una extensión trust_anchors vacía en Certificate. El gesto obliga a entregar una lista completa, en el orden correcto y sin certificados ajenos. El cliente puede tratarla como una ruta preconstruida y evitar la búsqueda de caminos alternativos.

RFC 4158 expone la complejidad de construir rutas en un grafo. RFC 5280 define el trabajo de validarlas. La extensión estricta puede reducir el primero; no cancela el segundo. Una cadena perfectamente ordenada todavía puede terminar en un ancla no autorizada o violar una restricción.

Por eso el recibo de producción necesita dos momentos distintos: la ruta se eligió por la coincidencia X y la política Y validó o rechazó esa ruta por la razón Z. Un panel que solo registra el certificado servido atribuye al servidor una decisión que pertenece al cliente.

La recuperación tiene una factura

Para corregir una primera selección fallida, el servidor puede enviar en EncryptedExtensions una lista no vacía de identificadores individuales disponibles, ordenada según su preferencia. Tras rechazar el certificado, el cliente busca una intersección con las anclas que realmente acepta, combina su preferencia con la del servidor e inicia una nueva conexión solicitando solo una.

El borrador limita el proceso a un reintento. Si no recibió la lista, no encuentra una coincidencia confiable o vuelve a fallar, entrega un error a la aplicación. La limitación evita un ciclo de tanteos, pero deja un coste claro: otra conexión y más latencia.

Durante una transición de CA, un operador podría dar prioridad a una cadena nueva y conservar otra más extendida como respaldo. Los clientes actualizados entrarían directamente. Los rezagados podrían recuperar con la segunda conexión. Ese patrón permite avanzar sin afirmar que toda la población ya confía en la nueva raíz. A la vez, obliga a medir el percentil alto de latencia, no solo la tasa agregada de handshakes.

Grupos, preferencias y desacuerdo

Un grupo comprime varios identificadores. No garantiza que el cliente confíe en todos sus miembros. Tampoco garantiza que dos implementaciones mantengan la misma definición en el tiempo. La asignación, versión y retirada de grupos se convierte en una dependencia de coordinación. Un mapa obsoleto no amplía la confianza, pero puede dirigir el tráfico hacia una cadena que falla de forma constante.

Las preferencias también pueden divergir. El servidor ordena las anclas disponibles según sus costes, capacidad o estrategia de transición. El cliente puede preferir otra por seguridad o política. La recuperación debe dejar constancia de cómo se resolvió esa intersección. “Había una ancla común” no explica por qué ganó una sobre otra ni quién asumió la latencia.

La selección de una CA por el servidor tampoco es una aprobación institucional. Es el resultado de inventario, metadatos y preferencias dentro de una conexión. Convertirlo en una señal reputacional confunde coordinación técnica con legitimidad.

Dos formas de ser observado

El borrador diferencia clientes que nunca anuncian la extensión, que la anuncian de forma condicional o que lo hacen siempre. La lista condicional suele requerir una sonda activa para ser observada. La lista incondicional puede capturarse pasivamente. Si es exclusiva de un usuario, se convierte en una huella estable.

La recomendación es no enviar una lista incondicional única y usar, cuando corresponda, una lista común a un conjunto de anonimato. Incluso así, una lista derivada de conexiones previas puede correlacionar sesiones. La privacidad depende de cuándo se emite, cuántos clientes comparten el patrón y qué estado histórico intervino; no solo del número de bytes.

El servidor también debe filtrar su lista de disponibilidad por el servicio solicitado, incluido el contexto SNI. Enumerar todas las anclas de una plataforma compartida revela relaciones que el cliente no necesita conocer. Las anclas sensibles no deberían entrar en este mecanismo.

Siete pruebas para una sola conexión

Una implementación mínima y verificable separa siete superficies. La primera es la política de señal: lista exacta, grupos, condición de emisión y regla de anonimato. La segunda es el inventario de rutas: cadenas realmente disponibles y versión de sus metadatos. La tercera es la selección y el respaldo: qué coincidió, cómo se ordenó y qué ocurrió sin coincidencia.

La cuarta es la validación local, cuya autoridad no puede delegarse al selector. La quinta es la recuperación, con la lista disponible, el único reintento y su coste. La sexta es la privacidad, incluido el filtrado por servicio y el estado previo utilizado. La séptima es el resultado: cadena presentada, motivo de rechazo, desenlace TLS y efecto visible para la aplicación.

Ese recibo permite que distintos equipos cooperen sin fingir una política común. También conserva el principio más valioso del borrador: una mejor coordinación no exige centralizar la decisión de confianza.

Fuentes