RFC: 5280
Оригинал: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Предыдущие версии: RFC 2459, RFC 3280, RFC 4325, RFC 4630
Категория: Предложенный стандарт
Дата публикации: (с дополнениями из RFC 6818, Январь 2013)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич
4.1.2.5. Период действия «Validity»

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

  1. Дата начала периода действия («notBefore»);
  2. Дата окончания периода действия («notAfter»).

Обе эти даты могут кодироваться как UTCTime-время или GeneralizedTime-время.

УЦ, придерживающиеся данного стандарта, обязаны всегда кодировать даты периода действия сертификата как UTCTime-время до 2049 года включительно. А начиная с 2050 года и далее — как GeneralizedTime-время. Прикладные системы, которые также придерживаются данного стандарта, должны быть способны обрабатывать даты периода действия сертификата, закодированные как UTCTime-время или как GeneralizedTime-время.

Срок действия сертификата это период времени от даты, указанной в субполе «notBefore», до даты, указанной в субполе «notAfter», включительно.

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

Для указания того, что сертификат включает некорректный срок действия, дата, указанная в субполе «notAfter», должна иметь кодировку GeneralizedTime и значение «99991231235959Z».

Когда издатель не способен обновлять (корректировать) информацию о статусе (состоянии) до тех пор, пока не наступит дата «notAfter» (включая случай, когда дата «notAfter» имеет значение «99991231235959Z»), тогда он обязан гарантировать, что после прекращения обновления информации о состоянии данного сертификата, для последнего не существует приемлемого МС. Это может можно обеспечить, либо на основе завершения срока действия, либо путём аннулирования (отзыва) все сертификатов УЦ, которые содержат открытый ключ для проверки подписи сертификата, а также путём прекращения использования открытого ключа для проверки подписи сертификата, выступающей в качестве «якоря доверия» (trust anchor, в данном случае это последняя «скрепляющая» подпись, замыкающая цепочку (маршрут или путь) доверия или сертификации).

Страница 16 из 108

2007 - 2022 © Русские переводы RFC, IETF, ISOC.