Resumo

  • O draft-birkholz-did-x509-03 valida uma cadeia fornecida em ordem folha-primeiro, usa o último certificado como âncora daquela execução e confere uma impressão digital não-folha e os predicados da folha.
  • Essa âncora algorítmica não entra automaticamente no repositório de confiança da parte verificadora. Uma política local ainda precisa aceitar a CA, o DID e o contexto.
  • Resolução, confiança, verificação da assinatura, autorização de finalidade, persistência e efeito externo precisam de recibos independentes. A revisão 03 é um Internet-Draft Informational de submissão independente, não um RFC nem um padrão do IETF.

Uma equipe recebe um artefato assinado, um DID e a cadeia de certificados. O software valida todas as ligações, encontra no caminho a impressão digital indicada e confirma que o certificado folha contém os atributos esperados. A tela mostra “identidade resolvida”. Minutos depois, alguém pergunta se aquela CA estava autorizada para a organização.

O log não sabe responder porque o sistema tratou uma âncora trazida pela própria mensagem como se fosse uma escolha institucional.

A revisão 03 do did:x509 fornece um mecanismo útil para evitar um registro persistente de documentos DID. O identificador descreve uma classe de certificados; a cadeia chega como evidência; o resolvedor deriva a chave da folha. A elegância dessa construção depende de não expandir o significado do sucesso. Coerência criptográfica e confiança da parte verificadora são fatos de camadas diferentes.

O identificador é uma regra de seleção

A forma básica começa por did:x509:0, seguida de algoritmo de impressão digital, impressão digital e pelo menos um predicado. SHA-256, SHA-384 e SHA-512 são aceitos. A impressão corresponde a um certificado não-folha — intermediário ou âncora — e os predicados são avaliados no certificado folha.

subject testa um subconjunto de atributos do nome do sujeito. san exige um e-mail, nome DNS ou URI. eku procura um OID de uso estendido. fulcio-issuer repõe o prefixo https:// e compara a extensão de emissor Fulcio, que deve existir e não ser crítica.

Assim, uma organização pode renovar o certificado folha sem mudar o DID. Mais de uma cadeia pode satisfazer a mesma identidade. A continuidade, contudo, é tão segura quanto a precisão dos predicados. Um subconjunto amplo de subject pode aceitar muitas folhas. Um SAN correspondente não concede controle operacional. Um EKU declara uma categoria de uso da chave; não autoriza uma pessoa a aprovar aquela implantação específica.

Há uma âncora para o cálculo e outra decisão para a instituição

O parâmetro x509chain carrega certificados DER completos em base64url, separados por vírgulas. A folha vem primeiro; o certificado tratado como raiz ou âncora vem por último. Menos de dois certificados deve resultar em falha.

O resolvedor executa a validação de caminho da RFC 5280. Isso envolve assinaturas, restrições, nomes, políticas, usos de chave, extensões críticas, algoritmos e o instante de validação. Depois ele compara a impressão do DID com um certificado não-folha, verifica todos os predicados e deriva um JWK da chave pública da folha.

O último certificado é uma trust anchor no vocabulário do algoritmo. Ele fecha o caminho para aquela execução. A política da parte verificadora pode, porém, nunca ter aceitado esse certificado. A aplicação precisa consultar seu próprio repositório, sua allowlist de DID ou impressão de CA, ou outra regra explicitamente administrada.

A RFC 9360 deixa o princípio claro para cadeias transportadas em COSE: certificados recebidos não podem atualizar silenciosamente as âncoras configuradas pela aplicação. Evidência apresentada pelo remetente não recebe o poder de nomear a autoridade que a julgará.

Recibo Afirmação válida Lacuna restante
DID analisado Versão, algoritmo, impressão e predicados têm forma correta Existe uma cadeia legítima correspondente?
Caminho validado A folha chega ao último certificado sob parâmetros definidos A parte verificadora confia nesse certificado?
Impressão e predicados A cadeia integra a classe descrita pelo DID A classe é adequada à finalidade?
Política local A CA ou o DID são aceitos nesse contexto A mensagem foi realmente assinada?
Assinatura Os bytes cobertos verificam com a chave resolvida O signatário pode ordenar a operação?
Autorização e commit Regra e registro permitem ator, ação e recurso O efeito alegado ocorreu fora do sistema?

