Кратко

  • RFC 5349 описывает ECC-сертификаты, подписи и ECDH для PKINIT и требует поддержку P-256 и P-384. Общий минимум снижает стоимость interoperability, но не доказывает, что конкретная кривая разрешена для любого workload или что реализация корректна.
  • При отказе KDC возвращает preference list в Kerberos error без integrity protection. Локальная политика клиента и KDC ограничивает retry; удалённая рекомендация не может сама расширить accept set.
  • Named curve, valid point, certificate, shared secret, authenticated reply, issued ticket и service access — отдельные receipts. Концентрационный риск можно управлять только при наличии инвентаря этих зависимостей.

Общая база убирает одни отказы и объединяет другие

Когда обе стороны обязаны поддерживать одинаковые named curves, переговоры становятся короче, тестовая матрица меньше, а шанс найти общую реализацию выше. Это практическая ценность требований P-256 и P-384.

Но «поддерживается всеми» не означает «безопасно во всех условиях». Общая библиотека может содержать одинаковую ошибку. Одна неверная policy deployment может охватить весь парк. Изменение внешней рекомендации требует найти каждую зависимую key и service.

RFC 5349 обсуждает опасение, что катастрофическая проблема широко используемой кривой затронет множество ключей. Он не утверждает, что это произошло. Вопрос governance состоит в готовности заменить общий компонент без потери контроля и доказательств.

Полезный инвентарь связывает curve, implementation version, key instance, certificate, KDC, assurance tier и service. Без него стандартный OID создаёт видимость управляемости, а blast radius остаётся неизвестным.

Diversity не является бесплатной страховкой

Custom или дополнительные curves могут уменьшить зависимость от одного параметра. Они также увеличивают число parser paths, validation rules, certificate combinations и failure modes.

Поэтому нельзя выбирать между uniformity и diversity как между моральными позициями. Нужно определить interoperability population, обязательный минимум, разрешённые исключения, expiry и проверенный migration path.

NIST SP 800-56A Rev. 3, SP 800-186 и FIPS 186-5 дают текущий зафиксированный контекст для key establishment, curve parameters и signatures. NIST объявил обновление SP 800-56A; это monitoring trigger, а не доказательство мгновенной недействительности текущей публикации. Таблица 2008 года не должна самостоятельно определять policy 2026 года.

Preference list была неподписанной подсказкой

Client предлагает ECDH public value и domain parameters в PA-PK-AS-REQ. Если KDC их не принимает, он возвращает error 65 и TD-DH-PARAMETERS в порядке своих заявленных предпочтений.

Kerberos error messages не защищены целостностью. Attacker может изменить set или order так, чтобы выбрать более слабый или не взаимно предпочтительный вариант.

RFC 5349 требует local policy обеих сторон. Wire list помогает обнаружить intersection, но не создаёт разрешение. Если client автоматически запоминает успешный retry и переносит его в allow-list, transient observation превращается в durable authority.

Audit должен хранить original offer, exact error digest, order, selected retry, local rule и authenticated outcome. Иначе последняя curve выглядит решением KDC, хотя список мог быть изменён.

Curve identifier не доказывает membership точки

После выбора параметров peer передаёт public point. Его нужно проверить как valid point на correct curve. RFC 5349 особенно подчёркивает это для long-term private ECDH key: повторные неправильные точки способны раскрывать информацию до компрометации ключа.

OID задаёт ожидаемую группу. Validation проверяет вход. Эти состояния нельзя сводить к curve_supported=true.

Риск также зависит от reuse. Nonce logic RFC 4556 допускает согласование повторного использования ECDH key. Разрешённый reuse, фактический reuse и безопасная point validation — три разных факта. Инцидент должен группировать события по private-key instance.

Shared secret не выдал доступ

После принятия KDC отвечает своим public value. Стороны вычисляют EC point и превращают x-coordinate в DHSharedSecret, затем продолжают PKINIT и Kerberos.

Одинаковый результат вычисления не доказывает certificate path, intended principal, freshness, правильный realm, authenticated KDC reply, issuance of ticket, service authorization или user session.

Нужно фиксировать последовательность: parameter allowed, certificate validated, point valid, secret derived, KDF selected, reply authenticated, ticket issued, service authorized, session established. Финальная зелёная строка не должна ретроспективно окрашивать все предыдущие шаги.

Certificate уменьшает configuration surface

RFC 5349 допускает использовать ECC parameters из client или KDC certificate, избегая отдельной preconfiguration. Это полезно для consistency.

Но certificate всё ещё требует path, usage, validity и principal checks. Curve требует local acceptance. Session point требует validation. Authenticated parameter source не равен universal permission.

Agility повторяет границу политики

RFC 8636 позже вводит PKINIT algorithm agility. Отсутствующий KDF field может означать legacy KDC или downgrade; локальная политика решает, продолжать ли ради совместимости.

Зафиксированный в 2026 году post-quantum PKINIT draft снова использует hints и retries. Он остаётся Work in Progress и не является доказательством нормативного или deployed поведения. Но он подтверждает долговечность вопроса: discovery должно быть отделено от authorization.

Informational RFC не является census

RFC 5349 не Internet Standard и не обзор текущих сетей. IANA registry показывает assignments, не adoption. Пакет не доказывает vendor behavior, prevalence или named incident.

Minimum Initial Specification Лу Хэна используется как поздняя раскрытая аналогия: общий слой задаёт минимальный язык, а будущий выбор остаётся у участника. Reality Layers отделяет identifier, document preference, cryptographic result и operational access. Эти заметки не были источником RFC.