Resumo

  • O projeto LAKE de 2 de novembro pede duas etiquetas para verificar o estado de um dispositivo. Em julho pedia quatro, porque o comando de começar a verificação tinha um número próprio em cada um dos dois modelos.
  • Agora quem decide o acesso envia o sinal 0xF5 na primeira mensagem; o dispositivo deve responder com uma proposta na segunda. As duas mensagens levam a mesma etiqueta do modelo escolhido.
  • TBD1 e TBD2 ainda são marcadores no projeto. O registro público da IANA não traz essas atribuições.

Um número na campainha e na pasta

Pense numa fechadura de rede que recebe uma instrução: peça ao dispositivo um retrato verificável de seu estado antes de lhe dar acesso. O projeto anterior dava um número à campainha e outro à pasta de provas em cada modelo. A revisão 07 elimina as duas linhas exclusivas da campainha. Sob BG ou PP, a mesma etiqueta pode trazer o sinal de partida, a proposta, o pedido e depois a evidência ou o resultado. O programa precisa acompanhar a conversa, não apenas ler a etiqueta.

O sinal de partida é o valor verdadeiro do formato CBOR, 0xF5, na primeira mensagem EDHOC. O dispositivo responde na segunda com uma proposta. Na verificação de antecedentes, a prova do dispositivo passa pelo controlador de acesso até o verificador. No modelo passaporte, o dispositivo entrega ao controlador um resultado já emitido pelo verificador. Se a rotina olha só para a etiqueta, a campainha pode virar uma falsa pasta de provas.

O texto reserva ao controlador de acesso a escolha do tipo de prova, segundo a política local. O dispositivo mede; o verificador avalia; o controlador decide se abre. A conta do registro encolheu, mas a responsabilidade ficou exatamente onde estava.

A lista de documentos LAKE mantém a proposta como Internet-Draft de grupo, estado I-D Exists. O registro EDHOC da IANA não mostra BG nem PP. Faltam a atribuição definitiva e testes públicos da nova sequência entre implementações.