Кратко

  • RFC 9509 регистрирует id-kp-jwt, id-kp-httpContentEncrypt и id-kp-oauthAccessTokenSigning для трёх разных задач, которым не хватало общих PKIX-идентификаторов.
  • 3GPP допускает отдельный сертификат для каждой цели или один сертификат с несколькими целями; эти варианты создают разный радиус компрометации, обновления и отзыва.
  • EKU не заменяет начальное доверие, идентичность NF, KU, обработку JOSE, проверку claims, авторизацию и доказательство выполненной сервисной операции.

Архитектура сертификатов становится видна в момент отзыва. Если ключ больше нельзя использовать для подписи Client Credentials Assertion, должен ли тот же экземпляр потерять TLS-идентичность? Если в одном сертификате объединены несколько назначений, ответ может быть продиктован связностью ключей, а не намерением владельца сервиса.

RFC 9509 опубликована в марте 2024 года как Proposed Standard. Это подтверждают страница RFC Editor и запись IETF Datatracker. В действующем реестре SMI IANA номер 37 соответствует id-kp-jwt, 38 — id-kp-httpContentEncrypt, 39 — id-kp-oauthAccessTokenSigning.

Первое назначение относится к проверке подписи JWS над JWT, включая CCA. Второе — к защите HTTP JSON через JWE, например между SEPP. Третье — к подписи токенов доступа в OAuth 2.0. Существующие назначения TLS-клиента и сервера остаются отдельными.

Такая детализация предотвращает неявное наследование полномочий. Сертификат TLS-клиента у NF-потребителя не должен разрешать подпись CCA только потому, что закрытый ключ способен подписывать. Потребитель также не превращается в производителя из-за общей PKI оператора. RFC 9509 связывает назначение с Key Usage: для подписи нужна соответствующая KU, для примера переноса ключа JWE — keyEncipherment.

Один сертификат или несколько — это политика

RFC 5280 требует одновременно учитывать KU и EKU, если присутствуют обе. RFC 9509 не запрещает дополнительные EKU. Модель разрешённых и исключённых целей из RFC 9336 позволяет проверяющей стороне запретить комбинацию, отсутствие EKU или anyExtendedKeyUsage.

Действующая 3GPP TS 33.310 V19.5.0 прямо оставляет два варианта: отдельный сертификат для каждой цели либо один сертификат с несколькими целями. Выбор действует и для начального доверия, и для конечного сертификата 5G Core NF.

Разделение сужает полномочия ключа. Отзыв сертификата CCA необязательно отключает TLS; утечка ключа JWE не даёт подпись OAuth-токенов. Цена — больше процедур регистрации, ключей, цепочек, владельцев обновления, сроков, каналов отзыва и настроек проверяющих систем.

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

Назначение не удостоверяет экземпляр NF

TS 33.310 начинает с начального доверия: сертификата OAM, подписанных параметров профиля NF или Initial Authentication Key. Операторская RA/CA проверяет доказательство владения ключом, NF Instance ID и при необходимости NF type. Если EKU присутствует в начальном доверии, его можно сопоставить с запросом до выпуска конечного сертификата.

Поэтому id-kp-jwt описывает допустимую работу сертифицированного ключа, но не идентифицирует экземпляр. Идентификатор в subjectAltName, построенный путь, статус отзыва и данные регистрации отвечают на другие вопросы.

На рабочем контуре 3GPP TS 33.501 V19.5.0 добавляет следующие проверки. CCA — JWT, подписанный NF-потребителем; получатель проверяет JWS, идентичность и время. В OAuth NRF является сервером авторизации, потребитель — клиентом, производитель — сервером ресурсов. Производитель проверяет разрешённого issuer, подпись, subject, audience, идентификаторы slice или service set, scope, дополнительные ресурсы и действия, срок, а иногда согласованность с CCA и TLS-идентичностью. Только затем выполняется сервисный запрос.

3GPP TS 29.500 описывает сервисные интерфейсы, а TS 29.573 — межсетевой PLMN-контекст и SEPP. EKU шифрования не доказывает, что конкретный JSON разрешён, доставлен, расшифрован или применён.

Discovery может отстать от отзыва

TS 33.310 отмечает, что NRF способен вернуть производителя с уже отозванным сертификатом, если ещё не знает об отзыве. Состояние сертификата и состояние discovery различны. Полный журнал сохраняет способ начального доверия, NF и тип, сертификат, ключ и цепочку, KU/EKU, комбинации, алгоритм и заголовки JOSE, claims, версию политики, доказательство отзыва, запрос, ответ и телеметрию.

Назначение может быть заметно внешнему наблюдателю. TLS 1.2 может передавать сертификат открыто; TLS 1.3 защищает сообщения после ServerHello; Certificate Transparency публикует сведения о публично доверенных сертификатах. Видна подготовленная возможность, но не факт её использования.

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