Resumo

  • A RFC 9734 registrou id-kp-imUri, OID 1.3.6.1.5.5.7.3.40, para certificados destinados a assinar credenciais de identidade de mensageria instantânea, sem recorrer às finalidades TLS genéricas.
  • A EKU restringe a finalidade da chave. O identificador da conta fica em subjectAltName; caminho de certificação, comparação com o identificador esperado, controle atual, status e autorização continuam separados.
  • No MLS, a chave pública do certificado precisa ser idêntica à chave de assinatura do LeafNode. Mesmo assim, o aplicativo e o Authentication Service ainda definem e validam quais identidades são aceitáveis.

Uma organização revoga o acesso de um aparelho, mas não consegue alcançar imediatamente todos os verificadores. O certificado ainda encadeia até uma raiz confiável, ainda não expirou e contém id-kp-imUri. O painel chama isso de identidade válida. O inventário de dispositivos chama o mesmo aparelho de retirado.

Não há contradição criptográfica. Há duas autoridades respondendo a perguntas diferentes.

A RFC 9734, publicada em fevereiro de 2025, define uma finalidade de chave para certificados de identidade de clientes de mensagens instantâneas. Organizações podem evitar id-kp-clientAuth e id-kp-serverAuth, reduzindo a chance de uma credencial emitida para mensagens ser aceita em outro protocolo.

A recomendação de não misturar essas EKUs genéricas com id-kp-imUri protege a especificidade. O efeito, porém, depende da emissão e do verificador. Um campo que ninguém aplica não estreita a superfície de confiança.

Finalidade e nome ocupam extensões diferentes

A RFC 5280 diz que Extended Key Usage indica as finalidades da chave pública certificada. Subject Alternative Name vincula identidades ao sujeito. Uma URI aparece como uniformResourceIdentifier e precisa ser absoluta.

Logo, id-kp-imUri não contém a conta. O URI im: apresentado não contém a política de admissão. Um caminho válido não contém a referência que o aplicativo queria comparar. Uma assinatura bem-sucedida prova posse da chave naquele momento, não controle permanente do cadastro do serviço.

A RFC 3860 define o esquema im: para identificar uma INSTANT INBOX e recomenda o URI do sujeito em subjectAltName para operações S/MIME de IM. O documento também afirma que sua abstração pressupõe entrega confiável e não oferece garantias de entrega na camada de aplicação. Endereço e resultado nunca foram o mesmo fato.

No XMPP, a separação reaparece. A RFC 6121 usa JIDs como identificadores, mas exige autorização própria para mudanças de roster e outras operações. Nomear o ator não concede a ele todos os verbos.

O número 40 coordena implementações

O registro SMI da IANA reserva o decimal 40 para id-kp-imUri. Essa atribuição evita colisões semânticas. Não é uma auditoria da CA, do desafio de conta ou do cliente que consumirá o certificado.

A extensão pode ser crítica ou não crítica, a critério do emissor. O aplicativo pode exigir a finalidade particular. Assim, é preciso medir tanto o perfil emitido quanto o comportamento negativo: certificados IM são recusados em autenticação TLS de cliente e servidor? Certificados TLS genéricos são recusados quando a entrada exige a finalidade IM? Uma EKU crítica desconhecida provoca falha?

Também é necessário procurar anyExtendedKeyUsage, finalidades genéricas adicionadas por compatibilidade e reutilização da mesma chave. A métrica de adoção só é honesta quando inclui as portas que permaneceram fechadas.

Caminho válido e conta esperada são algoritmos distintos

A validação do caminho processa assinaturas, datas, âncoras, restrições, políticas, Key Usage e EKU. Ela não cria o URI que o usuário ou serviço pretendia autenticar.

A RFC 9525 distingue identificadores apresentados pelo certificado e identificadores de referência esperados pelo cliente, no contexto de identidade de serviço. O vocabulário evita um erro comum: guardar apenas o nome apresentado e esquecer a pergunta feita.

Se o certificado apresenta dois URIs, a aplicação precisa escolher segundo uma regra. Se um alias foi transferido, a assinatura antiga não atualiza a realidade. Se a normalização altera caracteres ou domínios, a transformação precisa ser auditável. O recibo deve conter referência, valores apresentados, regra, cadeia, âncora, política, tempo, resultado e motivo.

MLS compõe a identidade em etapas

A RFC 9420 exige que a chave pública do certificado final em um X509Credential seja igual à signature_key do LeafNode. Isso liga o objeto de credencial à chave que assina no grupo.

O aplicativo ainda decide quais identificadores aceita. O Authentication Service verifica se a credencial representa legitimamente os identificadores apresentados e se eles autenticam as referências esperadas. Credenciais novas ou substituídas voltam a passar pela validação nos eventos de entrada e atualização.

Uma admissão tem, portanto, quatro resultados independentes: chave do certificado igual à do LeafNode; PKI e EKU aceitas; URI apresentado correspondente ao esperado; cliente autorizado para grupo, função e epoch. O OID participa do segundo resultado.

Uma conta ainda pode existir em vários dispositivos. A RFC 9420 reconhece que identificadores de aplicação podem não individualizar clientes, e um leaf index só vale dentro de um epoch. Onde o risco é por aparelho, a organização precisa preservar registro de dispositivo além do URI da conta.

O tempo separa emissão de uso

Uma conta é suspensa, um aparelho é perdido, um vínculo de trabalho termina ou um membro é removido. O certificado permanece estático.

A RFC 6960 define good, revoked e unknown no OCSP. good significa, no mínimo, que nenhum certificado com o serial consultado e dentro do intervalo aparece revogado. Não comprova necessariamente que o certificado foi emitido nem resume toda a validade. thisUpdate, nextUpdate e producedAt enquadram a informação no tempo.

O draft-barnes-mimi-identity-arch-02, citado pela RFC 9734, trata revogação como fluxo externo e discute certificados curtos, OCSP e CRLs. É um rascunho em andamento, não evidência de implantação. A fronteira, contudo, é real: uma credencial não carrega sozinha mudanças ocorridas depois da emissão.

O dossiê por trás do selo

Na emissão, registre URI pedido, método de prova de conta, autoridade, versão de política, prova de posse, subjectAltName, EKUs, serial e validade. Na validação, preserve referência, nomes apresentados, regra de comparação, cadeia, âncora, resultado de finalidade, fonte de status, frescor e política de falha. No MLS, guarde LeafNode, credential, decisão do Authentication Service, grupo, epoch, cliente e regra de entrada. O resultado de entrega só existe quando a camada correspondente o observou.

O texto, o XML, o registro editorial, os errata e o histórico IETF provam a origem do padrão, não seu uso por um produto.

A primazia do código em execução pergunta quais controles realmente rodaram. A especificação inicial mínima mantém o OID como coordenação estreita e deixa as decisões locais visíveis. As camadas de realidade impedem que registro, extensão, nome, autorização e resultado virem um único fato institucional.

A RFC 9734 não criou uma identidade universal. Criou uma forma de dizer com precisão para que uma chave foi certificada.

Fontes