Summary

  • O draft-ietf-cose-hpke-27 foi publicado em 12 de setembro e continua no acompanhamento do diretor de área. É um Internet-Draft na trilha de padrões, não um RFC nem um perfil de implantação aprovado.
  • A presença de psk_id protegido seleciona o modo PSK; sua ausência leva ao modo Base. A criptografia chega ao detentor da chave privada receptora, mas o KEM não autentica o remetente.
  • kid identifica a chave do destinatário. Daniel Kade propõe um recibo restrito da autenticação e da autorização efetivamente usadas, sem PSK ou texto claro; a proposta é editorial, não normativa.

O êxito da abertura tem um alcance preciso

A revisão 27 chegou em 12 de setembro. O histórico do Datatracker registra o documento em AD Evaluation::AD Followup, depois da submissão à IESG para publicação na Standards Track. A mudança visível desta versão torna explícito que o HPKE exige uma fonte de aleatoriedade criptograficamente segura e que, em Key Encryption, a chave de conteúdo também deve ser gerada dessa forma.

O aperto do texto não encerra o processo. O registro atual ainda pode mudar, os números de IANA são provisórios e não existe um RFC resultante. O que já pode ser examinado é o significado operacional de um retorno bem-sucedido da função de abertura.

No modo Base, qualquer parte que conheça a chave pública do destinatário pode formar um objeto que o detentor da chave privada consiga abrir. O AEAD autentica o ciphertext e os dados associados sob a chave derivada; não atribui a encapsulação de chave pública a uma identidade organizacional. Confundir essas duas formas de “autenticação” cria uma autorização que a primitiva nunca ofereceu.

O formato de criptografia não decide sozinho a confiança

O texto define Integrated Encryption e Key Encryption. Na primeira, o HPKE protege diretamente o texto claro em COSE_Encrypt0, para um destinatário. Na segunda, uma chave de conteúdo protege a mensagem e o HPKE envolve essa chave na camada de destinatário, o que permite vários destinatários.

Cada identificador de algoritmo COSE solicitado no rascunho fixa o trio KEM, KDF e AEAD, além do formato em que pode ser usado. Isso dá uma semântica fechada ao número do algoritmo e reduz trocas silenciosas de componentes ou camadas.

O modo de autenticação fica em outro lugar. Com psk_id no cabeçalho protegido, vale mode_psk; sem ele, vale mode_base. O próprio rascunho diz que o modo não está indicado explicitamente na ciphersuite.

Dois objetos com o mesmo algoritmo podem, portanto, trazer garantias diferentes. No modo PSK, a abertura autentica posse do segredo compartilhado externo. No Base, o KEM não faz essa afirmação. Um log que guarda apenas o número do algoritmo perde a entrada que escolheu o caminho de confiança.

kid aponta para quem recebe

O uso de kid é recomendado para informar qual chave pública estática do destinatário o remetente escolheu. O receptor pode usá-lo para encontrar a chave privada correspondente durante uma rotação ou quando várias gerações estão ativas. O parâmetro não é a identidade de quem enviou.

A distribuição da chave pública está fora do escopo. Cabe à aplicação preservar sua origem, o tenant ao qual pertence e a vigência. Uma chave matematicamente válida, copiada para o contexto errado, ainda produz um objeto HPKE válido para esse contexto errado.

O psk_id também não é a PSK. O identificador fica protegido, enquanto o segredo entra externamente e não pode ser codificado no objeto. Provar posse desse segredo não define sozinho a pessoa, o serviço ou a permissão correspondente. O rascunho HPKE atual exige alta entropia e avisa que uma senha fraca não se torna uma PSK adequada por passar por uma função derivadora.

O contexto só protege o significado que a aplicação escolheu

Cabeçalhos protegidos e dados autenticados externos permitem ligar contexto ao ciphertext. Em Key Encryption, a Recipient_structure inclui de modo determinístico o algoritmo da camada seguinte, os cabeçalhos protegidos do destinatário e informações extras. Essa ligação mitiga substituição de algoritmo entre a camada que envolve a chave e a camada de conteúdo.

Ainda é o perfil de uso que decide se ali deve constar tenant, finalidade, validade, versão da política ou número da solicitação. Um campo vazio pode ser aceitável na gramática e insuficiente para a decisão local.

O HPKE é uma construção de baixo nível. Fora da ordenação dentro de um contexto, replay, downgrade, perda de mensagens e frescor pertencem ao protocolo que o incorpora. Um objeto de uso único pode passar pela verificação mais de uma vez. Impedir a repetição da ação exige estado fora da primitiva.

Há também a fronteira do ciphertext destacado. Uma assinatura ou MAC COSE aplicado depois não cobre automaticamente os bytes separados. O rascunho exige integridade para esse conteúdo. “Assinatura válida” não serve como evidência sem o registro do que foi assinado.

Base pode ser exatamente a política desejada

Uma caixa de envio confidencial e aberta a qualquer pessoa pode preferir o modo Base. Outro protocolo pode autenticar o remetente em uma camada separada. O documento cita COSE_Sign, COSE_Sign1, COSE_Mac e COSE_Mac0 como formas de acrescentar autenticação.

O problema não é permitir Base, mas chamá-lo de identidade verificada. O modo PSK tampouco encerra a governança: um único segredo pode representar um aparelho, uma frota ou uma equipe. Posse não informa automaticamente revogação, delegação nem autorização para uma ação específica.

A fronteira real aparece quando o resultado criptográfico manda fazer algo: aceitar uma configuração, executar um comando ou registrar um relatório. O sistema precisa separar proteção do conteúdo, autenticação da credencial e permissão conferida pela política.

Registrar por que a aplicação decidiu aceitar

Daniel Kade propõe um recibo de autenticação do remetente para cada objeto aceito. O registro incluiria versão do rascunho ou do perfil, Integrated ou Key Encryption, ciphersuite, modo HPKE efetivo, impressão digital da chave do destinatário e proveniência de distribuição. Para PSK, acrescentaria uma impressão unidirecional de psk_id, a versão não secreta da chave e seu estado de ciclo de vida. Para Base, apontaria a assinatura, MAC, canal ou identidade de aplicação verificada — ou declararia que o envio anônimo é permitido.

O recibo ligaria ainda o perfil de contexto protegido, o resultado de frescor e replay, a cobertura de conteúdo destacado, a versão da política de autorização e a decisão. Não guardaria PSK, texto claro nem identidade desnecessária. Um identificador opaco e hashes permitem revisão sem criar outro cofre de credenciais.

Esse recibo não é exigido pelo rascunho, pelo RFC 9052, pelo RFC 8937 ou pelo registro COSE da IANA. É a prova organizacional que o Policy Mirror de Heng Lu separa do resultado do mecanismo. A especificação inicial mínima recomenda um registro comum pequeno; a disciplina editorial de BTW impede transformar uma revisão em alegação de falha operacional.

Sources

  1. COSE HPKE, revisão 27
  2. COSE HPKE, revisão 26
  3. Registro atual no Datatracker
  4. Histórico do documento
  5. HPKE, revisão 04
  6. RFC 9052 — estruturas e processamento COSE
  7. RFC 8937 — melhorias de aleatoriedade
  8. Registro COSE da IANA
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists