Данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).

В сфере PKI OID'ы имеют очень важное значение, хоть это далеко и не всегда очевидно для администраторов. Что такое OID? Это Object IDentifier (OID), который является как бы древовидным «инвентаризационным» номером объекта. В инфраструктуре PKI этими OID'ами обладают очень много типов объектов, например:

• Шаблоны сертификатов;
• Application Policies/Extended Key Usages (EKU);
• Issuance Policies/Certificate Policies;
• Certificate Practice Statement;
• алгоритмы криптографии
• и т.д.

Как они выглядят? OID'ы записываются с использованием десятично-точечной нотации, например: 1.3.6.1.5.5.7.3.1. Поскольку OID'ы являются древовидной структурой, то каждый элемент имеет какое-то значение. Схема дерева достаточно обширна и отобразить её всю весьма проблемно. Но существуют ресурсы, которые позволяют исследовать деревья стандартизированных OID'ов. Чтобы показать сложность этого дерева можно попробовать разобрать вышеуказанный OID:

• 1 — ISO assigned
• 3 — ISO Identified Organization
• 6 — US Department of Defense
• 1 — Internet
• 5 — Security
• 5 — Mechanisms
• 7 — PKIX
• 3 — id-kp, arc for extended key purpose OIDS
• 1 — id_kp_serverAuth

Вот так пройдясь по дереву OID'ов мы выяснили, что этот OID обозначает Server Authentication в Application Policies/EKU сертификатов. Вы можете самостоятельно поупражняться в разборе OID'ов с использованием этой странички: OID assignments from the top node. В принципе, вы должны уметь ориентироваться в стандартизированных OID'ах, которые используются в интернете.

Но это всё теория. На практике случается, что этих стандартизированных OID'ов недостаточно, чтобы описать конкретный объект. Для этого IANA выделила специальную ветвь OID'ов для частных организаций, которые могут в пределах этой ветви создавать свои собственные OID'ы. Корнем этой ветви является: 1.3.6.1.4.1.xxx.yyy

где xxx — уникальный OID, который выделяется конкретной частной организации и yyy — прозивольное пространство OID'ов, которые закреплены за конкретной организацией. Например, компании Microsoft выделено пространство с OID = 311 или полный путь дерева 1.3.6.1.4.1.311. Как видно по этой ссылке, все OID'ы которые используются только в продуктах Microsoft используют ветку 1.3.6.1.4.1.311. Когда вы создаёте новый шаблон сертификатов, Issuance Policy, Application Policy, Windows генерирует рандомный OID который находится в ветке, которой владеет Microsoft. В принципе, это не так страшно до тех пор, пока ваша или партнёрская компания не станут использовать сертификаты друг друга. Вот тогда могут начаться проблемы с валидацией сертификатов. Рассмотрим ситуацию:

Вы — компания «Дизайн табуреток» по производству приложений для макетирования и моделирования табуреток и эти приложения используются у партнёрской организации «Табуретки для всех». Каждое ваше приложение подписано сертификатом подписи. В обеих компаниях существуют строгие правила проверки и выдачи сертификатов подписи. В компании «Дизайн табуреток» используется 2 шаблона сертификатов подписи:

• Internal Code signing;
• External Code Signing.

Сертификаты на основе первого шаблона выдаются разработчикам на основе автоматической выдачи сертификатов (autoenrollment) для внутренних нужд. Когда приложение уже готово для поставки производителям табуреток (например, «Табуретки для всех»), то приложение окончательно подписывается руководителем разработок приложения. Поскольку это очень ответственный процесс, вы создали шаблон сертификатов с названием External Code Signing, но с более строгими требованиями:

• Сертификат выдаётся только уполномоченным лицам, предварительно подписавших документ, который регулирует ответственность за подписываемые этим сертификатом файлы;
• Для выдачи сертификата требуется явное одобрение менеджера CA;
• Сертификат должен храниться только на смарт-карте (в криптопровайдерах шаблона указан CSP поставщика смарт-карт, например Aladdin);
• Сертификат выдаётся только теми CA, которые отвечают 2-му уровню безопасности (что подразумевает использование HSM, раздельное управление службами CA и т.д.).

Поскольку оба шаблона выпускают сертификаты с одинаковым Application Policy/EKU (OID = 1.3.6.1.5.5.7.3.3), для определения различных порядков выдачи сертификатов вы создали два отдельных Issuance Policy, InternalIssuance (OID = 1.3.6.1.4.1.311.8888.8888) и ExternalIssuance (OID = 1.3.6.1.4.1.311.9999.9999) и назначили каждую политику выдачи соответствующему шаблону.

