OID (Object Identifier) в контексте Distinguished Name (DN) представляет собой формализованную систему идентификации атрибутов субъекта сертификата в инфраструктуре X.509. В Jsrsasign работа с DN опирается на строгую ASN.1-модель, где каждый элемент имени имеет не только строковое представление, но и уникальный числовой идентификатор, позволяющий однозначно интерпретировать структуру имени в различных криптографических системах.
Distinguished Name представляет собой иерархический набор атрибутов, описывающих субъект или эмитента сертификата. Каждый атрибут в DN кодируется как пара:
В ASN.1 это выражается через конструкцию
AttributeTypeAndValue, где OID определяет семантику поля, а
значение задаёт конкретные данные.
DN формируется как последовательность таких пар, например:
Каждое из этих полей имеет свой стандартный OID, закреплённый в международных спецификациях X.500 / X.509.
В криптографических библиотеках, включая Jsrsasign, используется набор стандартных OID, определённых ITU-T и IETF.
2.5.4.32.5.4.62.5.4.102.5.4.112.5.4.72.5.4.82.5.4.92.5.4.52.5.4.12Эти OID являются основой большинства DN-структур в X.509 сертификатах.
Помимо классических атрибутов, в DN могут использоваться расширенные идентификаторы:
1.2.840.113549.1.9.10.9.2342.19200300.100.1.25Email Address исторически относится к PKCS#9 и часто встречается в пользовательских сертификатах, хотя в современных реализациях предпочтение отдаётся альтернативным механизмам через SAN (Subject Alternative Name).
В Jsrsasign DN обычно задаётся в виде массива или строки, где
библиотека выполняет преобразование в ASN.1 структуру
X500Name.
Пример логической структуры:
Внутренне Jsrsasign сопоставляет строковые ключи с соответствующими OID и формирует DER-последовательность.
Библиотека использует таблицу соответствий:
CN → 2.5.4.3O → 2.5.4.10OU → 2.5.4.11C → 2.5.4.6При отсутствии стандартного ключа возможно прямое использование OID, что важно при работе с нестандартными PKI-системами.
DN в Jsrsasign создаётся через объектную модель:
Логика формирования включает:
Каждый RDN может содержать один или несколько атрибутов, что позволяет формировать сложные DN с множественными значениями одного уровня.
OID кодируется в формате OBJECT IDENTIFIER согласно правилам DER:
Например:
2.5.4.3 (CN) преобразуется в бинарную ASN.1 структуру,
которая затем включается в AttributeTypeAndValue.
Jsrsasign скрывает эту сложность, предоставляя высокоуровневый API, но при анализе сертификатов важно понимать, что именно OID определяет тип поля, а не его строковое имя.
При парсинге сертификата Jsrsasign выполняет обратное преобразование:
Если OID неизвестен библиотеке, он остаётся в числовом виде, что важно при работе с кастомными расширениями корпоративных PKI.
В реальных системах DN может включать:
В таких случаях Jsrsasign позволяет использовать прямую запись OID:
CN → 1.2.3.4.5.6.7.8Значение при этом обрабатывается как обычный атрибут DN, без необходимости предопределённого алиаса.
Каждый OID связан не только с идентификатором, но и с типом ASN.1 значения:
Например:
Jsrsasign автоматически выбирает тип на основе содержания строки, но при необходимости можно контролировать кодирование вручную через ASN.1 примитивы.
OID в DN критичен для совместимости между:
Неправильное использование OID (например, подмена CN нестандартным идентификатором без корректного OID) приводит к тому, что сертификат может быть корректно подписан, но не распознан внешними системами.
Особенно это касается:
В цепочке сертификатов DN сравниваются между:
Сравнение происходит не по строкам, а по ASN.1 структурам, где OID играет ключевую роль. Даже одинаковые строки, но с разными OID, считаются различными атрибутами.
Внутренняя логика библиотеки сводится к следующим этапам:
При анализе сертификатов выполняется обратный процесс с восстановлением человекочитаемой формы.
Использование OID вместо строковых ключей обеспечивает:
DN в Jsrsasign следует этой модели, сохраняя соответствие стандартам X.500 и ASN.1 без отклонений от спецификации.