Resumen

  • La versión 06 del borrador del grupo TLS sobre identificadores de anclas de confianza, fechada el 30 de septiembre, cambia el máximo de la representación binaria de 255 a 32 bytes. La estructura TrustAnchorID también queda limitada a entre uno y 32 bytes. El documento sigue siendo un Internet-Draft de grupo de trabajo, con estado I-D Exists ante el IESG; no es una RFC.
  • La versión añade instrucciones sobre componentes OID arbitrariamente grandes: evitar desbordamientos, comparar bytes cuando resulte posible y tratar de modo interoperable los identificadores válidos que un sistema local de texto no puede mostrar o configurar. La confianza final continúa dependiendo de la política de quien verifica el certificado.

Cuando una autoridad certificadora cambia de clave o una aplicación incorpora una raíz nueva, no todos los clientes siguen el mismo calendario. Quien presenta un certificado puede disponer de varias rutas de certificación, pero necesita saber cuál tiene posibilidades de ser reconocida por su interlocutor. El mecanismo trust_anchors propuesto en el borrador comunica identificadores compactos de las anclas aceptadas, en lugar de cargar siempre con nombres largos de autoridades. Es una ayuda para seleccionar una ruta candidata, no una votación sobre qué CA debe considerarse legítima.

El cambio verificable entre las ediciones del 14 y el 30 de septiembre es específico. El antiguo límite binario era de 255 bytes. La nueva versión lo fija en 32 y modifica la sintaxis TLS de <1..2^8-1> a <1..32>. Según el texto, así caben cómodamente bajo 255 bytes tanto las formas binarias como las representaciones decimales separadas por puntos, relativas o completas. Hablar de «32» sin decir que se refiere a la longitud de un ID induciría a error: el borrador no restringe a 32 el número de autoridades fiables ni el número de cadenas disponibles.

La revisión reconoce además que una etiqueta breve puede contener un componente OID cuyo valor matemático sea enorme. También los patrones usados para hacer coincidir grupos de anclas pueden manejar enteros grandes. La nueva sección de implementación prohíbe interpretar mal esos valores o generar un comportamiento indefinido por desbordamiento. Recomienda conservar los identificadores como secuencias de bytes: para comprobar igualdad o correspondencia no es imprescindible transformar cada componente en un entero del tamaño que admita el ordenador local.

El problema no es que el protocolo haya creado una autoridad nueva, sino que una conversión de formato pueda alterar la señal que transporta.

Los diagnósticos y archivos de configuración sí suelen necesitar números en forma textual. En esas partes, el borrador permite límites locales. A cambio exige que un ID válido pero no admitido por esa representación reciba un tratamiento interoperable. Las implementaciones TLS deben aceptar los identificadores con componentes OID de tamaño arbitrario en los mensajes de negociación señalados por el documento. Pueden descartar los que otra pieza del sistema no soporte antes de entregárselos; si se descartan todos los ID de EncryptedExtensions, el efecto equivale a que la extensión no estuviera presente. El borrador aconseja a quienes fijan un límite admitir como mínimo valores hasta 2^32-1, para cubrir el rango de números de empresa privados, y asignar identificadores dentro de esa capacidad. Esa recomendación no afirma que todos los productos la cumplan.

Hay otros retoques, entre ellos un ejemplo de grupo versionado cuyo máximo abierto deja de expresarse como 2^64-1 y pasa a infinito. Es un cambio de ejemplo, no una modificación observada en un registro de CA en servicio. La ficha del IETF todavía presenta el documento como borrador activo y no muestra aprobación final del IESG. Ni fallos concretos, ni ataques, ni implantación comercial pueden inferirse de esta comparación textual.

Fuentes