Кратко

  • RFC 9963 выделяет три значения *_legacy, чтобы сервер TLS 1.3 мог явно запросить RSASSA-PKCS1-v1_5 у клиентского сертификата, который не способен создать совместимую подпись RSASSA-PSS.
  • Исключение ограничено клиентским CertificateVerify: оно не применяется к CertificateVerify сервера и серверным сертификатам и по умолчанию должно быть отключено.

RFC 9963, авторами которой указаны David Benjamin и Andrei Popov, разбирает узкое трение при миграции. TLS 1.3 убрал RSASSA-PKCS1-v1_5 из CertificateVerify в пользу RSASSA-PSS. В RFC отмечается, что некоторое криптографическое оборудование на стороне клиента, в том числе отдельные TPM, может не создавать совместимую с TLS 1.3 подпись PSS. Поэтому стороны способны выбрать TLS 1.3 и столкнуться с отказом только тогда, когда сервер запросит сертификат клиента.

Ответ не в том, чтобы вновь сделать старую схему обычной. Документ определяет rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy и rsa_pkcs1_sha512_legacy. Эти значения определены только для подписи в клиентском CertificateVerify, а не для иных контекстов. Именно эта небольшая оговорка задаёт операционную границу: кодовая точка говорит, что конечная сторона может выразить в определённом сообщении, но название алгоритма не даёт каждому участнику TLS общего разрешения.

Правила согласования не дают исключению стать фоновым свойством. Клиент не должен объявлять эти значения в расширении signature_algorithms ClientHello и не должен принимать их в серверном CertificateVerify. Сервер, желающий поддержать клиента только с устаревшим ключом, может послать значения в CertificateRequest и принять одно в ответе клиента, но не может принять значение, которое не предлагал. Такой клиент может согласовать путь, если он предложен. Если ключ поддерживает PSS, клиенту не следует выбирать устаревший путь, хотя определить это не всегда практически возможно. Реализации должны отключать значения по умолчанию.

Граница для сервера также ясна. Описанная проблема миграции не относится к ключам сервера. Новые значения запрещены для серверных сертификатов, а PSS остаётся обязательным для серверов TLS 1.3 с RSA. Исключение не отменяет корректной реализации: необходимо соблюдать RFC 8017, использовать обязательный параметр NULL и корректное DER-кодирование; сервер обязан отклонять неподходящие подписи.

Следовательно, источники подтверждают только узкий вывод. Сервер и клиент могут намеренно согласовать маркированное исключение совместимости при заявленных условиях. Это не доказывает, что конкретный TPM, браузер, библиотека, организация или сервер его развернули; не удостоверяет отдельную сессию и не устанавливает общий результат безопасности. Профиль IETF связывает David Benjamin с RFC, а его открытый сайт даёт профессиональный контекст, но не свидетельствует о работающих системах третьих лиц.

Именно эта сдержанность делает проект полезным. Давление совместимости реально, но путь явен, направлен и по умолчанию закрыт. Оператор может сохранить потребность клиента, предложение сервера, согласованный результат и условие вывода из эксплуатации. Тогда кодовая точка остаётся точным инструментом протокола, а не заменой полной истории развертывания.

Sources