Closed agievich closed 6 years ago
Насколько я помню, флаги bpki-eku-clientTM
и bpki-eku-serverTM
задумывались как аналоги eku флагов clientAuth
и serverAuth
, используемых для TLS. Эти флаги должны указываться в сертификатах терминала (выступает в качестве клиента) и КТ (сервер), а сертификаты должны использоваться только в рамках протокола bauth при аутентификации в приложении eID. Сертификат eID записывается на КТ один раз при производстве, поэтому описываемые в btok процессы не относятся к этому сертификату.
Не понятно, почему эти флаги используются применительно к сертификатам подписи (владельца КТ или терминала)?
Если имеется ввиду сертификат подписи владельца КТ, который должен использоваться только в терминальном режиме, то нужно ли отличать подписи квалифицированную от обычной? Если нет, то ничего дополнительного делать не нужно. Если да, то нужно, например, ввести новый eku флаг bpki-eku-qualified
(указывается в квал. серт. владельца КТ и в запросе на него на этапе Enroll2), терминал, после выработки подписи КТ, должен поставить свою контр-подпись, а при проверке нужно проверять наличие флага (для таких-то документов должна быть только квал. подпись). Аналогичных флагов в RFC я не встречал, но этот флаг в целом имеет смысл. Контр-подпись, наверно, будет излишней.
Если речь идет об изменении (упрощении, облегчении) форматов сертификатов eID, то имеет смысл облегчить сертификаты как КТ, так и терминала (КТ будет проще проверить сертификат терминала, и сертификаты будут помещаться в короткие apdu команды). В этом случае можно отказаться от bpki-eku-xxxTM
, но нужно поддержать выпуск облегченных сертификатов для терминалов. На уровне форматов и процессов, как я понимаю, это будет сделать достаточно затруднительно: нужно вводить флаги для указания формата сертификата - обычный или облегченный (в CMS есть OtherCertificateFormat, нужно ввести oid для указания наших облеченных сертификатов).
Флаги bpki-eku-xxxTM
не имеют отношения к облегченным сертификатам. Только сертификаты X.509. И даже более конкретно: сертификаты, которые используются при проверке ЭЦП. Флаг bpki-eku-clientTM
должен присутствовать в X509-сертификате владельца КТ, чтобы показать, что подпись вырабатывается в терминальном (с повышенными гарантиями надежности) режиме. Для организации терминального режима у терминала должен быть сертификат. Пока это облегченный сертификат.
Теперь переформулирую свой вопрос: стоит ли предусматривать, что со временем у терминала может появиться X508-сертификат, и тогда уместно предусмотреть флаг bpki-eku-serverTM
?
@semenov-vladyslav Почему bpki-eku-serverTM
в сертификате КТ, а не терминала? Это намеренно или описка?
По флагам никаких действий не предпринимается. Флаг bpki-eku-serverTM
остается на будущее. Уже сейчас понятно, что его вполне может использовать СИ (служба идентификации).
По поводу выбора между обычным и квалифицированным сертификатом в Enroll2
. Этот выбор делает РЦ, выступающий в роли терминала. Выбор реализуется заполнением CSR: с флагом bpki-eku-clientTM
или без него.
В описание Enroll2
добавлена фраза:
При формировании запроса РЦ может включить в него расширение
ExtKeyUsage
с идентификаторомbpki-eku-clientTM
и, таким образом, запросить выдачу терминального сертификата.
Флаг
bpki-eku-clientTM
в EKU сертификата указывает на то, что сертификат выпущен для владельца КТ и лк этого сертификата может использоваться (только и только) в терминальном режиме. Этот значит, что КТ будет подписывать только те хэш-значения, которые поступили от предварительно аутентифицированного (надежного) терминала. Речь идет о квалифицированной подписи.Итак, флаг
bpki-eku-clientTM
нужен, это фактически признак квалифицированного сертификата. Такие сертификаты будут, для их выпуска предусмотрен сценарийEnroll2
. Правда в этом сценарии не предусмотрен выбор между обычным и квалифицированным сертификатом.Флаг
bpki-eku-serverTM
, дуальныйbpki-eku-clientTM
, кажется естественным. Этот флаг планировалось использовать в аутентификационных сертификатах терминалов, взаимодействующих с КТ. Но при сегодняшнем понимании сертификаты терминалов обязательно будут облегченными. Они будут иметь совершенно другой формат, в котором нет местаbpki-eku-serverTM
.Два вопроса:
Enroll2
между обычными и квалифицированными сертификатами?bpki-eku-serverTM
: исключить или на всякий случай оставить на будущее?