Кратко

  • RFC 9734 зарегистрировал id-kp-imUri, OID 1.3.6.1.5.5.7.3.40, для сертификатов, ключ которых предназначен для подписания удостоверений личности клиента мгновенных сообщений, а не для общей TLS-аутентификации.
  • EKU отвечает за назначение ключа. Идентификатор аккаунта находится в subjectAltName; путь доверия, сравнение с ожидаемым именем, текущий контроль, отзыв и прикладное разрешение остаются отдельными решениями.
  • В MLS открытый ключ конечного сертификата должен совпадать с ключом подписи LeafNode. Но допустимые идентификаторы всё равно определяет приложение, а проверяет Authentication Service.

После ротации дежурства старый ноутбук сохраняет сертификат и закрытый ключ. Новый ноутбук получает своё удостоверение с тем же служебным URI. Обе цепочки действительны, в обеих есть id-kp-imUri. Если система допускает оба устройства, это не следствие RFC — это отсутствие отдельной политики устройств.

RFC 9734, опубликованный в феврале 2025 года, вводит специальное расширенное назначение ключа для удостоверений IM-клиентов. Общие id-kp-clientAuth и id-kp-serverAuth увеличивают риск того, что сертификат для сообщений примут в другом протоколе. Поэтому издателям не рекомендуется объединять их с id-kp-imUri.

Новая OID сужает допустимый коридор. Она не выбирает аккаунт и не утверждает, что предъявившее сертификат устройство всё ещё имеет право действовать.

В сертификате назначение и имя разделены

RFC 5280 определяет Extended Key Usage как перечень назначений сертифицированного открытого ключа. Subject Alternative Name связывает с субъектом идентификаторы; URI кодируется как uniformResourceIdentifier.

Поэтому id-kp-imUri и представленный в subjectAltName URI im: — разные утверждения. Первое ограничивает применение ключа. Второе сообщает имя, которое издатель связал с субъектом по своей процедуре. Валидный путь подтверждает выбранную PKI-цепочку. Проверка подписи подтверждает владение ключом в момент испытания.

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

RFC 3860 определяет im: URI как идентификатор INSTANT INBOX и рекомендует помещать URI субъекта в subjectAltName для S/MIME-операций IM. Одновременно документ не предоставляет собственного подтверждения доставки на прикладном уровне. Адрес и результат различались уже в исходной модели.

RFC 6121 показывает то же для XMPP: JID идентифицирует элемент, но изменение roster и другие действия требуют самостоятельной авторизации. Имя — вход политики, а не готовое разрешение.

IANA координирует значение номера

Реестр SMI IANA закрепляет номер 40 за id-kp-imUri в ветви PKIX. Это обеспечивает совместимое толкование. Реестр не проверяет владельца конкретного аккаунта или качество конкретной CA.

Издатель может сделать EKU критической или некритической. Приложение может требовать конкретное назначение. Контроль возникает только тогда, когда неверный профиль отвергается.

Нужно измерять не только наличие OID, но и смешанные clientAuth, serverAuth, anyExtendedKeyUsage, корректную обработку критических расширений и повторное использование ключа. В отрицательных тестах IM-сертификат не должен проходить как общий TLS-клиент или сервер, а общий TLS-сертификат — как IM-удостоверение там, где профиль обязателен.

Валидный путь не хранит ожидаемое имя

Алгоритм пути проверяет подписи, сроки, якоря, ограничения, политики, Key Usage и EKU. Он не знает, какой URI собиралось аутентифицировать приложение.

RFC 9525 в области идентичности сервисов различает предъявленные сертификатом идентификаторы и эталонный идентификатор, ожидаемый клиентом. Эта модель полезна и здесь: сравнение невозможно воспроизвести, если сохранена только предъявленная сторона.

В сертификате может быть несколько URI. Псевдоним может перейти другому владельцу. Нормализация может изменить строку. Журнал должен содержать эталон, предъявленные значения, правило сравнения, якорь, политику, время, результат и причину — а не одну строку «цепочка верна».

MLS добавляет точную привязку ключа

RFC 9420 требует, чтобы открытый ключ конечного сертификата в X509Credential был идентичен signature_key в LeafNode. Это исключает ситуацию, когда участник предъявляет один сертификат, а подписывает групповым ключом без связи с ним.

Однако приложение само определяет приемлемые эталонные идентификаторы. Authentication Service проверяет законную связь предъявленных имён с credential, затем их соответствие ожидаемым именам. Новые и заменённые credentials проверяются в установленных событиях добавления и обновления.

У решения о допуске есть как минимум четыре отдельных квитанции: ключ сертификата совпал с LeafNode; цепочка и IM-EKU приняты; предъявленный URI совпал с ожидаемым; конкретному клиенту разрешены группа, роль и epoch. OID участвует только во второй.

Один аккаунт может обслуживать несколько устройств. RFC 9420 прямо отмечает, что прикладной идентификатор не обязан уникально определять клиент, а leaf index действует лишь в одном epoch. Для различения управляемого ноутбука, личного телефона и бота нужна отдельная координата устройства.

После выпуска состояние продолжает меняться

Аккаунт блокируют, устройство теряют, трудовые отношения заканчиваются, участника удаляют. Статический сертификат не переписывает себя.

RFC 6960 задаёт ответы OCSP good, revoked и unknown. Минимальный смысл good: сертификат с запрошенным номером в периоде действия не значится отозванным. Это не обязательно подтверждает выпуск или полную действительность. thisUpdate, nextUpdate и producedAt ограничивают утверждение во времени.

draft-barnes-mimi-identity-arch-02, на который ссылается RFC 9734, рассматривает короткие сертификаты, OCSP и CRL как варианты отдельного потока статуса для сквозной идентичности. Это незавершённый проект, а не доказательство внедрения. Но граница верна: изменения после выпуска приходят извне сертификата.

Вернуть зелёному значку его исходные данные

При выпуске нужны запрошенный URI, метод доказательства аккаунта, проверяющая сторона, версия политики, владение ключом, subjectAltName, EKU, серийный номер и срок. При проверке — эталон, предъявленные имена, правило, цепочка, якорь, назначение, источник статуса, свежесть и режим отказа. Для MLS — LeafNode, fingerprint credential, решение Authentication Service, группа, epoch, клиент и правило допуска. Доставка подтверждает только наблюдавшийся этап.

Канонические текст и XML, карточка RFC Editor, errata и история IETF устанавливают происхождение стандарта, но не его развёртывание.

Принцип Heng Lu о первичности работающего кода требует показать реально выполненные проверки. Минимальная начальная спецификация оставляет общий слой узким, а локальные решения видимыми. Разделение слоёв реальности не позволяет превратить номер, расширение, имя, полномочие и результат в один факт.

RFC 9734 не увеличил обещание сертификата. Он сделал одно обещание точнее.

Источники