Выпуск новых сертификатов УЦ

Для любого сертификата открытого ключа (далее - сертификат или СОК) Удостоверяющего центра (УЦ) наступает время, когда приближение даты окончания срока действия сертификата УЦ уже не позволяет выпускать сертификаты конечных пользователей (СКП) с максимальными сроками действия, предусмотренными политикой выпуска сертификатов. Не простым и не однозначным является ответ на вопрос, как поступить в связи с приближением даты окончания срока действия сертификата УЦ.

Далее по тексту будут использоваться термины: Кросс-сертификат: Сертификат удостоверяющих центров, в которых эмитент и субъект сертификата являются двумя разными удостоверяющими центрами; кросс-сертификаты указывают на доверенные отношения между двумя удостоверяющими центрами (см. п.п. 3.9 СТБ 34.101.19-2012). Самоизданный сертификат: Сертификат удостоверяющего центра, в котором эмитент и субъект являются одной и той же стороной (т.е. значение эмитент и субъект совпадают, см. п.п. 3.17 СТБ 34.101.19-2012). Самоподписанный сертификат: Самоизданный сертификат, электронная цифровая подпись которого может быть проверена с помощью открытого ключа из данного сертификата (см. п.п. 3.18 СТБ 34.101.19-2012). Обновление сертификата УЦ: Генерация новой собственной пары "личный ключ - открытый ключ" и выпуск нового сертификата УЦ до истечения срока действия сертификата УЦ. Сертификат Корневого УЦ: Самоизданный и самоподписанный сертификат УЦ, который является корневым УЦ в иерархической Инфраструктуре Открытых Ключей (ИОК).

1. Случай создания новый УЦ

Let's Encrypt - известный бесплатный, автоматизированный и открытый центр сертификации - решает вопрос путем выпуска сертификатов для нового УЦ Цепочка доверия (Let's Encrypt) Это означает, что выпускаются сертификаты УЦ, имеющие новые значения субъекта, но наследующие функции УЦ. В таких случаях предусматривается возможность выпуска кросс-сертификатов. Каждый УЦ выпускает свой список отозванных сертификатов (СОС). Порядок проверки СКП, у которых старый сертификат Корневого УЦ (root.old.cer) содержиться в доверенных (кроме того, для проверки должны быть сертификаты УЦ Издателей, кросс-сертификат и все СОС), приведена ниже:

user.old.cer - subroot.old.cer - root.old.cer
               subroot.old.crl   root.old.crl

user.new.cer - subroot.new.cer - cross-root.new.cer - root.old.cer
               subroot.new.crl   root.new.crl         root.old.crl

В какой-то момент, до наступления даты окончания срока действия сертификата root.old.cer, необходимо будет обеспечить продолжение непрерывной работы пользователя по проверке СКП путем добавления в доверенные root.new.cer. После добавления проверка может быть выполнена следующим образом:

user.old.cer - subroot.old.cer - root.old.cer
               subroot.old.crl   root.old.crl

user.new.cer - subroot.new.cer - root.new.cer
               subroot.new.crl   root.new.crl

Для всех указанных выше случаев можно успешно выполнить проверку корректности СКП с использованием утилиты openssl из состава OpenSSL. При этом корректность всех СОС проверяется с использованием цепочки сертификатов (маршрута сертификации), построенной для проверки СКП.

2. Случай обновления сертификатов УЦ

Более удобным для издания / отзыва СКП с точки зрения практического использования является вариант обновления сертификата УЦ. В этом случае предполагается, что значения субъекта в старом и новом сертификате УЦ совпадают; УЦ выпускает один объединенный СОС. На мой взгляд, имеющиеся рекомендации (RFC) и стандарты (СТБ) не дают ответа на вопрос, может ли использоваться личный ключ, соответствующий открытому ключу, указанному в старом сертификате УЦ (далее - старый личный ключ УЦ), после выпуска нового сертификата УЦ. Т.е., например, может ли УЦ продолжать выпускать сертификаты с использованием старого личного ключа; может ли УЦ выпускать СОС как с использованием старого, так и нового личных ключей.

Рассмотрим случай, когда старый личный ключ УЦ после обновления сертификата УЦ больше не используется для выпуска СОС (СОС выпускается ТОЛЬКО с использованием нового личного ключа УЦ). При этом старый личный ключ УЦ использовался только для выпуска двух самоизданных сертификатов - сертификата УЦ с новым открытым ключом УЦ, подписанный старым личным ключом УЦ, а также сертификата УЦ со старым открытым ключом УЦ, подписанный новым личным ключом УЦ (аналоги кросс-сертификатов).

