Определение прав доступа при отсутствии discretionaryData

[andrewkostevich]

Если компонент discretionaryData отсутствует, то используются максимальные для прикладной программы права доступа

Права максимальные или, может, минимальные?

Максимальные права для программы eID

• включают запись в перезаписываемые группы данных?
• включают право использования CAN?

Максимальные права для программы eSign

• включают генерацию и удаление ключей, запись сертификатов?

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

[olegotory]

Если терминал не имеет доступа к прикладной программе, то опускается весь компонент, который отвечает за права (см. раздел 9 стандарта): certHolderAuthorizationTemplate (для eID) и certExtensions (для eSign). Если же компонент, отвечающий за права, включен, но в нем отсутствует discretionaryData, то это означает, что права максимальные (равносильно случаю, когда в правах все биты установлены в 1). Максимальные права устанавливаются для сертификата корневого УЦ, могут устанавливаться для сертификатов подчиненных УЦ и некоторых терминалов. Считаю, что из контекста стандарта понятно, что такое максимальные права.

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

Предложение: оставить как есть и закрыть issue.

[andrewkostevich]

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

Включенные по умолчанию права

• запись в перезаписываемые группы данных программы eID
• право использования CAN при аутентификации программы eID
• генерация и удаление ключей, запись сертификатов программы eSign

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

[olegotory]

В стандарте нет такого понятия -- включенные по умолчанию права. По сертификату права всегда однозначно определяются. За установку прав отвечает УЦ. Для максимальных прав логика следующая: если права максимальные, то для уменьшения длины сертификата компонент discretionaryData может не включаться, т.е. случай, когда discretionaryData не включается, эквивалентен случаю, когда права заданы и установлены во все единицы. Что предлает @andrewkostevich мне непонятно. Про какие безопасные значения прав доступа по умолчанию идет речь? Следует сформулировать конкретно,что предлагается.

[andrewkostevich]

Права по умолчанию, все единицы от УЦ кроме:

• запрещают запись в перезаписываемые группы данных
• запрещают право использования CAN
• запрещают генерацию и удаление ключей, запись сертификатов программы eSign

Лучше сделать по аналогии с basicConstraints: в basicConstraints признак УЦ по умолчанию (если не задан) выставлен в FALSE: если права терминала явно УЦ не установлены, запретить ему опасные операции

[agievich]

Напомню, что слова доступа (HAT) КУЦ, ПУЦ (опционально), терминала, а также слово доступа, заданное пользователем в начале работы с КТ, накладываются друг на друга по правилу AND:

HAT <- HAT_КУЦ AND [HAT_ПУЦ AND] HAT_Т AND HAT_owner.

Исключение HAT из сертификата с поднятием прав до максимальных вполне естественно: оно в точности соответствует исключению того же HAT из предыдущей формулы.

Исключение HAT из сертификата КУЦ кажется разумным: уменьшается объем сертификата, сокращается время разбора цепочки сертификатов. Исключение HAT из сертификата КУЦ фактически означает, что сужение прав будет определено позднее -- в сертификате Т (или мб ПУЦ). Рассуждения о том, что сужение не будет выполнено (так я понимаю предыдущие комментарии) кажутся натянутыми. Разве мы не предполагаем, что УЦ будут корректно спроектированы и реализованы?

[andrewkostevich]

Если оператор КУЦ и ПУЦ при разворачивании архитектуры для выпуска сертификатов терминалов не выполнит задние необязательных по стандарту параметров (параметра HAT) он получит уязвимую архитектуру, что IMHO нарушает принцип "безопасной конфигурации по умолчанию"

[agievich]

Возникло непонимание. Речь не идет об установке прав. Речь идет об их кодировании: максимальные права кодируются специальным (минималистским) образом. Трудно представить себе ситуацию, когда оператору будет предложено включить HAT в сертификат Т, или исключить. Оператору будет предложено задать права Т. Это не компетенция оператора, как заданные права будут кодироваться.

[andrewkostevich]

Нужно все-таки определиться с обязательностью discretionaryData.

По тексту стандарта компонент discretionaryData является обязательным:

1. Для описания прав доступа к eID компонент objId должен принимать значение id-eIdAccess, определенное в приложении А. Компонент discretionaryData должен присутствовать и состоять из пяти октетов.
2. Для описания прав доступа к прикладной программе eSign компонент objId должен принимать значение id-eSignAccess, определенное в приложении А. Компонент discretionaryData должен присутствовать и состоять из двух октетов.

Рядом по тексту стандарта компонент discretionaryData является необязательным:

1. discretionaryData OCTET STRING OPTIONAL
2. Если компонент discretionaryData отсутствует, то используются максимальные для прикладной программы права доступа

По тексту и по сути компонент discretionaryData является обязательным, предлагаю убрать OPTIONAL и оговорку про отсутствует

[olegotory]

Компонент discretionaryData при определении типа CertHAT объявлен как OPTIONAL потому, что так он объявлен в первоисточниках.

Предлагается написать:

1. Для описания прав доступа к eID компонент objId должен принимать значение id-eIdAccess, определенное в приложении А. Если компонент discretionaryData присутствует, то он должен состоять из пяти октетов.
2. Для описания прав доступа к прикладной программе eSign компонент objId должен принимать значение id-eSignAccess, определенное в приложении А. Если компонент discretionaryData присутствует, то он должен состоять из двух октетов.

[andrewkostevich]

Просьба дать ссылку на первоисточник

[agievich]

Решение: согласиться с первоначальным предложением и сделать поле CertHAT.discretionaryData обязательным со всеми вытекающими последствиями.

[agievich]

Реализовано в https://github.com/bcrypto/btok/commit/2e0204a3b71dd9374a76fb66de48a322a0f6a61c