Как я уже гоорил, эти OID'ы будут генерироваться рандомно, но в пределах ветки принадлежащей Microsoft. Если у вас есть своё пространство OID'ов, то при создании новой политики выдачи отредактируйте OID так, чтобы он находился в пространстве OID'ов вашей компании.

Компания «Табуретки для всех» удовлетворена мерами безопасности, которые предприняты разработчиком программ макетирования табуреток для охраны сертификата подписи и готова доверять таким сертификатам. Но в силу ряда причин, компания не хочет доверять остальным сертификатам выданных в компании «Дизайн табуреток». Следовательно будет организовываться частичное доверие, которое именуется как Cross-certification или Qualified Subordination.

Как быть в такой ситуации? Поскольку оба шаблона выдают сертификаты с одинаковым Application Policy, то Certificate Trust List (CTL) здесь не подходит. Для этого компания «Табуретки для всех» создаёт у себя файл policy.inf, который помимо всего прочего содержит вот такие строчки:

[ApplicationPolicyStatementExtension]
Policies = CodeSigning
critical = false
[CodeSigning]
OID = 1.3.6.1.5.5.7.3.3
[PolicyStatementExtension]
Policies = ExternalIssuance
Critical = false
[ExternalIssuance]
OID = 1.3.6.1.4.1.311.9999.9999

и с использованием этого файла policy.inf создали сертификат на основе шаблона Cross Certification Authority. Вот что будет в этом сертификате:

Данный CrossCA сертификат выдан в CA компании «Табуретки для всех» на имя выдающего (Issuing CA) CA в компании «Дизайн табуреток». И данный сертификат публикуется в компании «Табуретки для всех» посредством групповых политик или через AD.

Вопрос создания Cross Certification Authority выходит за рамки данной статьи. Хоть тема создания Cross CA весьма интересна, но, к сожалению, на практике используется не так часто, как сами сертификаты. Поэтому рассказывать об этом нет смысла, наверное.

Таким образом, компания «Табуретки для всех» будет доверять только тем сертификатам компании «Дизайн табуреток», в расширениях которых содержится как минимум:

• Certificate Policies –> Policy Identifier = 1.3.6.1.4.1.311.9999.9999
• Application Polocies –> Policy Identifier = Code Signing

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

Как видите, OID'ы обретают особую важность когда ваши сертификаты начинают использоваться вне пределах вашей компании. Но здесь сразу возникает вопрос: а кто владеет OID = 1.3.6.1.4.1.311.9999.9999? Поскольку OID находится внутри ветки принадлежащей Microsoft, компания «Дизайн табуреток» по сути говоря ничего общего с этим OID'ом не имеет. Чтобы решить этот вопрос, как я уже говорил выше, каждая компания должна получить в IANA (или любой подобной организации) свой OID. В большинстве случаев это совершенно бесплатно (жадные дети могут радоваться :rock:) и оформить его можно, например, вот по этой ссылке: http://pen.iana.org/pen/PenApplication.page

После выполнения всех формальностей и подтверждения вы получите своё OID-пространство. Например, у меня номер 34658 и все мои собственные OID'ы (как Application Policies, CPS, Issuance Policies, etc) будут храниться в этом дереве: 1.3.6.1.4.1.34658. Скажем, мой CPS будет иметь OID = 1.3.6.1.4.1.34658.1 или 1.3.6.1.4.1.34658.222. Вместо последней цифры может быть что угодно, что придёт мне на ум, поскольку не существует нормативных документов, которые бы регулировали использования пространства OID'ов. Но в качестве образца можно посмотреть, как это сделано в Microsoft: http://support.microsoft.com/kb/287547. Чтобы выяснить владельца того или оного пространства, можно пройти по ссылке: http://www.iana.org/assignments/enterprise-numbers.

Таким образом нестандартные OID'ы в инфраструктуре PKI следует использовать только в пространстве OID'ов, которые выданы для вашей организации (кроме шаблонов сертификатов, чьи OID'ы менять не следует). Этим самым устраняются проблемы вопросов владения и ответственности за использование и содержимое сертификатов. Но у нас на сегодня остаётся последний вопрос: а где мы должны публиковать используемые нами OID'ы и их описания? Как правило все OID'ы, которые могут использоваться внутри и вне пределах вашей организации описываются в документе под названием Certificate Practice Statement или сокращённо CPS.

Собственно всё, что я хотел сегодня поведать про OID'ы. Если кому-то будет интересно, то можно будет посмотреть эту тему чуть плотнее.