Кратко

  • Для digest, ECDSA, HMAC и HKDF с SHA3 RFC 9688 требует отсутствия параметров; для RSA PKCS#1 v1.5 с SHA3 — обязательный NULL; для KMAC форма зависит от точной настройки S.
  • Успех parser, распознанный OID или действительная подпись не доказывают сохранность исходных байтов, выбранный путь исполнения, сертификатную политику, полномочие и итог приложения.

Представим архив, который проверил входной SignedData, разобрал ASN.1 и сохранил новую сериализацию. На обоих этапах интерфейс показывает RSA with SHA3-256. Но новая библиотека удалила обязательный NULL. Имя осталось, а объект изменился.

Это аналитический пример, не утверждение о конкретном продукте. Он показывает, где заканчивается OID. Номер координирует алгоритм, но не хранит роль поля CMS, состояние параметров, вложенный идентификатор, входные байты, ключ, реализацию, политику и решение приложения.

Матрица присутствия

SHA3-224, SHA3-256, SHA3-384 и SHA3-512 как digest требуют отсутствующего поля параметров. Это правило действует в соответствующих полях SignedData, SignerInfo, DigestedData и AuthenticatedData. Отсутствие не равно присутствующему NULL.

ECDSA-with-SHA3, HMAC-with-SHA3 и HKDF-with-SHA3 тоже требуют отсутствия. Универсальный кодировщик, добавляющий NULL в каждый AlgorithmIdentifier, меняет нормативное состояние.

RSA PKCS#1 v1.5-with-SHA3 требует противоположного: NULL должен присутствовать. Очистка всех нулевых значений нарушает именно эту ветвь.

KMAC задаёт третью форму. Без customization S параметры отсутствуют. При наличии S они должны содержать точные байты в OCTET STRING. Отсутствие и присутствующая пустая строка — разные свидетельства происхождения.

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

Для KDF недостаточно имени

KMAC использует K, X, L, S. Ключ K может быть результатом KEM Decap. Контекст X при использовании RFC 9629 включает DER CMSORIforKEMOtherInfo. L задаёт длину. S отделяет область применения.

Запись id-kmac128 не позволяет воспроизвести derived key. Даже сохранённые параметры не заменяют точные X и L. Две стороны способны поддерживать один OID и получить разные ключи.

KDF2 и KDF3 несут вложенный идентификатор digest. Если выбран SHA3, внутренние параметры также должны отсутствовать. Проверка внешнего OID не проверяет вложенный контракт.

Сначала байты, затем удобное представление

Parser может принять две формы и свести их к одному внутреннему значению. После потери входных байтов нельзя отличить терпимость получателя от соответствия отправителя. Повторная сериализация создаёт новое утверждение.

Нужны hash полученного CMS, путь поля, OID, состояние и hash параметров, вложенные идентификаторы, версия parser, факт нормализации, криптопровайдер, ссылка на ключ, операция и результат. Проверка сертификата, назначение ключа, авторизация и результат приложения фиксируются отдельно.

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

Реестр не наблюдает исполнение

IANA создаёт общие уникальные координаты. Эти записи не сертифицируют библиотеку, не считают развёртывания и не подтверждают interoperability. Поведение доказывают захваченные байты, векторы, версии и воспроизводимые результаты.

Разделение делает обе стороны сильнее: реестр отвечает за имя, running code — за действие, приложение — за итог.

Источники