Closed mkazl closed 1 month ago
Вместо
Форматы
SignedData
иEnvelopedData
профилируются в 8.6, 8.7. Речь идет о профилировании в рамках ИОК. За пределами ИОК форматыSignedData
иEnvelopedData
могут конкретизироваться по-другому.
предлагается писать
Форматы
SignedData
иEnvelopedData
профилируются в 8.6, 8.7. Речь идет о профилировании в рамках процессов раздела 9. Вне этих процессов форматыSignedData
иEnvelopedData
могут конкретизироваться по-другому.
К новой формулировке тоже есть претензия: она ссылается на раздел 9, поэтому не учитывает следующие три типа подписанных данных:
id-ct-TSTInfo
- ответ СШВ, который определен в разделе 8 (подпункт 8.9.2);id-ct-DVCSResponseData
- ответ СШВ, который определен в разделе 8 (подпункт 8.10.2);bpki-ct-resp
- ответ УЦ, который определен в разделе 8 (пункт 8.11).Вторая попытка:
Форматы
SignedData
иEnvelopedData
профилируются в 8.6, 8.7. Профилирование касается случаев использования форматов в процессах и сервисах, определяемых или конкретизируемых в настоящем стандарте. В других случаях форматыSignedData
иEnvelopedData
могут профилироваться по-другому.
Возможно, следует рассмотреть следующую формулировку:
Форматы
SignedData
иEnvelopedData
профилируются в 8.6, 8.7. Профилирование касается случаев использования форматов в процессах и сервисах касающихся операций управления РЦ и УЦ, определяемых или конкретизируемых в настоящем стандарте. Операции функционирования и управления относительно репозитария СОК и СОС в данном стандарте не рассматриваются, форматыSignedData
иEnvelopedData
ФЛ и ЮП могут профилироваться по-другому.
Предлагаемая формулировка технически неточна, ведь профилирование касается не только "операций управления РЦ и УЦ". Подготовка запроса на выпуск сертификата — это ведь не управление РЦ или УЦ. Выпуск штампа времени — это также не управление РЦ или УЦ. Можно продолжать.
Следует иметь в виду, что обсуждается формулировка из вводной части стандарта. Здесь мы не можем себе позволить больших подробностей и "забеганий вперед". Почему выводятся из профилирования только ФЛ и ЮП? А остальные стороны? "Репозитарии СОК и СОС" в СТБ 341012.78 не упоминаются. Почему мы должны говорить о них во вводной части? "Репозитарий" (не встречал этот термин в стандартах СТБ 34.101) или "репозиторий" (термин СТБ 34.101.19)?
Предлагаем некоторое время подождать, так как возможно кем-нибудь будут предложены альтернативные формулировки. Если же таковых не будет, то можно остановиться на предложенном выше варианте.
Предложенные корректировки реализованы в https://github.com/bcrypto/bpki/commit/788b2b0ae75bcd1e6866b1b9c94d01a9437ba01b.
В пункте 5.3 Стандарта есть абзац, в котором сказано, что:
Эту фразу можно интерпретировать так: все подписанные (
SignedData
) и конвертованные (EnvelopedData
) данные, которые передаются между сторонами ИОК, должны соответствовать требованиям пунктов 8.6 и 8.7 соответственно. Получается, например, подписанные данные не могут иметь базовый типid-data
, так как в пункте 8.6 такой тип подписываемых данных среди допустимых типов подписываемых данных не упоминается.Возможно вместо
следует писать
или что-то вроде этого.