что такое код oid

Что такое код oid

«Инфотекс Интернет Траст» — уполномоченный орган по ведению реестра идентификаторов объектов РФ (OID) в соответствии со стандартом ГОСТ Р ИСО/МЭК 9834-1-2009 и Соглашением между «Инфотекс Интернет Траст» и Росстандартом.

Для быстрого доступа к необходимой информации из российского дерева идентификаторов объектов (OID) воспользуйтесь фильтром по категории использования идентификаторов объектов и поиском по сайту. Для просмотра информации по организациям, выберите соответствующую рубрику.

Можно воспользоваться быстрым поиском, например: ИнфоТеКС Интернет Траст или 1.2.643.3.5

Российское дерево идентификаторов объектов OID

Как получить OID?

Регистрация объектного идентификатора (OID) производится по квалифицированному сертификату ключа электронной подписи, выпущенному на ответственного за регистрацию OID’а сотрудника юридического лица. Приобрести сертификат электронной подписи вы можете в компании Инфотекс Интернет Траст или в любом аккредитованном удостоверяющем центре. Сертификат не требует включения дополнительных OID’ов.

Для получения идентификатора объекта юридическое лицо должно зарегистрироваться в личном кабинете, заполнить и подписать заявку на получение OID электронной подписью. При этом на получение OID в каждой отдельной дуге российского дерева идентификаторов объектов должна быть заполнена отдельная заявка. Зарегистрировать организацию в личном кабинете может любое лицо организации. Подача же заявления осуществляется с электронной подписью ответственного за регистрацию объектного идентификатора лица.

Для регистрации в личном кабинете необходимо указать ИНН организации. После того как мы получим ваши данные из ЕГРЮЛ, вам на электронную почту придет приглашение в личный кабинет. После этого вы можете подать заявку. Заявка подписывается квалифицированным сертификатом электронной подписи. После проверки вашей заявки, вы получаете подписанное электронной подписью уведомление о присвоении объектного идентификатора. OID публикуется в реестре.

Об изменении реквизитов юридического лица заявитель должен сообщить в уполномоченный орган по регистрации через личный кабинет.

Срок рассмотрения заявления — 7 дней!

Новости

У Российского Реестра идентификаторов объектов юбилей — 15 лет со дня публикации первых записей в группах.

C 15.09.2015 по 17.09.2015 года в Санкт-Петербурге прошла XIII международная научно-практическая конференция «PKI.

Введена в эксплуатацию новая версия интернет-сайта по поддержке реестра идентификаторов объектов Российской Федерации.

© 2000 – 2021 Уполномоченный орган по регистрации идентификаторов объектов АО «ИнфоТеКС Интернет Траст»
127083, г. Москва, вн. тер. г. муниципальный округ Савеловский, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11.
Политика обработки персональных данных пользователей сайтов АО «ИнфоТеКС Интернет Траст»

ИНН не соответствует формату утвержденному в РФ! Завершить процесс регистрации вы сможете указав корректный ИНН вашей организации!

Источник

Реестр идентификаторов объектов (OID) Минздрава России

В 2001 году стартовал международный проект «Реестр идентификаторов объектов (Object Identifier, OID)», позволяющий в мировом масштабе однозначно идентифицировать любой реальный и виртуальный объект. Цель проекта — разработка, поддержание и развитие системы и правил однозначной идентификации объектов реального и виртуального мира в информационно-телекоммуникационном пространстве на основе описания древообразной структуры идентификации, называемой «Международное дерево идентификаторов объектов».

В рамках Международного проекта «Реестр OID» определены:

Проект реализуется совместно Международным союзом электросвязи (ITU-T, исследовательская группа 17) и Международной организацией по стандартизации (технический комитет 1/ исследовательский комитет 6 (ISO, JTC 1/SC 6)). Федеральное агентство по техническому регулированию и метрологии России (Росстандарт) уполномочило организацию ОАО «ИнфоТеКС Интернет Траст» вести российский национальный сегмент (корень Российской Федерации — 1.2.643) международного дерева идентификаторов объектов в соответствии со стандартом ГОСТ Р ИСО/МЭК 9834-1-2009.

Минздрав России на основании государственного задания уполномочил Институт вести идентификаторы объектов Минздрава России, назначаемые в рамках российского национального сегмента международного дерева идентификаторов объектов. По Положению «О порядке ведения Реестра идентификаторов объектов Минздрава РФ», выполнение этих функций Институт передал отделу регламентной службы ведения нормативно-справочной информации Минздрава России. Отдел также проводит обновление списка идентификаторов (OID), присвоенных справочникам Минздрава России, на официальном портале нормативно-справочной информации (НСИ).

Международное дерево идентификаторов объектов расположено в сети Интернет по адресу www.oid-info.com; основные положения проекта зафиксированы в рекомендациях серии X.660-X.670 (Rec. ITU-T X.660 and X.670 series) и идентичных им стандартах ИСО и приведены на сайте.

Российское дерево идентификаторов объектов, как составляющая часть мирового дерева, доступно по адресам: www.oid-info.com/get/1.2.643 и www.oid.iitrust.ru. В соответствии с ГОСТ 7.67 «Коды названий стран» (ИСО 3166-1) Российской Федерации присвоен код 643, двух символьное обозначение — RU. Российское дерево идентификаторов состоит из 9 дуг нижнего уровня, описывающих тематическое применение OID, и насчитывает около 500 объектов, зарегистрированных на российском уровне.