Теоретически проверка СКП может быть успешно выполнена для следующей цепочки сертификатов (случай обновления сертификата Корневого УЦ)

user.old.cer - subroot.old.cer - root.old.cer

с использованием в т.ч. СОС, выпущенного с использование нового личного ключа Корневого УЦ

                                 root.new.crl (cross-root.new.cer - root.old.cer)

Одним из обязательных условий успешной проверки корректности сертификата является условие, согласно которому точка доверия маршрута сертификации для эмитента СОС ДОЛЖНА быть такой же, как и точка доверия для верификации проверяемого сертификата (см. п.п. 8.3.3 СТБ 34.101.19-2012). В нашем случае - root.old.cer

Однако на практике при использовании программ, реализующих алгоритм проверки СОК, таких, как OpenSSL, проверка СКП завершится с ошибкой по причине невозможности определения статуса сертификата subroot.old.cer. Проверка СКП с помощью OpenSSL может быть выполнена успешно в случае, если в доверенных присутствует только новый сертификат Корневого УЦ. Следующие схемы успешно могут быть применены в OpenSSL для проверки СКП (предполагается случай выпуска СОС только с использованием нового личного ключа Корневого УЦ):

user.old.cer - subroot.old.cer - cross-root.old.cer - root.new.cer

user.new.cer - subroot.new.cer  - root.new.cer

Одним из возможных решений в случае необходимости обновления сертификата Корневого УЦ (СОС выпускается ТОЛЬКО новым сертификатом Корневого УЦ, обновления сертификата УЦ Издателя СКП еще не было) может быть применение следующей схемы.

На стороне Корневого УЦ:

Произвести выпуск СОС для действующего сертификата Корневого УЦ, предоставить доступ для пользователей (обеспечивается максимальный срок возможного перехода на обновления у пользователей).
Выпустить новый сертификат Корневого УЦ и СОС, организовать предоставление доступа для пользователей.
Выпустить сертификат УЦ со старым открытым ключом УЦ, подписанный новым личным ключом УЦ (аналог кросс-сертификата), организовать предоставление доступа для пользователей.

На стороне пользователей:

Загрузить СОС для сертификата Корневого УЦ, полученный в 1. Имеем: subroot.old.cer, subroot.old.crl, root.old.cer, root.old.crl
Загрузить новый сертификат Корневого УЦ; СОС, выпущенный с использованием нового сертификата Корневого УЦ; сертификат УЦ со старым открытым ключом УЦ, подписанный новым личным ключом УЦ. Имеем: subroot.old.cer, subroot.old.crl, root.old.cer, root.old.crl, root.new.cer, root.new.crl, cross-root.old.cer
В период действия СОС, выпущенного старым сертификатом Корневого УЦ, выполнить удаление старого сертификата Корневого УЦ (после этого считаем, что root.old.crl уже не используется). Имеем: subroot.old.cer, subroot.old.crl, cross-root.old.cer, root.new.cer, root.new.crl.

Примечание: Далее возникает вопрос, как обеспечить корректное обновление сертификата УЦ Издателя, который должен быть издан с использованием нового сертификата Корневого УЦ. Это необходимо решить в процессе дальнейшего обсуждение темы.

Чтобы продолжить обсуждение темы, на мой взгял, следует ответить также на следующие вопросы:

Допускает ли стандартами Беларуси и международными рекомендациями (RFC) после обновления сертификата УЦ использование старого личного ключа УЦ для выпуска очередных СОС?
(в случае положительного ответа на вопрос 1) Допускается ли выпуск очередных СОС как с использованием старого, так и нового личного ключа УЦ?
Возможно ли поместить в область доверенных как старый так и новый сертификат Корневого УЦ, и в каких случаях (какие могут быть ограничения)?

Хотелось бы определить возможные схемы работы для ИОК, в которой необходимо обновить сертификат Корневого УЦ, допустимые требованиями стандартов и рекомендаций.

К сожалению, по ошибке, issues опубликован без указания конкретного автора, Поэтому данным дополнительным сообщением хочу определить, что автором является сотрудник ЗАО "АВЕСТ".

Ответы на вопросы.

