Resumo

  • A RFC 9596 registra o parâmetro protegido typ, rótulo 16, para declarar o tipo do objeto COSE inteiro; o content type da RFC 9052 continua descrevendo apenas o payload ou ciphertext.
  • A biblioteca COSE repassa typ à aplicação sem interpretá-lo; o valor só reduz confusão quando a aplicação rejeita ausências e divergências e vincula cada tipo a validação, chave e autorização próprias.

Uma mensagem chega com assinatura válida e typ protegido igual ao esperado. O roteador técnico pode saber qual código chamar. O serviço ainda não sabe se a carga obedece ao perfil, se aquela chave podia emitir tal objeto ou se o efeito solicitado é permitido.

A RFC 9596 foi desenhada para esse ponto intermediário. Ela leva ao COSE a tipagem explícita conhecida do JOSE. Quando uma estrutura aceita várias classes de objeto, o tipo do envelope inteiro ajuda a não entregar uma delas ao validador da outra. A especificação, porém, não delega significado de negócio à biblioteca criptográfica.

O parâmetro é uma declaração protegida. A decisão pertence ao código que recebe e conhece o contexto.

O envelope não é o payload

A RFC 9052 já oferece o cabeçalho content type para identificar os dados no campo payload ou ciphertext. A RFC 9596 cria typ para a estrutura COSE completa. Reutilizar a sintaxe de tipo de mídia ou CoAP Content-Format não elimina a diferença entre as camadas.

Um resultado de atestação e um recibo podem ambos carregar CBOR. O parser interno vê a mesma família de codificação, mas o aplicativo precisa de contratos externos diferentes. Um pode exigir determinado emissor e audiência; outro pode exigir uma raiz de recibo, outra chave e nenhuma ação operacional.

typ admite um inteiro sem sinal do registro CoAP Content-Formats ou uma string de tipo de mídia, com parâmetros. O receptor deve guardar a representação exata, porque uma política pode distinguir parâmetros, aliases ou formas numéricas. Transformar tudo cedo em uma etiqueta amigável apaga o dado que orientou o despacho.

Uma auditoria completa registra tanto o tipo do objeto quanto o tipo da carga, com a posição e os bytes protegidos. Sem isso, “tipo conferido” vira uma frase sem sujeito.

Integridade impede edição silenciosa, não erro assinado

A RFC 9596 determina que typ não apareça em cabeçalhos não protegidos. Quando a construção COSE autentica o bloco protegido, um intermediário não consegue trocar a classe declarada sem invalidar a verificação.

Mas o próprio signatário pode declarar a classe errada. Pode usar um alias antigo, um tipo válido em outro endpoint, parâmetros não aceitos ou um payload incompatível. A assinatura conserva fielmente o erro.

A especificação deixa claro que implementações COSE ignoram o significado do parâmetro e apenas o passam à aplicação. O aplicativo que usa tipagem explícita deve rejeitar valores fora do conjunto esperado e também objetos sem tipo quando o perfil exige um.

Por isso, proteção não se mede pela presença do campo. Mede-se pelo comportamento diante do campo errado. Uma plataforma que registra typ e depois cai num handler genérico preserva o símbolo e perde a fronteira.

O validador precisa excluir a outra classe

A motivação vem da RFC 8725. Em JWT, um tipo de token pode ser apresentado onde outro era esperado. Tipos explícitos ajudam; regras de validação mutuamente exclusivas completam a defesa.

Imagine dois objetos COSE com tipos diferentes, mas as mesmas chaves sem restrição, a mesma audiência padrão e claims quase todos opcionais. Se ambos chegam à mesma autorização genérica, a etiqueta separa o caminho nominal e mantém sobreposta a superfície real de aceitação.

Cada tipo deve selecionar um contrato inteiro: estruturas COSE aceitas, cabeçalhos protegidos exigidos, content type do payload, claims, issuer, audience, finalidade da chave, validade, replay, rota e ação. O valor errado precisa falhar antes que uma camada compartilhada elimine sua identidade.

A RFC 8725 observa que usos legados podem ignorar typ. Logo, a migração não termina quando produtores adicionam o campo. Termina quando os receptores, identificados por versão, rejeitam casos negativos de forma observável.

Registro público e política local têm papéis distintos

A IANA registra typ sob o rótulo 16 e referencia os registros de Media Types e CoAP Content-Formats. Esse mecanismo coordena nomes e evita colisões. Não forma uma lista universal de confiança.

A IANA não sabe se um endpoint habilitou o tipo, se a chave tem finalidade adequada, se os parâmetros são permitidos ou se o conteúdo respeita o perfil. Um nome registrado é um fato de namespace. Autorização é um fato local.

A arquitetura deve separar o catálogo público, a política de aceitação versionada de cada rota e o recibo de cada decisão. Se “tipo conhecido” virar “tipo autorizado”, a equipe que administra o catálogo passa a controlar serviços que ela não opera.

É a diferença entre especificação inicial mínima e autoridade contínua. O padrão cria uma linguagem comum. Adoção voluntária é comprovada pelo código em execução, pelas rejeições e pela compatibilidade praticada.

Uma trilha que não atribui tudo à assinatura

O recibo operacional deve conter hash dos bytes recebidos, estrutura COSE, bytes do cabeçalho protegido, valor e forma exatos de typ, tipo do payload, endpoint, operação, conjunto esperado, versão de política, resultado criptográfico, chave e finalidade, parsing, claims obrigatórios, emissor, audiência, frescor, replay, decisão de autorização, handler e resultado.

A verificação criptográfica prova a relação entre chave e objeto. O tipo prova apenas a declaração no contexto esperado. O parser prova forma. O perfil prova semântica delimitada. A política de chave prova competência. A autorização decide a operação. O resultado revela o que ocorreu.

Cada equipe precisa assinar somente o recibo que consegue observar. A biblioteca COSE não pode declarar sucesso de negócio. O registro de mídia não pode declarar confiança na chave. O serviço não deve reescrever a história criptográfica quando recusa o pedido.

As camadas de realidade de docs/heng-lu-note.md preservam justamente essa ordem. O símbolo é útil quando aponta para validação executada; torna-se poder fictício quando recebe o crédito pelo efeito final.

Fontes