Resumo

  • A RFC 9597 registra o parâmetro 15 para transportar um mapa de alegações CWT em cabeçalhos COSE, inclusive diante de payload cifrado, destacado ou não-CWT.
  • Uma alegação antecipada pode selecionar uma busca de chave, mas identidade, contexto e ação permanecem provisórios até a validação criptográfica e semântica.
  • Quando cabeçalho e payload repetem a mesma alegação, a regra normal exige igualdade; igualdade, porém, não comprova verdade, competência da chave, privacidade nem permissão.

O receptor vê o emissor antes de ver o conteúdo. Usa esse emissor para consultar um diretório, obtém chaves candidatas e separa capacidade de processamento. Só então verifica a assinatura. Se ela falhar, a pergunta importante não é apenas se o objeto foi rejeitado. É se a identidade provisória deixou algum efeito.

RFC 9597 padroniza a presença de alegações CWT no cabeçalho de qualquer estrutura COSE. O recurso atende objetos cifrados, assinaturas com conteúdo destacado e payloads que não são conjuntos CWT ou sequer CBOR. O padrão torna uma afirmação acessível mais cedo. Não lhe concede autoridade mais cedo.

Um mapa resolve a colisão, não a política

Parâmetros COSE e alegações CWT usam chaves numéricas compactas. Colocar cada alegação diretamente no cabeçalho misturaria dois espaços de registro. A RFC cria, por isso, um único parâmetro “CWT Claims”, rótulo 15, no registro COSE da IANA. Dentro dele há um mapa cujas chaves pertencem ao registro CWT.

A RFC 8392 define emissor, sujeito, audiência, expiração, início de validade, emissão e identificador. A RFC 8610 fornece a notação CDDL. Registro e esquema tornam os bytes interoperáveis; não dizem qual alegação é obrigatória num endpoint, quem pode afirmá-la ou qual ação ela autoriza.

O parâmetro pode acompanhar um payload que não seja CWT. Uma imagem ou firmware pode ser assinado e trazer emissor para descoberta de chave. Assim, a presença de um mapa CWT não identifica o conteúdo. O perfil local precisa preservar essa distinção.

Proteção criptográfica tem um escopo menor que confiança

A RFC 9052 separa mapas protegidos e não protegidos. A RFC 9597 recomenda colocar as alegações no protegido, para evitar maleabilidade, e permite uma única ocorrência entre ambos.

O receptor não deve presumir que a recomendação foi seguida. A política precisa decidir se rejeita rótulo 15 não protegido ou o aceita apenas como pista sem confiança. Sem regra explícita, um fallback de implementação passa a governar a fronteira.

Mesmo protegido, o mapa só fica vinculado à operação criptográfica e à chave. Resta saber se a chave tinha competência para esse emissor e classe de objeto, se a audiência inclui o serviço, se os tempos são válidos e se a aplicação autoriza o pedido.

A interpretação também precisa de proteção. Quando o contexto natural não é suficiente, RFC 9597 recomenda typ, da RFC 9596. O tipo escolhe o contrato de validação; o contrato dá sentido às alegações. Uma alegação protegida, lida sob um seletor maleável, não produz uma decisão protegida.

Descoberta de chave é uma escolha provisória

O emissor pode ser necessário para encontrar a chave usada na própria validação. A circularidade é legítima. O privilégio não é.

Antes de validar, a plataforma pode escolher um namespace de consulta, uma fila isolada ou um orçamento pequeno. Não deve criar definitivamente um tenant, popular cache compartilhado, escolher conta de cobrança, abrir busca ilimitada ou executar efeito externo.

O recibo provisório precisa conter bytes recebidos, localização protegida, valor exato, ramo escolhido, consulta e candidatos. O recibo final acrescenta resultado criptográfico, fonte da interpretação, versão de perfil, comparação com payload, audiência, tempo, política, ação e efeito.

Se a assinatura falhar, o sistema deve desfazer ou isolar o estado antecipado. A exigência da RFC é clara: decisões tentativas baseadas em informação ainda não segura devem ser confirmadas após o processamento criptográfico. Testes devem provocar busca bem-sucedida seguida de assinatura inválida e provar que identidade e caches provisórios não sobrevivem.

Esse é o papel da primazia do código em execução: a documentação promete confirmação; o registro executado prova que ela controlou o resultado.

Duas cópias pedem uma regra reconstruível

A RFC 7519 oferece mecanismo semelhante para JWT e JOSE. A RFC 9597 determina que alegações repetidas no cabeçalho e no payload de um CWT tenham valores idênticos, a menos que a aplicação defina processamento específico diferente.

A regra impede que um gateway encontre chaves para emissor A e o serviço autorize emissor B. Uma exceção precisa indicar qual componente lê cada cópia, qual proteção a cobre, por que a divergência é segura e qual versão de perfil estava ativa. Uma autorização genérica para “ser diferente” destrói a auditabilidade.

Igualdade não é verdade. Duas expirações iguais podem estar vencidas; duas audiências iguais podem excluir o endpoint; dois emissores iguais podem vir de chave incompetente. As práticas da RFC 8725 continuam necessárias depois da comparação.

O cabeçalho pode furar a confidencialidade

Uma alegação disponível antes da decriptação está fora do ciframento. Emissor pode revelar empresa; sujeito, pessoa ou dispositivo; audiência, serviço; identificador, correlação. Copiar tudo para facilitar suporte pode expor o que o payload cifrado deveria esconder.

A decisão correta começa pelo mínimo: qual único dado a tarefa antecipada exige? Quem o vê na rede, proxy, fila, log, trace, cache e erro? Por quanto tempo? Um domínio temporário de roteamento pode substituir sujeito estável? Validade criptográfica não é consentimento de divulgação.

A especificação inicial mínima e decisão local oferece a divisão adequada: contêiner e consistência no comum; finalidade, retenção, autoridade e ação no sistema que executa.

Payload destacado amplia a cadeia

COSE pode validar conteúdo transportado separadamente, mas RFC 9052 responsabiliza a aplicação por preservar os bytes. Um emissor correto não prova que o arquivo recuperado é o pretendido.

Guardar localizador, contexto de recuperação, bytes ou hash e resultado da ligação evita associar uma pista legítima ao conteúdo de outra transação. O recibo final deve dizer: a alegação ficou visível; este valor e esta interpretação foram protegidos; a cópia do payload cumpriu a regra; a política local autorizou; a ação e o efeito foram observados.

As camadas de realidade impedem comprimir toda essa sequência na palavra “confiável”.

Fontes