Resumo

  • A RFC 9509 registra id-kp-jwt, id-kp-httpContentEncrypt e id-kp-oauthAccessTokenSigning para três usos que não tinham identificadores PKIX comuns no 5G.
  • O 3GPP admite um certificado para cada finalidade ou um certificado com várias finalidades; a escolha altera o alcance de comprometimento, renovação e revogação.
  • O EKU não substitui confiança inicial, identidade da NF, KU, processamento JOSE, claims, política de autorização nem prova da execução do serviço.

Uma carteira de certificados costuma ser avaliada pelo custo de operação: quantas chaves, quantas renovações, quantos alertas. Essa conta omite a pergunta mais importante. Se uma chave cair, quais poderes caem com ela? No 5G Service Based Architecture, juntar tarefas pode reduzir objetos e aumentar simultaneamente o raio de uma falha.

A RFC 9509 foi publicada em março de 2024 como Proposed Standard, conforme a página do RFC Editor e o registro do Datatracker. O registro SMI da IANA mostra as atribuições: 37 para id-kp-jwt, 38 para id-kp-httpContentEncrypt e 39 para id-kp-oauthAccessTokenSigning.

O primeiro identifica a validação de assinatura JWS em um JWT, como a Client Credentials Assertion. O segundo identifica o uso de JWE para conteúdo JSON em HTTP, inclusive o tratamento da chave de conteúdo entre SEPPs. O terceiro cobre a assinatura de tokens do fluxo OAuth 2.0. Os EKUs de TLS cliente e servidor continuam separados.

Essa taxonomia reduz um risco concreto: uma NF consumidora não deve parecer produtora só porque ambas recebem certificados do operador. Uma chave autorizada para TLS também não deve assinar uma CCA por simples capacidade matemática. Por isso a RFC relaciona finalidade e Key Usage: trabalhos de assinatura exigem KU de assinatura; o exemplo JWE de transporte de chave exige keyEncipherment.

A decisão local está na combinação

A RFC 5280 determina que KU e EKU, quando presentes, sejam satisfeitos em conjunto. A RFC 9509 não impede outros EKUs no mesmo certificado. A política de propósitos permitidos e excluídos da RFC 9336 pode rejeitar combinações, ausência de EKU e anyExtendedKeyUsage.

A atual 3GPP TS 33.310 V19.5.0 declara a escolha: a implementação pode adotar um certificado por finalidade ou um certificado com múltiplas finalidades, tanto para confiança inicial quanto para o certificado final da NF.

Separar credenciais limita a autoridade de cada chave. Revogar a assinatura de CCA não precisa derrubar TLS; expor uma chave de JWE não entrega assinatura de token. Em troca, aumentam inscrição, armazenamento, distribuição, renovação, expiração, revogação e configuração de verificadores.

O certificado multifinalidade diminui a contagem, porém concentra trabalhos numa chave, numa cadeia e num evento de revogação. Uma troca urgente causada por uma finalidade pode parar outras. Essa consequência não é recomendação universal de topologia; é motivo para registrar quem aceitou o acoplamento.

Finalidade e identidade não são intercambiáveis

TS 33.310 começa com confiança inicial por certificado OAM, parâmetros assinados do perfil da NF ou chave inicial de autenticação. A RA/CA verifica prova de posse, NF Instance ID e, quando aplicável, NF type. Se a confiança inicial contém EKU, a finalidade do pedido pode ser comparada antes da emissão final.

Logo, id-kp-jwt não identifica a NF. Ele descreve um uso certificado. A identidade em subjectAltName, o caminho efetivamente aceito, a situação de revogação e o expediente de inscrição permanecem provas separadas.

Em operação, a 3GPP TS 33.501 V19.5.0 define CCA como JWT assinado pela NF consumidora. O receptor verifica JWS, identidade e tempo. No OAuth, o NRF é servidor de autorização, a consumidora é cliente e a produtora é servidor de recursos. A produtora confere emissor permitido, assinatura, sujeito, audiência, identificadores de slice ou conjunto quando presentes, scope, recursos e ações adicionais, expiração e, se necessário, coerência entre CCA e certificado TLS. O serviço só é executado depois.

A TS 29.500 detalha as interfaces baseadas em serviços; a TS 29.573 trata interconexão PLMN e SEPP. Um EKU de criptografia não comprova que um JSON específico era permitido, chegou, foi decifrado ou produziu efeito.

Descoberta e revogação podem divergir

TS 33.310 observa que o NRF pode devolver uma produtora cujo certificado foi revogado sem que o repositório ainda saiba. O estado criptográfico e o estado de descoberta não são equivalentes. Um recibo útil registra confiança inicial, NF e tipo, certificado, chave e cadeia, KU/EKU, combinações, algoritmo e cabeçalhos JOSE, claims, versão da política, prova de revogação, requisição, resposta e telemetria.

A finalidade também pode ficar visível. TLS 1.2 pode expor certificados; TLS 1.3 protege suas mensagens após ServerHello; Certificate Transparency pode tornar público um certificado confiável. Isso revela preparação, não execução.

A lente editorial é explícita: primazia do código em execução, camadas de realidade e especificação inicial mínima com decisão local. O registro fornece uma língua comum; autoridade e resultado continuam na implementação observável.