A parte legível do DID não pode virar credencial

Os predicados aparecem na string. É tentador extrair uma organização, um domínio ou um e-mail e tomar uma decisão antes da resolução. A revisão 03 rejeita esse atalho. Antes da verificação contra a cadeia, os componentes são apenas texto controlado por quem montou o identificador.

Qualquer pessoa pode produzir uma string sintaticamente válida com um nome convincente. Só a cadeia verificada liga o texto a uma folha emitida. E apenas a política local transforma a CA dessa folha em fonte aceitável para uma finalidade. Pular qualquer uma dessas duas ligações cria um oráculo de identidade autodeclarada.

Validade depende de tempo, revogação e algoritmo

O método permite validar no tempo atual ou em um ponto relevante, como o momento da assinatura. Uma folha vencida hoje poderia ser válida quando o artefato foi criado. Um iat em JWT ou CWT, definidos pelas RFC 7519 e RFC 8392, não se torna relógio confiável por aparecer no token; integridade e política de aceitação precisam ser demonstradas.

A revogação é consultada se a aplicação exigir, por CRL, OCSP ou outro meio. Transparência de certificados, endossos e bloqueio de algoritmos fracos também podem entrar no julgamento. Um resultado sem horário, política de revogação, resposta utilizada e versão das regras não pode ser reproduzido.

Os modelos de recibos e transparência das RFC 9597 e RFC 9943 reforçam a diferença entre carregar prova e definir a autoridade que lhe dará consequência.

Ausência de registro não elimina governança

O método não oferece operação de atualização do documento DID nem autorização de atualização. Também não há operação de desativação. A criação é local e a resolução combina DID com a cadeia apresentada.

Revogar ou deixar vencer todas as folhas conhecidas pode tornar o DID inutilizável. Isso se parece com desativação, mas não tem garantia de irreversibilidade: uma CA capaz de emitir outra folha compatível pode restaurar a resolução. O poder real está no controle da CA, na largura dos predicados e nas políticas das partes verificadoras.

Quando várias cadeias satisfazem o DID, elas podem levar a chaves folhas diferentes. O arquivo de auditoria deve preservar a cadeia exata e o método de verificação usado em cada mensagem, não apenas o identificador estável.

Código em execução delimita a alegação

A revisão 03 descreve implementação da Microsoft e cita Nuts Foundation, assinatura, SCITT, CCF e ferramentas para contêineres confidenciais. O README da Microsoft, sua especificação e os vetores de teste são evidência concreta para testes.

O documento registra diferenças visíveis da implementação Nuts quanto a eku e a uma extensão SAN otherName. Essa divergência vale mais do que uma lista de adoção: aponta onde dois resolvedores podem selecionar conjuntos diferentes de certificados. As alegações de implementação são fornecidas por contribuidores; não equivalem a endosso do IETF.

A revisão 02 pretendia Standards Track. A 03 muda para Informational e amplia confiança, operações, resolução, privacidade e implementação. O Datatracker, o histórico e o anúncio do I-D delimitam o estado: trabalho em andamento e submissão independente, não padrão nem produto do IETF.

O DID Core do W3C e os registros de especificações DID oferecem o quadro geral de documentos e relações de verificação. Não alteram o estatuto desta proposta.

Um registro que preserve a causalidade

Guarde o DID exato e os bytes dos predicados; todos os certificados DER na ordem recebida; hash do pacote; resultado de construção e validação; tempo escolhido; decisões sobre nomes, políticas, restrições, usos, extensões e algoritmos; estado de revogação e transparência; certificado cuja impressão conferiu; resultado de cada predicado; regra local de confiança e sua versão; documento DID e JWK; objeto assinado e bytes cobertos; resultado da assinatura; autorização com ator, operação, recurso e validade; identificador do commit; e efeito observado.

Não transforme ausência em afirmação. Se revogação não era exigida, registre not_required_by_policy, não good. Se a âncora local não foi consultada, registre not_evaluated, não trusted.

A Minimum Initial Specification de Lu Heng sustenta uma camada comum mínima, sem capturar decisões futuras. Running-Code Primacy exige comparação entre implementações e efeitos. The Policy Mirror revela quem controla o repositório de confiança. Reality Layers impede que string, certificado, juízo, assinatura, autorização e resultado desapareçam num único estado.

Fontes