Структура CRL: поля и расширения

CRL (Certificate Revocation List) — это список отозванных сертификатов, формируемый и подписываемый удостоверяющим центром (CA). В контексте криптографии на JavaScript и библиотеки Jsrsasign работа с CRL основана на ASN.1-структуре X.509, где список представляет собой строго определённую последовательность полей и расширений.

CRL используется для проверки актуальности сертификатов: если сертификат присутствует в списке, он считается недействительным, даже если срок его действия ещё не истёк.

Базовая структура CRL (X.509 v2)

CRL в формате X.509 v2 состоит из трёх основных компонентов:

  • tbsCertList (to be signed certificate list) — данные, которые подписываются CA
  • signatureAlgorithm — алгоритм подписи
  • signatureValue — сама цифровая подпись

Внутри tbsCertList содержится основная структура списка отозванных сертификатов.

Поля tbsCertList

1. version (версия CRL)

Поле version указывает версию структуры CRL. Для современных списков используется значение:

  • v2 (1) — обязательна для поддержки расширений

Если версия не указана, по умолчанию считается v1, но расширения тогда недоступны.

2. signature (алгоритм подписи)

Поле определяет алгоритм, которым подписан CRL. Оно дублируется на верхнем уровне структуры.

Примеры алгоритмов:

  • SHA256withRSA
  • SHA384withECDSA
  • SHA512withRSA

В Jsrsasign алгоритмы обычно представлены строковыми идентификаторами OID или псевдонимами.

3. issuer (издатель CRL)

Поле issuer содержит Distinguished Name (DN) удостоверяющего центра, выпустившего CRL.

Пример структуры:

  • C = RU
  • O = Example CA
  • CN = Example Root CA

В Jsrsasign DN представляется как объект или строка в формате RFC 2253.

4. thisUpdate (дата выпуска)

Поле thisUpdate указывает момент создания или публикации текущего CRL.

Форматы:

  • UTCTime (для дат до 2050 года)
  • GeneralizedTime (для более поздних дат)

Это поле критично для определения актуальности списка.

5. nextUpdate (следующее обновление)

Поле nextUpdate определяет дату, до которой CRL считается действительным.

Если сертификат проверяется после этой даты, CRL считается устаревшим и должен быть загружен заново.

Отсутствие nextUpdate допускается, но не рекомендуется.

6. revokedCertificates (список отозванных сертификатов)

Это массив записей, каждая из которых описывает конкретный отозванный сертификат.

Каждый элемент содержит:

serialNumber (серийный номер)

Уникальный идентификатор сертификата, который был отозван.

revocationDate (дата отзыва)

Дата, когда сертификат был признан недействительным.

7. crlExtensions (расширения CRL)

Расширения позволяют добавлять дополнительную информацию о списке отзыва.

Это поле присутствует только в CRL v2.

Расширения CRL

Расширения играют ключевую роль в современных PKI-системах. Они позволяют расширить стандартный формат без изменения базовой структуры.

Каждое расширение имеет:

  • OID (идентификатор)
  • critical (критичность)
  • value (данные)

1. Authority Key Identifier (AKI)

OID: 2.5.29.35

Используется для идентификации ключа CA, подписавшего CRL.

Содержит:

  • keyIdentifier
  • authorityCertIssuer
  • authorityCertSerialNumber

Позволяет однозначно связать CRL с конкретным ключом удостоверяющего центра.

2. CRL Number

OID: 2.5.29.20

Последовательный номер CRL, увеличивающийся при каждом новом выпуске.

Используется для:

  • проверки актуальности
  • предотвращения атак повторного использования (replay attack)

3. Delta CRL Indicator

OID: 2.5.29.27

Указывает, что CRL является дельта-списком.

Дельта-CRL содержит только изменения с момента предыдущего полного CRL.

Значение:

  • baseCRLNumber — номер базового CRL

4. Issuing Distribution Point

OID: 2.5.29.28

Определяет точку распространения CRL и область действия списка.

Содержит:

  • distributionPoint
  • onlyContainsUserCerts
  • onlyContainsCACerts
  • onlySomeReasons

Позволяет сегментировать списки отзыва по типам сертификатов.

5. Freshest CRL

OID: 2.5.29.46

Указывает на расположение дельта-CRL.

Используется для оптимизации загрузки: клиент может загружать только изменения.

6. Reason Code (внутри записей revokedCertificates)

Хотя формально это расширение записи, а не CRL, оно тесно связано.

OID: 2.5.29.21

Возможные причины отзыва:

  • keyCompromise
  • cACompromise
  • affiliationChanged
  • superseded
  • cessationOfOperation
  • certificateHold

ASN.1 структура CRL (упрощённо)

CertificateList ::= SEQUENCE {
  tbsCertList          TBSCertList,
  signatureAlgorithm   AlgorithmIdentifier,
  signatureValue       BIT STRING
}

TBSCertList ::= SEQUENCE {
  version              Version OPTIONAL,
  signature            AlgorithmIdentifier,
  issuer               Name,
  thisUpdate           Time,
  nextUpdate           Time OPTIONAL,
  revokedCertificates  SEQUENCE OF RevokedCertificate OPTIONAL,
  crlExtensions        [0] EXPLICIT Extensions OPTIONAL
}

Структура RevokedCertificate

Каждая запись в списке отзыва:

RevokedCertificate ::= SEQUENCE {
  userCertificate      CertificateSerialNumber,
  revocationDate       Time,
  crlEntryExtensions   Extensions OPTIONAL
}

Представление CRL в Jsrsasign

В Jsrsasign CRL обычно обрабатывается через ASN.1-парсер и объектную модель.

Типичный сценарий:

  • загрузка PEM/DER
  • парсинг ASN.1
  • доступ к полям через структуры JavaScript

Пример логической структуры:

  • tbsCertList.issuer
  • tbsCertList.revokedCertificates[]
  • tbsCertList.extensions

Особенности работы расширений в Jsrsasign

При разборе CRL библиотека:

  • декодирует ASN.1 последовательности
  • интерпретирует OID расширений
  • преобразует значения в удобные JS-объекты

Важно учитывать:

  • критические расширения должны обрабатываться обязательно
  • неизвестные некритические расширения могут игнорироваться
  • порядок расширений не гарантируется

Влияние структуры CRL на проверку сертификатов

При валидации сертификата проверяются:

  • наличие серийного номера в revokedCertificates
  • актуальность thisUpdate / nextUpdate
  • соответствие issuer
  • применимость CRL к конкретной цепочке сертификатов

Расширения влияют на:

  • выбор CRL (Issuing Distribution Point)
  • оптимизацию загрузки (Delta CRL)
  • проверку доверия к источнику (Authority Key Identifier)

Типичные ошибки при интерпретации CRL

Игнорирование nextUpdate

Приводит к использованию устаревших списков.

Неправильная обработка Delta CRL

Без применения базового CRL дельта-список теряет смысл.

Пропуск критических расширений

Может привести к неверной валидации цепочки доверия.

Ошибки в интерпретации DN issuer

Несоответствие CA и CRL делает проверку недостоверной.

Оглавление