Требования-паззлы

[agievich]

Некоторые ячейки в таблице 2 очень трудно понять. Это паззлы. По-видимому, ячейки соответствуют каким-то конкретным СКЗИ каких-то конкретных разработчиков. По-видимому, разработчики закодировали функционал своих средств, не задумываясь о декодировании. А декодирование может оказаться непростым делом.

Вот ближайший пример. Средство предварительного шифрования: AШ... и УГ1 или УГ2, ПФ1 или УК5, УС2, УСЗ или УС4. Можно понять, что получатель сообщения генерирует открытый ключ (УГ1 или УГ2), погружает его в сертификат (УС2) и в ИОК (УСЗ или УС4). Отправитель сообщения генерирует сеансовый ключ (УГ1 или УГ2), зашифровывает на нем сообщение (АШ...), а сеансовый ключ зашифровывает на открытом ключе получателя (УК5). Все хорошо, но что означает ПФ1? ПФ1 -- это онлайн-протокол, в котором выполняется несколько разнонаправленных пересылок между сторонами. Но у нас средство предварительного шифрования -- отправитель может ходить сразу, не ожидая ответа от получателя. Возможно речь идет о том, что стороны предварительно согласовывают сеансовый ключ с помощью ПФ1, сохраняют его, а затем используют всякий раз при отправке сообщений друг другу. Это только догадка, логика решения не до конца понятна. Если догадка все-таки верна, то решение представляется спорным, поскольку требуется хранить сеансовый ключ на протяжении длительного времени.

Предлагается:

1. Дать краткие пояснения по ячейкам таблицы. В виде примечаний или сносок.
2. Провести упрощения -- уменьшить число ячеек-кейсов. Убрать требования по непрофильному функционалу. Например, для средств линейного шифрования есть ячейка (АШ, АИ1) или (АШ, АИ2) или АШИ и есть ячейка (АШ, АИ1) или (АШ, АИ2) или АШИ, ФХ1 или ФХ2. Дописка ФХ1 или ФХ2 явно непрофильная, она касается конкретного средства. Исключить. Оставить только (АШ, АИ1) или (АШ, АИ2) или АШИ. Или даже (АШ, АИ1 или АИ2) или АШИ.

[zm1ca]

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

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

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

Дописка ФХ1 или ФХ2 явно непрофильная, она касается конкретного средства. Исключить. Оставить только (АШ, АИ1) или (АШ, АИ2) или АШИ. Или даже (АШ, АИ1 или АИ2) или АШИ

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

Что касается предложения убрать непрофильные требования: на данный момент мы вряд ли можем пойти на это, однако излишняя специфичность это действительно актуальная проблема, которая находится на стадии индивидуального обсуждения с разработчиками соответствующих СКЗИ. Альтернативный вариант для АХ1 или АХ2: перенос обратно в третий столбец.

[agievich]

Я все-таки считаю, что нужно в каком-то виде зафиксировать, что подразумевается под тем или иным набором требований в той или иной ячейке. Может быть для начала добавить в репозиторий файл с комментариями по запутанным позициям. Иначе ситуация останется субъективной, допускающей разные трактовки.

[zm1ca]

Согласен. В сущности, это и было одной из целей создания данного репозитория. На данный момент все наши пояснения и комментарии действительно трудно собрать разработчику, поскольку они разбросаны по разным веткам обсуждения.

Данное предложение будет реализовано по мере наличия возможностей.