search

bcrypto / bpki

A public key infrastructure profile
8 stars 0 forks source link

Флаги bpki-eku-clientTM / bpki-eku-serverTM #47

Closed agievich closed 6 years ago

agievich commented 6 years ago

Флаг bpki-eku-clientTM в EKU сертификата указывает на то, что сертификат выпущен для владельца КТ и лк этого сертификата может использоваться (только и только) в терминальном режиме. Этот значит, что КТ будет подписывать только те хэш-значения, которые поступили от предварительно аутентифицированного (надежного) терминала. Речь идет о квалифицированной подписи.

Итак, флаг bpki-eku-clientTM нужен, это фактически признак квалифицированного сертификата. Такие сертификаты будут, для их выпуска предусмотрен сценарий Enroll2. Правда в этом сценарии не предусмотрен выбор между обычным и квалифицированным сертификатом.

Флаг bpki-eku-serverTM, дуальный bpki-eku-clientTM, кажется естественным. Этот флаг планировалось использовать в аутентификационных сертификатах терминалов, взаимодействующих с КТ. Но при сегодняшнем понимании сертификаты терминалов обязательно будут облегченными. Они будут иметь совершенно другой формат, в котором нет места bpki-eku-serverTM.

Два вопроса:

  1. Как организовать переключение в Enroll2 между обычными и квалифицированными сертификатами?
  2. Что делать с флагом bpki-eku-serverTM: исключить или на всякий случай оставить на будущее?
semenov-vladyslav commented 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 для указания наших облеченных сертификатов).

agievich commented 6 years ago

Флаги bpki-eku-xxxTM не имеют отношения к облегченным сертификатам. Только сертификаты X.509. И даже более конкретно: сертификаты, которые используются при проверке ЭЦП. Флаг bpki-eku-clientTM должен присутствовать в X509-сертификате владельца КТ, чтобы показать, что подпись вырабатывается в терминальном (с повышенными гарантиями надежности) режиме. Для организации терминального режима у терминала должен быть сертификат. Пока это облегченный сертификат.

Теперь переформулирую свой вопрос: стоит ли предусматривать, что со временем у терминала может появиться X508-сертификат, и тогда уместно предусмотреть флаг bpki-eku-serverTM?

@semenov-vladyslav Почему bpki-eku-serverTM в сертификате КТ, а не терминала? Это намеренно или описка?

agievich commented 6 years ago

По флагам никаких действий не предпринимается. Флаг bpki-eku-serverTM остается на будущее. Уже сейчас понятно, что его вполне может использовать СИ (служба идентификации).

По поводу выбора между обычным и квалифицированным сертификатом в Enroll2. Этот выбор делает РЦ, выступающий в роли терминала. Выбор реализуется заполнением CSR: с флагом bpki-eku-clientTM или без него.

В описание Enroll2 добавлена фраза:

При формировании запроса РЦ может включить в него расширение ExtKeyUsage с идентификатором bpki-eku-clientTM и, таким образом, запросить выдачу терминального сертификата.