Кратко

  • В редакции 06 проекта TLS Trust Anchor Identifiers от 30 сентября 2026 года предельная длина двоичного идентификатора снижена с 255 до 32 байт; структура TrustAnchorID теперь допускает от одного до 32 байт. Документ остается рабочим Internet-Draft со статусом IESG I-D Exists, а не опубликованным RFC.
  • Дополненный раздел об реализации требует не путать корректный OID с пределами локального отображения: его отдельные компоненты могут быть сколь угодно большими, поэтому переполнение или искажение значения недопустимы. Подбор цепочки сертификатов и решение доверять удостоверяющему центру остаются разными действиями.

При смене корневого сертификата различие между клиентами неизбежно. Одни уже приняли новый корень, другие еще работают со старым. Сторона, предъявляющая сертификат, может подготовить несколько путей, но без сведений о доверии партнера ей трудно выбрать подходящий. Предлагаемое расширение trust_anchors передает компактные идентификаторы вместо длинного перечня имен в существующем механизме certificate_authorities. Оно помогает согласовать представление цепочки, но не меняет содержимое локального хранилища доверия у проверяющей стороны.

У редакции есть точная, проверяемая новость. Текст от 14 сентября разрешал двоичному ID занимать до 255 байт. Версия от 30 сентября установила предел 32 байта и заменила диапазон структуры TLS с <1..2^8-1> на <1..32>. Авторы объясняют, что теперь двоичная и десятичная запись с точками, относительная и полная, помещаются в удобную границу менее 255 байт. Это предел длины одного обозначения, а не ограничение числа доверенных УЦ, клиентов или доступных цепочек.

Есть и другой смысл слова «большой». Компонент внутри OID может обозначать огромное целое число даже при сравнительно короткой двоичной записи; такие числа встречаются и в шаблонах для групп якорей. Если реализация пытается преобразовать каждый компонент в целое фиксированной разрядности, результат может переполниться или сравниться не с тем значением. Новая редакция прямо запрещает ошибочную интерпретацию и неопределенное поведение. Она рекомендует сохранять байтовое представление: равенство идентификаторов и сопоставление с шаблоном можно определять, не декодируя каждый компонент в привычную локальную числовую форму.

Диагностические сообщения и текстовые файлы конфигурации все же могут требовать десятичную запись. Проект допускает ограничения для таких компонентов, но требует совместимой обработки корректных ID, которые локальное средство не поддерживает. Реализация TLS должна принимать ID с произвольно большими компонентами OID в предусмотренных сообщениях рукопожатия. Перед передачей другому модулю она может отбросить неподдерживаемый ID; если отброшены все ID в EncryptedExtensions, это равносильно отсутствию расширения. Локальное неудобство вывода не должно превращаться в другую политику доверия. Если пределы компонентов установлены, рекомендуется поддерживать по крайней мере значения до 2^32-1, то есть полный диапазон Private Enterprise Numbers, и выделять ID с учетом этой границы. Это рекомендация SHOULD, а не доказательство соответствия существующих программ.

В сравнении редакций видна и правка примера: для версионированной группы открытый максимум 2^64-1 заменен бесконечностью. Иллюстрация не свидетельствует об изменении действующего реестра CA. Рабочая группа продолжает обсуждать Internet-Draft; IESG пока не одобрил его как стандарт. Из текста нельзя вывести ни факт внедрения, ни уязвимость конкретного продукта, ни уже случившийся сбой проверки сертификатов.

Источники