Формирование `ResponderID.byKey` в OCSP

[agievich]

В п. 6.2.1 СТБ 34.101.26 следующий абзац нуждается в переделке:

Компонент byKey содержит хэш-значение открытого ключа OCSP сервера. Хэшируется кодовое представление значения компонента subjectPublicKey типа SubjectPublicKeyInfo, за исключением тега и длины. Для кодирования ДОЛЖНЫ использоваться отличительные правила (см. приложение В). В качестве алгоритма хэширования ДОЛЖЕН использоваться алгоритм, определенный в запросе.

Во-первых, в RFC2560/6960 компонент byKey должен формироваться с помощью SHA-1. Другие хэш-функции не допускаются.

Во-вторых, вместо "за исключением тега и длины" следует писать "за исключением тега, длины и числа неиспользуемых битов".

[agievich]

Предлагается следующая редакция проблемного абзаца:

Компонент byKey содержит хэш-значение открытого ключа OCSP сервера. Хэшируется кодовое представление значения компонента subjectPublicKey типа SubjectPublicKeyInfo, за исключением тега, длины и числа неиспользуемых битов. Хэширование ДОЛЖНО выполняться с помощью алгоритма SHA-1.

Из-за жесткой привязки byKey к SHA-1 при профилировании типа

ResponderID ::= CHOICE {
  byName        [1]  Name,
  byKey         [2]  KeyHash}

разумно отдавать предпочтение компоненту byName (именно такой выбор по умолчанию реализован в openssl ocsp).

Следует обсудить отказ от byKey в пользу byName при профилировании ответов OCSP в СТБ 34.101.78.