Международное дерево OID используется для однозначной идентификации объектов в целях:

Российское дерево включает:

Источник

Как читать MIB и OID

Содержание

Общая информация

Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB. [1]

Для начала кратко опишем некоторые важные термины протокола SNMP (Simple Network Managment Protocol):

Object Name — имя объекта, уникальная константа для всего MIB, однозначно соответствующая определённому OID.

MIB — это структурированный текстовый файл или несколько файлов, которые содержат информацию о всех объектах устройства. Объектом может быть какая-нибудь настройка или параметры системы. У каждого объекта есть свой набор полей, таких как тип данных, доступность (чтение, запись), статус (обязательный, необязательный), текстовое название настройки. Также объект может содержать другие объекты.

Есть стандартные MIB’ы, определяемые различными RFC и огромное множество MIB’ов от производителей оборудования, которые дополняют стандартные и могут быть взяты с сайтов этих компаний. Эти дополнения необходимы, чтобы описать специфические для устройства параметры. Можно также составить и свои MIB’ы, нигде их не регистрировать и успешно использовать.

Каждый объект в MIB имеет свой уникальный цифровой адрес OID и имя Object Name. SNMP менеджер, используя OID, способен считывать или устанавливать значение объекта. Например, адрес объекта (OID) содержащего наименование системы: 1.3.6.1.2.1.1.5, а его имя (object name): sysName. Так как всё общение между SNMP агентом устройства и SNMP менеджером (системой наблюдения или администратором) происходит через OID, то понимать, что они описывают, очень даже полезно. Имя объекта играет ту же роль в SNMP, что и DNS имя в ip сетях — более наглядное описательное представление набора чисел. Строго говоря в разных MIB’ах оно может представлять разные OID, хотя, те что описаны в RFC, по идее должны быть уникальными для всех.

Как читать OID

Вышеприведённый OID (1.3.6.1.2.1.1.5) для объекта sysName построен целиком на стандартном MIB, и будет существовать скорее всего на всех устройствах. Он читается так:

OID специфичного объекта для конкретного устройства, дополненный своими MIB’ами, будет значительно длиннее. Вот пример OID датчика температуры у первого вентилятора в Intel Modular Server: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.1. Первые 7 параметров из стандартных MIB’ов, остальные 10 из MIB’ов Intel. Четыре первых мы уже расшифровали выше, остальные поясняются следующим образом:

Вся описательная информация находится как раз в текстовых файлах MIB, поэтому давайте разберёмся как их читать.

Как читать MIB

При работе с удалённой системой по SNMP протоколу все запросы происходят через OID, отражающий положение объекта в дереве объектов MIB. Все OID системы можно получить просканировав устройство, например командой snmpwalk:

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

Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.

Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:

Строка в описании объекта fans

говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.

Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:

где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки «components OBJECT-IDENTITY» (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:

Далее находим и остальное:

Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16

Теперь можно узнать их значения, заодно выяснив и их количество:

По приведённому несложному алгоритму можно прочитать любой MIB, главное получить его, что, к сожалению, не всегда возможно.

Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и on-line (см. раздел Ссылки). Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь iReasoning MIB Browser, но не потому, что он лучше других, а просто я попробовал его первым и он мне вполне понравился.

Теперь, зная как читать MIB’ы и OID’ы администратору будет легче использовать и донастраивать системы мониторинга здоровья системы, такие как Zabbix, MRTG, PRTG, Cacti и т.п.

Источник

Объектные идентификаторы области использования ключа

Объектные идентификаторы (OID) определяют отношения, при осуществлении которых электронный документ, подписанный ЭЦП, будет иметь юридическое значение.

OID, зарегистрированные в Удостоверяющем центре, включаются состав следующих расширений сертификата ключа подписи: Key Usage (использование ключа), Extended Key Usage (расширенное использование ключа), Application Policy (политики применения сертификата).

В каждый сертификат издаваемый нашим Удостоверяющим центром включаются следующие OID:

Остальные объектные идентификаторы включаются в издаваемый сертификат на основании Заявления на изготовление сертификата ключа подписи.

Перечень объектных идентификаторов используемых в различных информационных системах

Текст ограниченной лицензии КриптоПро CSP

Ограниченная лицензия на использование любого экземпляра программы для ЭВМ СКЗИ «Крипто-Про CSP» версии 3.6 для использования с ключом электронной подписи (закрытым ключом электронной цифровой подписи) соответствующего сертификата ключа проверки электронной подписи (сертификата ключа подписи) жителями города Москвы, работниками органов исполнительной власти города Москвы и работниками иных учреждений и организаций, осуществляющих свою деятельность в интересах органов исполнительной власти города Москвы и/или участвующих в процессах оказания государственных услуг и/или исполнения государственных функций с использованием современных технологий

Источник

Что такое код oid

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

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

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

Вот так пройдясь по дереву 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 шаблона сертификатов подписи:

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

Поскольку оба шаблона выпускают сертификаты с одинаковым 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, который помимо всего прочего содержит вот такие строчки:

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

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

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

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

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

Как видите, 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’ы. Если кому-то будет интересно, то можно будет посмотреть эту тему чуть плотнее.

Источник