Опечатка в п.8.6 Подписанные данные и п 8.2.2 Атрибут challengePassword

[zm1ca]

В п.8.6 Подписанные данные:

1) id-ct-TSTInfo, если подписывается ответ СШВ (см. 8.9.2); 2) id-ct-DVCSResponseData, если подписывается ответ СЗД (см. 8.10.2); ... Первый идентификатор определен в СТБ 34.101.81, второй — в СТБ 34.101.82, остальные — в приложении А.

СШВ определяются в СТБ 34.101.82, а СЗД в СТБ 34.101.81. Возможно, имеет место опечатка.

В п 8.2.2 говорится:

Строка — значение атрибута challengePassword состоит из двух частей

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

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

Менее значимые опечатки:

1. в п 6.6 Описание алгоритмов

   Компонентами типа является идентификатор алгоритма (или пары связанных алгоритмов) и соответствующие параметры.

явля_ю_тся

2. В п 7.2 Роли

ПУЦ подчиняется РУЦ.

подчиня_ю_тся т.к. в предшествующем предложении речь идёт о произвольном числе

3. в п. 5.4 Криптографические токены

Программный КТ представляет собой файл-контейнер с защищенным личным ключом и сопутствующими программами, которые реализуют криптографическую логику работы с ключом.

В текущей формулировке не вполне ясно, как сопутствующие программы могут содержаться в файле, в котором также хранится и ключ. Если подразумевается совокупность файла-контейнера и сопутствующих программ (отдельно), то следует писать, например: "...файл-контейнер с защищённым ключом и сопутствующие программы...". Однако, в таком случае не вполне ясно, благодаря чему достигается общность файла-контейнера и программ. В аппаратных токенах, например, такая общность достигается помещением вышеуказанных сущностей в общую криптографическую границу.

[agievich]

Переносится в #59.

1. Опечатки в п.п. 6.6, 8.6 исправлены.
2. Объяснения в п. 8.2.2 считаем точными и исчерпывающими. Строка challengePassword -- это строка типа UTF8String (см. 8.2.1). Описан синтаксис строки (правила форматирования) и семантика (содержание) частей. Шаблон "строка состоит из частей ... одна из частей может быть опущена" вполне распространен.
3. "ПУЦ подчиняется РУЦ". Именно так должно быть.
4. В фразе "... файл-контейнер с ... ключом и сопутствующими программами, которые..." придаточное предложение относится к "программами" (определительное придаточное предложение относится к отдельному существительному или местоимению в главной части).

[zm1ca]

1. Да, все использованные конструкции корректны по отдельности, однако это не помогает установить однозначность в понимании читателем слов "первая" и "вторая" применительно к частям. Дополнительно обращаю внимание на необходимость явного указания размерностей для длин частей.
2. В 5.4 ясно, к чему относится придаточное предложение. Вопросы вызывает возможность надёжной реализация схемы файл-контейнер=ключ+программы

[agievich]

1. Части описываются семантически (по смыслу). Это нормально. Когда мы говорим, что объект состоит из нескольких частей -- первой, второй, третьей -- мы не подразумеваем, что части следуют друг за другом. Длины частей однозначно определяются при разборе (парсинге) объекта -- каждой части предшествует определенный префикс, заданный в Стандарте.

2. Файлу-контейнеру сопутствуют (его сопровождают) программы.

[zm1ca]

1. Таким образом, предложение "Длина второй части не должна превышать 128." полностью корректно, и не требует корректировки "128 бит."?
2. В текущей формулировке программы сопутствуют ключу. Например, если попросить кого-то купить Вам булку с изюмом и (чем?)корицей, вряд ли кто-то принесёт (что?)корицу отдельно, в качестве сопровождения булке с изюмом. На мой взгляд, раз в данном стандарте предлагаются программные токены, их определение должно быть максимально прозрачным для разработчиков, чтобы различия в понимании не обнаружились лишь на стадии сертификации.

[agievich]

1. Длина второй части строки [типа UTF8String] не должна превышать 128 [символов UTF8]. Да, именно так.
2. Не "булка + корица", а "контейнер с ключом + программы". Именно такая концепция. Стандарт обсужден, согласован и принят. Сейчас мы ведем речь о поправках в деталях. Давайте создадим wishlist для будущих редакций Стандарта. Предлагайте альтернативную концепцию программного КТ.

[zm1ca]

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

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

Что касается концепции, то "контейнер ключа+программы" -- это практически все сертифицируемые СКЗИ.

[agievich]

Дополнительно изменение (п. 5.4, реализовано в #59): "...файл-контейнер с защищенным ключом и сопутствующими программами..." -> "...файл-контейнер с защищенным ключом и сопутствующие программы..."