Допускается. УЦ, выпустивший СОС, описывается именем (поле issuer типа Name) и идентификатором открытого ключа (расширение authorityKeyIdentifier). Имя указывается обязательно, идентификатор открытого ключа -- опционально (и снова обязательно в СТБ 34.101.78). Таким образом, сама схема построения СОС предполагает, что сторона с фиксированным именем может использовать несколько разных ключей. Более того, в СТБ 34.101.19, п. 7.2.1 при описании расширения authorityKeyIdentifier явно сказано:

Данное расширение особенно полезно в случаях, когда эмитент имеет несколько ключей подписи по причине либо наличия нескольких одновременно существующих пар ключей, либо смены ключей.
Не вижу причин для запрета. Подтверждение из другого источника: https://security.stackexchange.com/questions/211713/whats-the-goal-behind-signing-a-crl-with-an-old-certificate-key.
Не вижу причин для запрета. Выпуск нового сертификата не означает отзыв действующего.

Note К сожалению, не все в предложениях понятно. Например, фраза

Выпустить сертификат на основе старого сертификата Корневого УЦ с использованием нового сертификата Корневого УЦ.

Что означает "на основе старого", "с использованием нового"? Возможно следует подправить терминологию. Говорить о сертификатах в терминах "личный ключ" (на котором сертификат выпускается), "открытый ключ" (который в сертификате указывается), "имя" (которое также указывается) и т.д.

"... К сожалению, не все в предложениях понятно ..." Спасибо за замечания. Текст был скорректирован так, чтобы в нем, насколько возможно, использовалась терминология, предусмотренная в СТБ 34.101.19.

Выпустить сертификат УЦ со старым открытым ключом УЦ, подписанный новым личным ключом УЦ (аналог кросс-сертификата), ....

Каково назначение "кросс-сертификата"? Спрашиваю потому, что если действующий и новый сертификаты УЦ включены в пространство доверия пользователей, если действующий и новый сертификаты используются параллельно в течение переходного периода (например, для проверки СОС), то в "кросс-сертификатах" нет необходимости.

Решение с параллельным действием двух сертификатов УЦ в течение переходного периода представляется максимально простым и эффективным. Это решение не устраивает? Есть недостатки?

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

Каково назначение "кросс-сертификата"? Спрашиваю потому, что если действующий и новый сертификаты УЦ включены в пространство доверия пользователей, если действующий и новый сертификаты используются параллельно в течение переходного периода (например, для проверки СОС), то в "кросс-сертификатах" нет необходимости.

В решение предполагается случай, когда после обновления используется ТОЛЬКО ОДИН СОС, который выпускается с использованием НОВОГО личного ключа Корневого УЦ.

Решение с параллельным действием двух сертификатов УЦ в течение переходного периода представляется максимально простым и эффективным. Это решение не устраивает? Есть недостатки?

Решение - использовать СОС-ы, выпускаемые с использованием личных ключей УЦ, для действующих сертификатов УЦ должно быть применено как общее решение для всей ИОК - т.е. должно распространяться как на Корневой УЦ, так и на УЦ издателей. Это ОДИН ИЗ ВОЗМОЖНЫХ подходов, не противоречащих белорусским стандартам и международным рекомендациям. К недостаткам такого подхода можно отнести необходимость выпуска СОС в УЦ с использованием разных личных ключей УЦ. Техподдержка клиентов тоже усложниться в части понимания, что не так у конечного пользователя.

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

В решении с "кросс-сертификатами" все по-другому. Нагрузка на УЦ увеличивается минимально (всего лишь выпустить "кросс-сертификат"), а вот на пользователей -- существенно: в клиентском ПО нужно предусмотреть наличие "кросс-сертификата", нужно договориться о сетевой локации, в которой "кросс-сертификат" размещается, нужно строить и обрабатывать более длинные цепочки сертификатов.

Если клиентское ПО правильно спроектировано и получает адрес для загрузки СОС из CRLDistibutionPoints, то для пользователей наличие одного или нескольких СОС мало что меняет: работаем со старым сертификатом -- загружаем СОС из одной сетевой локации, перешли на новый сертификат -- из другой

Здесь необходимо определиться с терминологией правильно спроектировано. Если прикладное ПО соответствует требованиям СТБ 34.101.19-2012 - это правильно спроектированное (ОБЯЗАНО обеспечить обработку CRLDistibutionPoints) или не совсем. Это критично для определения нагрузки на клиенте и на УЦ.

