Изменение формата таблиц

[bcryptoregulatory]

Изменение формата таблиц

[zm1ca]

Полагаю, снизить необходимость в переходах между таблицами 1 и 2 можно изменив обозначения на более осмысленные. Так, например, замена обозначений: AШ = belt, AИ1 = belt-mac, АИ2 = hmac, АШИ - belt-datawrap, УГ = rng, УК1 = keyrep, УК5 = keytransport, ПФ3 = bsts-bmqv, УС2 = x509, УС3 = crl, УС4 = ocsp, Б1 = sotfware, Б2 = hardware, Ф1 = enveloped, приведёт к следующему виду профиля для средств предварительного шифрования:

Средства криптографической защиты информации	Требования к криптографическим алгоритмам	Требования к криптографическим протоколам и управлению ключами	Требования безопасности	Требования к форматам данных
Средства предварительного шифрования	(belt, belt-mac или hmac) или belt-datawrap	*rng, keyrep или keytransport	sotfware или hardware	[enveloped]
		rng, bsts-bmqv или keytransport, x509, crl или ocsp

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

[agievich]

В целом поддерживаю. Мы систему имен (namespace) давно продвигаем. Считаем, что без имен (слов) трудно и разговаривать, и создавать нормативные документы. Получаются сплошные бюрократизмы в стиле "п. 6.9 СТБ 34.101.31-2011".

"То, что не названо, -- не существует."

Детали:

1. Желательно снабжать каждое имя префиксом, который указывает на стандарт: cms-signed, belt-keyrep. Больше ясности и единообразия. Возможные префиксы: belt, bign, brng, bels, bash, bake, btok, bpki, а также вот здесь: https://github.com/bcrypto/stb/blob/master/README.md.
2. Мы стали сокращать имена: belt-dwp вместо belt-datawrap, bign-keyt вместо bign-keytransport. Желательно учесть.

[agievich]

Не следует привязываться к пунктам стандартов. Стандарты меняются, пункты плывут. Скоро будет запущено обсуждение новой редакции СТБ 34.101.31. Совсем другие пункты.

В новых редакциях стандартов мы, наоборот, отвязываемся от пунктов, делаем ставку на имена (belt-ecb, bign-sign, etc.). Понятно, что это можно сделать не всегда, у некоторых механизмов нет имен. В связи с этим таблица 1 имеет важно значение. Она фактически создает namespace, покрывая собственными именами имена и пункты стандартов.

Кроме этого, таблица 1 систематизирует криптографические механизмы, демонстрирует ассортимент криптографических "кирпичиков".

А вот таблица 2 действительно спорная. Здесь также проводится систематизация, но уже не "кирпичиков", а "зданий". Систематизация "типов зданий" полезна, но вот предпринятая систематизация "проектов" уже спорна.

[agievich]

Упрощение Таблицы 2 (объединение столбцов, упразднение последнего столбца) поддерживаю.

[zm1ca]

Кроме этого, таблица 1 систематизирует криптографические механизмы, демонстрирует ассортимент криптографических "кирпичиков".

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

[zm1ca]

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

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

[agievich]

Шаги по унификации имен:

• software -> skzi-sw;
• hardware -> skzi-hw;
• belt -> belt-encr или belt-modes;
• bign-with-hbelt -> bign-sign (без детализации фх; фх дополнительно детализируется в таблице 2);
• hmac -> brng-hmac (для единообразия, первая лексема всегда указывает на стандарт);
• bash -> bash-hash (в стандарте bash будут еще другие алгоритмы);
• 1176-dsa -> stb1176-sign;
• tls -> btls;
• dhX-XXX -> btls-dhX-XXX;
• brng разделить на skzi-rng и brng (с возможной допонительной детализацией brng-ctr, brng-hmac);
• revoke-req -> bpki-revoke-req или просто bpki-revoke;
• crl -> x509-crl (можно объяснить, что требуется дополнительное профилирование в соответствии с bpki или дополнительно ввести bpki-crl);
• signed -> cms-signed;
• enveloped -> cms-enveloped.

[zm1ca]

Принято в 9d2fde6 за исключением:

• software -> skzi-sw; (нужно обладать специфическими знаниями, чтобы разобраться что имелось ввиду)
• hardware -> skzi-hw;
• dhX-XXX -> btls-dhX-XXX; (алгоритмов много, и перечисляются они через запятую. изменение этих обозначений раздует таблицу)
• brng разделить на skzi-rng и brng (разделение убрано ранее для лаконичности. в любом случае, требования устанавливаются стандартами, а не профилями)