Resumo

  • kid é um valor não estruturado e não exclusivo que reduz o conjunto de chaves candidatas em COSE; ele não é impressão digital, identidade de dispositivo nem autorização.
  • A trilha verificável mantém o escopo da consulta, todos os candidatos, a impressão da chave que validou, o conteúdo protegido, o vínculo de identidade, a política e o resultado da aplicação.

Um verificador recebe um COSE_Sign1 com kid = 0x19 no cabeçalho não protegido. O armazenamento local devolve duas chaves. Uma pertence à janela de transição que ainda aceita objetos antigos; outra foi provisionada no mesmo sistema para outro domínio. Só a segunda valida a assinatura.

Se o registro final disser apenas “0x19 validado”, a informação mais importante desapareceu. Não se sabe qual conjunto foi consultado, quais chaves estavam nele, qual impressão venceu nem que regra permitiu usar o resultado. Uma dica de busca passou a representar o signatário inteiro.

O exemplo é construído, não um relato de falha real. Ele serve para mostrar que a ambiguidade pode ser compatível com a norma, enquanto a falsa certeza nasce no modelo operacional.

Um resultado de busca, não uma chave universal

A RFC 9052 define estruturas e processamento atuais de COSE. O parâmetro kid ocupa o rótulo inteiro 4 e carrega uma cadeia de bytes. Seu conteúdo fornece uma entrada para localizar a chave criptográfica necessária e pode ser comparado ao membro kid de COSE_Key.

A norma proíbe pressupor unicidade. Mais de uma chave pode usar o mesmo valor, de modo que todas as associadas talvez precisem ser testadas. A composição interna do valor também não é padronizada. Em COSE_Key, ele pode ser escolhido por uma pessoa ou calculado a partir da parte pública, mas ainda assim aparecer em objetos de chaves diferentes.

A consulta correta precisa de jurisdição: aplicação, emissor ou tenant, versão do key store, horário e bytes recebidos. Ela produz um conjunto de candidatos. A impressão completa da chave que passa pela verificação surge depois e não pode ser reconstruída com segurança a partir do nome curto.

O registro COSE da IANA mantém kid como identificador binário de chave no rótulo 4. Há também uma entrada separada para kid context. Nem todo perfil usa esse segundo campo, mas o registro não confunde contexto com identificador.

Estar fora da proteção é parte do contrato

Objetos COSE carregam conjuntos de parâmetros protegidos e não protegidos. O primeiro entra na construção autenticada. O segundo acompanha o objeto sem receber automaticamente essa garantia. Uma tela que mistura os dois já perdeu uma propriedade do protocolo.

RFC 9052 chama kid de pista sobre qual chave usar e afirma que ele não é um campo crítico de segurança. Por isso, pode ficar no cabeçalho não protegido. A consequência não é confiar nele; é impedir que a decisão de segurança dependa dele.

Alterar o valor pode gerar custo, ampliar o conjunto, consultar o namespace errado ou confundir auditoria. Não cria por si só uma assinatura válida sob outra chave. O verificador continua obrigado a usar uma chave real sobre os bytes exatos. Limites de consulta, isolamento por tenant e histórico de tentativas tratam os riscos operacionais sem inventar autenticidade para o rótulo.

O objeto da assinatura tem fronteiras

Para assinaturas, COSE forma Sig_structure com o contexto, os parâmetros protegidos do corpo, os parâmetros protegidos do signatário quando existentes, dados autenticados externos e o payload completo. A codificação vira ToBeSigned, entregue ao algoritmo junto com a chave e a assinatura.

O recibo precisa guardar o tipo de estrutura, bytes dos cabeçalhos protegidos, regra de formação de external_aad, hash do payload e impressão de cada chave tentada. Falhas de parsing, mapas malformados e parâmetros críticos desconhecidos também merecem registro: podem encerrar o processamento antes da verificação matemática.

“Assinatura válida” descreve esse conjunto preciso. Não autentica retroativamente todo campo exibido no painel. Quando kid vem da parte não protegida, o layout deve mostrar a separação.

A aplicação ainda deve identificar e autorizar

Depois da validação criptográfica, RFC 9052 exige que a aplicação verifique se a chave está corretamente associada à identidade signatária e se essa identidade tem autorização antes de executar ações.

Certificado, atestação, recibo de provisionamento ou cadastro local podem sustentar o primeiro vínculo. Função, recurso, finalidade, instante e versão da política governam o segundo. Uma chave pode validar um documento histórico depois de perder permissão para emitir comandos novos. Duas chaves com o mesmo kid podem ter períodos e usos diferentes.

Há mais uma fronteira: decisão não é efeito. A autorização pode aprovar algo que a aplicação não consegue confirmar, e um commit interno não prova que o equipamento externo mudou. Cada transição precisa do próprio recibo.

ACE usa o índice sem transformá-lo em acesso

A seção de perfis da RFC 9052 deixa cada aplicação escolher estruturas, serviços, parâmetros, algoritmos e formas de negociação. COSE descreve o mecanismo criptográfico; o protocolo que o emprega define sua política.

Na RFC 9200, o ACE OAuth aplica essa divisão a ambientes restritos. Um exemplo de resposta do servidor de autorização inclui uma COSE_Key de prova de posse e alerta que kid serve apenas para simplificar indexação e recuperação. Sua unicidade não deve ser presumida nem no domínio do cliente nem no Resource Server.

Mesmo dentro de autorização, a pista não contém o direito. O registro deve acrescentar perfil e versão, servidor ou emissor, cliente, audience, Resource Server, uso permitido da chave e decisão de política.

A autoria de Schaad é evidência delimitada

Jim Schaad escreveu a especificação COSE original de 2017, a RFC 8152. A RFC 9052, também assinada como J. Schaad, depois substituiu a parte de estruturas e processo; RFC 9053 separou os algoritmos. O perfil do IETF Datatracker situa esses documentos em sua trajetória de RFCs.

São textos de consenso da IETF, não decretos individuais. A autoria não prova que uma implementação existe nem concede controle sobre sua segurança. Uma homenagem da Oregon Wine Press publicou a fotografia creditada usada apenas para preservar a identidade visual no retrato editorial desta matéria. O cenário da vinícola não é fonte técnica.

A lista dos que falharam também importa

O primeiro registro descreve o objeto recebido: hash, estrutura COSE, cabeçalhos protegidos e não protegidos, dados externos e referência do payload. A consulta vira outro objeto com namespace, versão do armazenamento, horário, kid original e candidatos completos.

Cada chave mantém impressão, proveniência, validade, operações permitidas e resultado. A que passa aponta para o hash de ToBeSigned. Só então entram o vínculo de identidade, a autorização e o recibo da ação.

Os candidatos rejeitados explicam a rotação e as diferenças entre verificadores. Apagá-los faz parecer que o rótulo sempre teve uma única resposta. Preservá-los permite uma frase honesta por etapa: esta chave verificou estes bytes; esta evidência ligou a chave a esta identidade; esta política permitiu ou negou a ação; este efeito foi observado.

Fontes