Кратко

  • OpenPGP Key ID — 64-битная подсказка для поиска, у которой возможны коллизии; сама по себе она не определяет единственный пакет открытого ключа или его владельца.
  • Проверяемая квитанция сохраняет всех кандидатов, выбранный пакет и полный отпечаток, происхождение, сертификаты, состояние ключа, криптографический результат и отдельное решение о полномочиях.

Система получила подпись, извлекла шестнадцать шестнадцатеричных знаков и нашла одну запись. Журнал зафиксировал: ключ определён. Но в нём не осталось ответа на самый простой вопрос — запись была единственной или интерфейс просто не показал остальные?

Короткий идентификатор полезен именно как сокращение пространства поиска. Ошибка возникает позже, когда эта подсказка получает статус уникального ключа, затем превращается в доказательство личности, а зелёный результат проверки — в служебное полномочие.

Jon Callas участвовал в создании прежних спецификаций OpenPGP. Его профиль IETF перечисляет пять RFC, включая RFC 2440 и RFC 4880. Биография ACLU описывает работу в криптографии, разработке и дизайне; упомянутые должности являются историческим контекстом, а не подтверждением нынешнего места работы. Действующая RFC 9580, заменившая RFC 4880, написана другими авторами.

Проекция длиной восемь октетов

RFC 4880 задаёт Key ID как восемь октетов и прямо предупреждает: реализация не должна считать такие идентификаторы уникальными. Для RSA-ключа версии 3 берутся младшие 64 бита модуля; для версии 4 — младшие 64 бита отпечатка.

Нынешняя RFC 9580 сохраняет и длину, и предупреждение. Версия 4 использует младшую часть SHA-1-отпечатка, а версия 6 — старшую часть SHA-256-отпечатка. Поэтому одинаковое название поля без номера версии скрывает различное происхождение значения.

Разные большие объекты способны попасть в одну 64-битную проекцию. Такая коллизия не равна взлому криптографии и не обязательно означает атаку. Это неоднозначность обнаружения. Она становится уязвимостью процесса, когда API возвращает только первый результат, кэш индексирует записи лишь по Key ID или импорт заменяет прежнего кандидата новым.

Версия входит в доказательство ещё по одной причине. Одно и то же математическое содержимое RSA, оформленное как ключ версии 3, 4 или 6, может получить разные отпечатки и Key ID. Короткое значение не является постоянным именем математического ключа вне пакетного контекста.

Полный отпечаток доказывает пакет, но не биографию

Полный отпечаток гораздо точнее связывает проверку с конкретным сериализованным пакетом открытого ключа. Его можно вычислить локально и сравнить с ожидаемой величиной машинным способом; вероятность коллизии намного ниже, чем у 64-битного фрагмента.

RFC 9580 при этом сомневается в надёжности ручного чтения и сравнения длинных отпечатков. Практический вывод — передавать ожидаемый отпечаток по аутентифицированному каналу и сравнивать автоматически, а не возвращаться к сокращению. В квитанции нужно указать, пришёл ли эталон из управляемой конфигурации, подписанного каталога, независимого канала или изменяемой страницы. Точное совпадение с неверным эталоном остаётся ошибкой.

Связь с человеком устанавливается отдельно. Пакет User ID содержит текст UTF-8 — обычно имя и электронный адрес, — но формат не проверяет его правдивость. Сертификационные подписи описывают привязку с разной силой: generic ничего не говорит о тщательности проверки, persona прямо не заявляет проверку, casual и positive обозначают более строгие уровни.

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

Верная подпись не назначает ответственного

Подпакет Issuer Key ID в подписи остаётся восьмибайтовой подсказкой. RFC 9580 запрещает применять его к ключам новее версии 4 и рекомендует включать Issuer Fingerprint во все подписи. Если для версии 4 присутствуют оба значения, Key ID должен совпасть с младшими 64 битами отпечатка. Такая согласованность полезна, но не отменяет разрешение полного пакета.

Криптографическая операция отвечает на узкий вопрос: проверяется ли эта подпись этим ключом над этими точными байтами? Истечение срока, отзыв, релевантный момент, допустимые алгоритмы и key flags оцениваются отдельно. Техническая способность подписать не является универсальным разрешением.

Организационные полномочия приходят из другой системы. Корректная подпись манифеста не доказывает, что владелец ключа сейчас отвечает за выпуск, что манифест описывает правильный объект или что политика разрешает публикацию. Владение ключом, сертифицированная личность, актуальная роль и право на конкретное действие — четыре разных звена.

Квитанция, не скрывающая неопределённость

Сначала сохраняются точные подписанные данные и пакет подписи. Issuer Key ID остаётся подсказкой, а в журнал попадают все кандидаты из каждого источника. Для выбранного ключа хранятся полный публичный пакет, его версия, локально рассчитанный отпечаток, источник и время получения.

Затем отдельно записываются проверяемый User ID, цепочка сертификации или правило доверия, срок и отзыв на нужный момент, key flags, алгоритмическая политика и итог криптографической проверки. Только последняя стадия принимает внешнее решение, вправе ли подписавший совершить требуемое действие.

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

Источники