На мой взгляд, использовать возможности CRLDistibutionPoints необходимо крайне осторожно. Требуется оценка увеличения нагрузки на ресурсы УЦ при скачивании клиентом актуального СОС для проверки сертификата конечного пользователя. Хорошо, если СОС пустой или небольшого размера, не обновляется достаточно часто.

Здесь необходимо определиться с терминологией правильно спроектировано. Если прикладное ПО соответствует требованиям СТБ 34.101.19-2012 - это правильно спроектированное (ОБЯЗАНО обеспечить обработку CRLDistibutionPoints) или не совсем. Это критично для определения нагрузки на клиенте и на УЦ.

Фраза "правильно спроектировано" (неточно, но лучше сказать не получилось) касается именно проектирования. Фраза больше относится даже не к ПО, а к инфраструктуре, в которой ПО функционирует. Детали инфраструктуры описываются профилем ИОК. Пример профиля -- СТБ 34.101.78 (Bpki). В этом профиле расширение CRLDistributionPoints предусмотрено. Выше я неявно подразумевал профиль СТБ 34.101.78 (именно на площадке Bpki мы ведем обсуждение). Другой пример профиля -- настройки ГосСУОК. В этом профиле расширение CRLDistributionPoints не предусмотрено. Понятно, что если расширение в инфраструктуре не предусмотрено, то клиентское ПО поддержать его не сможет.

Соответствие требованиям СТБ 34.101.19 --- это о корректности реализации, а не о "правильном проектировании".

На мой взгляд, использовать возможности CRLDistibutionPoints необходимо крайне осторожно. Требуется оценка увеличения нагрузки на ресурсы УЦ при скачивании клиентом актуального СОС для проверки сертификата конечного пользователя. Хорошо, если СОС пустой или небольшого размера, не обновляется достаточно часто.

Логика управления СОС не меняется, в зависимости от наличия или отсутствия CRLDistibutionPoints в сертификатах. Расширение CRLDistibutionPoints всего лишь позволяет автоматизировать загрузку СОС.

Обсуждение развернулось в сторону CRLDistibutionPoints. И это, вообще говоря, уход в сторону. Давайте вернемся к сути дела.

Мы начали обсуждать "кросс-сертификаты" -- схему, которая позволяет перейти на новый сертификат, сохранив доверие к старому (точнее, его открытому ключу). Была затронута альтернативная схема -- "параллельные сертификаты". Здесь старый и новый сертификаты в течение переходного периода действуют параллельно.

Пока единственное преимущество "кросс-сертификатов" перед "параллельными сертификатами", которое я вижу, -- это снижение нагрузки на УЦ, которому не нужно подписывать СОС на старом личном ключе. Однако это преимущество лишь кажущееся. Действительно в схеме с "кросс-сертификатами" пользователи не могут перейти на новые сертификаты одномоментно, часть пользователей будет продолжать использовать старый сертификат в течение определенного времени. Для таких пользователей нужно выпускать дополнительный СОС.

Пока единственное преимущество "кросс-сертификатов" перед "параллельными сертификатами", которое я вижу, -- это снижение нагрузки на УЦ, которому не нужно подписывать СОС на старом личном ключе. Однако это преимущество лишь кажущееся. Действительно в схеме с "кросс-сертификатами" пользователи не могут перейти на новые сертификаты одномоментно, часть пользователей будет продолжать использовать старый сертификат в течение определенного времени. Для таких пользователей нужно выпускать дополнительный СОС.

При любом раскладе клиенту придется добавить в свое хранилище новый/вые сертификат/ты УЦ (обязательно новый сертификат Корневого УЦ в доверенные) и СОС для возможности проверки сертификатов конечных пользователей. Плюсы схемы с "кросс-сертификатами" - организация в УЦ выпуска после обновления только одного СОС с использованием только нового личного ключа УЦ . Минусы схемы с "кросс-сертификатами" - необходимость выполнения разовой операции: УЦ - по выпуску дополнительного самоизданного сертификата; клиентам - удаления из доверенных старого сертификата Корневого УЦ. Плюсы схемы с "параллельными сертификатами" - УЦ не требуется выпуск дополнительного самоизданного сертификата, клиентам не надо удалять старый Корневой сертификат из доверенных. Минусы схемы с "параллельными сертификатами" - организация в УЦ выпуска СОС-ов с использованием личных ключей для всех действующих сертификатов УЦ.

