search

bcrypto / bpki

A public key infrastructure profile
8 stars 0 forks source link

Дополнительные расширения в запросе на получение сертификата #35

Closed bcryptobot closed 6 years ago

bcryptobot commented 6 years ago

Дать возможность в заявке на выпуск сертификата задавать атрибуты, отличные от двух перечисленных в п. 8.2 (например, "Время подписания заявки" OId="1.2.840.113549.1.9.5" и "Планируемый владельцем период действия сертификата" OId="1.2.112.1.2.1.1.5.5").

Дать возможность в заявке на выпуск сертификата задавать расширения, отличные от трёх перечисленных в п.8.2.2 (например, "Период действия личного ключа" OId="2.5.29.16" ).

Дать возможность в заявке на выпуск сертификата задать желательный период действия сертификата.

agievich commented 6 years ago

Атрибут id-ce-privateKeyUsagePeriod (2.5.29.16) довольно стабильный. О его включении в CSR можно подумать.

Атрибут SigningTime (1.2.840.113549.1.9.5) в CSR нежелателен. Если уж его использовать, то на уровне CMS (см. #20).

Где описан формат атрибута с идентификатором 1.2.112.1.2.1.1.5.5?

Общая позиция по поводу запрашиваемых сроков действия сертификата.

Во-первых, в СТБ 34.101.19 сказано:

Срок действия сертификата – это временной интервал, в течение которого УЦ гарантирует, что будет поддерживать информацию о статусе сертификата.

Это значит, что срок действия находится в полном ведении УЦ, субъект не принимает решений по сроку действия своего же сертификата (хотя может вносить рекомендации).

Во-вторых, попытка учета рекомендаций требует разруливания, например, следующих ситуаций.

  1. Субъект запросил выпуск сертификата на 1 год, начиная с 2028 года. Разрешить или отказать? С одной стороны, 1 год -- разрешенный период. С другой стороны, при определении максимальных сроков действия сертификатов учитывалась, в том числе, угроза компрометации личного ключа при его длительном хранении. 10 лет -- это очень долго.
  2. Пусть рекомендации субъекта отвергнуты. УЦ должен отказать в выпуске сертификата или УЦ должен выпустить сертификат с теми сроками, которые он выбирает сам?

В-третьих, в BPKI определены сроки действия сертификатов тех или иных субъектов. Есть механизм информирования УЦ об оплате услуг выпуска сертификата (поле info в CSR.challengePassword), есть возможность продления сертификата (даже с тем же ок) с помощью Reenroll.

Вывод. Считаю, что механизмы BPKI ясны и достаточны. Новые механизмы (рекомендуемый срок действия в CSR) не нужны. Они только все запутают.

agievich commented 6 years ago

После дополнительных консультаций решено:

  1. Описать атрибут certificateValidity, в котором можно указать рекомендуемый срок действия сертификата (аналог атрибута 1.2.112.1.2.1.1.5.5).
  2. Не запрещать включение дополнительных атрибутов в запросах ПУЦ.
  3. Не запрещать включение дополнительных расширений в атрибуте extensionRequest запроса к ПУЦ.