Минусы схемы с "параллельными сертификатами" - организация в УЦ выпуска СОС-ов с использованием личных ключей для всех действующих сертификатов УЦ.

Выше я писал, что это также минус схемы с "кросс-сертификатами". Здесь у нас согласие?

Нет. Согласия нет.

Минусы схемы с "параллельными сертификатами" - организация в УЦ выпуска СОС-ов с использованием личных ключей для всех действующих сертификатов УЦ.

Хотел акцентировать внимание на ключевые слова "для всех действующих сертификатов УЦ". Если наглядно, то схема проверки СКП после обновления сертификата Корневого УЦ и УЦ Издателя СКП будет следющей: Для схемы с "кросс-сертификатами"

user.old.cer - subroot.old.cer - cross-root.old.cer - root.new.cer
               subroot.new.crl   root.new.crl         root.new.crl
user.new.cer - subroot.new.cer - root.new.cer
               subroot.new.crl   root.new.crl

Для схемы с "параллельными сертификатами"

user.old.cer - subroot.old.cer - root.old.cer
               subroot.old.crl   root.old.crl
user.new.cer - subroot.new.cer - root.new.cer
               subroot.new.crl   root.new.crl

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

Согласен, с помощью cross-root.old.cer можно построить цепочку от user.old.cer до root.new.cer, и старая точка доверия root.old.cer не нужна.

Но в инфраструктуре на протяжении переходного периода некоторые из пользователей будут продолжать использоватьroot.old.cer, не установив root.new.cer в качестве точки доверия. Для таких пользователей нужно выпускать root.old.crl. И без subroot.old.crl не обойдешься. Ведь если СОС будет подписан на ключе сертификата subroot.new.cer, то проверка СОС будет завершена с ошибкой -- root.new.cer не включен в пространство доверия.

Но в инфраструктуре на протяжении переходного периода некоторые из пользователей будут продолжать использовать root.old.cer, не установив root.new.cer в качестве точки доверия.

Конечно же, обязательным условием для возможности проверки СКП, выпущенных после обновления сертификатов Корневого УЦ и УЦ Издателя СКП, является установка root.new.cer в доверенные. Пользователи должны выполнить алгоритм перехода, который был изложен выше.

На стороне пользователей: 1.Загрузить СОС для сертификата Корневого УЦ, полученный в 1. Имеем: subroot.old.cer, subroot.old.crl, root.old.cer, root.old.crl 2.Загрузить новый сертификат Корневого УЦ; СОС, выпущенный с использованием нового сертификата Корневого УЦ; сертификат УЦ со старым открытым ключом УЦ, подписанный новым личным ключом УЦ. Имеем: subroot.old.cer, subroot.old.crl, root.old.cer, root.old.crl, root.new.cer, root.new.crl, cross-root.old.cer 3.В период действия СОС, выпущенного старым сертификатом Корневого УЦ, выполнить удаление старого сертификата Корневого УЦ (после этого считаем, что root.old.crl уже не используется). Имеем: subroot.old.cer, subroot.old.crl, cross-root.old.cer, root.new.cer, root.new.crl.

Был не внимателен и не акцентировал внимание на том, что на этапе 2 загрузка нового сертификата Корневого УЦ производится в доверенные (иначе в нем нет никакого смысла).

Пользователи должны выполнить алгоритм перехода, который был изложен выше.

Я понимаю, что так написано, что так в теории должно быть. Но может быть и по-другому -- пользователь не выполнил инструкцию:

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

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

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

Если целью является решение по плавному переходу на новые сертификаты для инфраструктуры Bpki (СТБ 34.101.78), то я бы делал ставку на схему "параллельные сертификаты". Нагрузка на клиентов здесь увеличивается минимально, переход для клиентов хорошо автоматизируется (CRLDistributionPoints). Нагрузка на УЦ увеличивается значимо (два СОС вместо одного), но на то они и УЦ.

Если целью является решение по плавному переходу на новые сертификаты для инфраструктуры ГосСУОК, то здесь желательно выслушать мнение более сведущих специалистов.

Встречный вопрос: чем регламентируется формат сертификата РУЦ (subroot) ГосСУОК? Документом https://nces.by/wp-content/uploads/2016/03/Formats.pdf? Но в нем предусмотрено расширение CRLDistributionPoits, хотя в выпущенных сертификатах (ruc.cer, ruc_old.cer) этого расширения нет.

Дискуссия переносится в #79.

bcrypto / bpki