Resumo

  • draft-ietf-rats-epoch-markers-05 permite que uma Epoch Bell emita marcadores reutilizáveis, dando a atores distribuídos uma referência limitada de frescor sem exigir hora civil confiável em cada attester.
  • Uma assinatura válida autentica o marcador e a chave da Bell; não comprova entrega simultânea, unicidade por sessão, correção do relógio ou o instante de medição da evidência.
  • O verifier precisa guardar um recibo de junção com identidade e tipo da Bell, rota, horário local de recepção, nonce, janela, estado antirreplay e versão da política aplicada.

Frescor é uma relação operacional

Perguntar se uma evidência é recente não equivale a ler um horário. Há o momento em que o estado foi medido, aquele em que a evidência foi produzida, o transporte, a avaliação e a decisão do relying party. Um relógio confiável posiciona eventos. Um desafio aleatório liga uma resposta a uma solicitação. Equipamentos restritos nem sempre têm esse relógio, e arquiteturas com intermediários nem sempre permitem desafio direto.

A Epoch Bell oferece um ritmo comum. Ela emite Epoch Markers, e o attester insere um marcador, ou seu handle, na evidência protegida. Depois, o verifier compara essa posição com a fronteira que ainda aceita. O rascunho cobre challenge-response pontual, distribuição espontânea por broadcast ou multicast e subscription solicitada.

O ritmo comum não vira tempo absoluto. Se o formato trouxer horário POSIX, ele depende do relógio e da administração daquela Bell. Se trouxer contador, mostra ordem apenas no contexto que preserva seu estado. Frescor continua sendo a relação entre emissão, entrega, produção de evidência e janela local.

Cada formato carrega uma hipótese diferente

A revisão 05 descreve tags temporais CBOR, o TSTInfo clássico da RFC 3161, uma representação CBOR, Epoch Tick, Tick List, contador monotônico e epoclet. Não são embalagens com a mesma semântica.

Variantes de tempo dependem de relógio confiável na Bell. Contadores dependem de continuidade de estado. Um Tick pode ser reutilizado por muitos consumidores, ao contrário de um verifier nonce criado para uma troca. Uma lista ajuda o receptor a recuperar posições recentes, mas exige memória e uma regra de ressincronização. O epoclet, com cerca de 44 a 64 bytes, combina horário POSIX, identificador de chave do deployment e HMAC. A economia transfere responsabilidade para guarda e rotação da chave compartilhada e sincronização dos servidores.

A assinatura ou MAC comprova uma frase delimitada: a chave esperada autenticou aqueles bytes segundo o formato. Ela não garante que o relógio estava correto, que o contador jamais repetiu após uma falha ou que todos receberam a emissão ao mesmo tempo. COSE, CWT, CBOR e as mensagens conceituais de RATS protegem declarações e ligam campos; não convertem saúde operacional em fato físico.

Uma emissão, várias chegadas

Filas, replicação multicast, links intermitentes e processamento intermediário produzem latência e skew. Um marcador atrasado continua autêntico. Um verifier próximo pode já ter recebido o tick 820, enquanto um local remoto ainda aceita 818. Se 820 virar fronteira universal, evidência honesta do caminho lento pode ser recusada. Se 818 permanecer válido sem prazo, uma captura antiga ganha vida longa.

O problema aparece nos modelos Passport e Background-Check. No primeiro, o attester leva a evidência ao relying party. No segundo, a appraisal pode ocorrer em outro serviço, que devolve um Attestation Result. Em ambos, o resultado deve ficar vinculado ao marcador ou handle usado, e a política deve considerar o caminho real até o decisor.

Uma janela ampla tolera distância, suspensão e filas, mas prolonga o período de uso de evidência boa capturada. Uma janela estreita limita replay e aumenta falsa recusa. O cálculo precisa de recepção local, canal previsto, orçamento de transporte e processamento e vencimento explícito. O protocolo não oferece uma duração universal.

Reutilizável não é uso único

O Epoch Tick é compartilhável por desenho. Isso reduz custo de distribuição e permite que muitos attesters citem a mesma emissão. Também significa que o Tick não herda a propriedade de um nonce só porque aparece dentro de um token assinado.

Quando uma sessão requer exclusividade, o verifier acrescenta seu nonce. O rascunho pede pelo menos 64 bits de entropia, gerados por fonte criptograficamente segura, e permite até 512 bits. O nonce responde se aquela mensagem atende à solicitação atual. O marker informa uma posição da Bell. Ambos devem ser ligados à identidade ou chave do attester e ao digest da evidência no mesmo objeto protegido.

Sem essa junção, um adversário pode transportar um marcador ainda aceito para evidência velha ou para outra sessão. Bell, chave, domínio, escopo, tipo e algoritmo também precisam ser fixados pela política. Se uma parte não confiável puder escolher a forma mais fraca, a negociação vira downgrade, não simples compressão.

O escopo do estado decide quem será recusado

Ticks e contadores exigem memória. Guardar apenas o maior valor visto em todo o domínio custa pouco, mas deixa o caminho mais rápido avançar a fronteira de todos. Attesters lentos podem ser recusados mesmo quando agiram corretamente. Estado por attester consome mais recursos, porém separa históricos e padrões de conectividade.

Um datacenter homogêneo pode preferir limite global e janela curta. Uma frota industrial que passa períodos offline pode exigir histórico individual, suspensão declarada e recuperação cuidadosa após reinício da Bell ou do verifier. Não há resposta automática na criptografia: a escolha distribui custo de armazenamento e risco de falso negativo.

Ressincronização também precisa de proveniência. Tick List pode ajudar a recuperar o atraso, mas aceitar um membro anterior ainda é uma decisão. Reset de contador após perda de estado se parece com rollback. Rotação da chave abre nova época de confiança mesmo que o horário continue. Fronteira anterior, época de chave, causa e autorização da transição devem permanecer registradas.

A Bell pode errar com uma assinatura válida

Uma Bell comprometida ou mal configurada consegue emitir markers criptograficamente perfeitos. O relógio pode saltar, o contador repetir, a mesma chave operar em dois lugares ou receptores selecionados receberem visões atrasadas. A verificação fica verde enquanto a premissa de frescor falha.

Governança da Bell exige operador nomeado, custódia, rotação e revogação das chaves, monitoramento do relógio ou do estado, medição da distribuição e tratamento dos markers emitidos durante incidentes. Várias Bells não fabricam tempo consensual por conta própria. A política precisa definir se são alternativas, escopos separados ou um quorum.

Ticks previsíveis ainda podem correlacionar mensagens protegidas, pois um observador agrupa tráfego ao redor de cada emissão. Variar intervalo, incremento ou escopo pode reduzir essa ligação, mas modifica janelas e estado. Privacidade e frescor devem ser avaliados juntos.

Guardar a junção que produziu a decisão

Um recibo durável começa com identidade da Bell, chave de verificação e sua época; tipo, bytes ou digest do marker; domínio, escopo e alegação de emissão se houver; recepção local, canal e latência medida ou estimada. Em seguida, liga attester, digest da evidência e contexto de produção. Registra o verifier nonce e a sessão quando usados.

O recibo informa se o estado era global, por attester ou particionado de outro modo, qual era a fronteira anterior, o resultado de replay ou reordenação, as ressincronizações e a versão exata da política. Decisão, expiração, revogação e revisão completam o registro. Um incidente posterior na Bell poderá localizar decisões afetadas sem reescrever o passado.

Esses campos são complemento operacional, não matéria a ser empilhada no marker interoperável. A especificação comum fica mínima; decisões futuras permanecem locais; o que realmente ocorreu fica preservado. Esse arranjo permite coordenação sem transformar uma preferência arquitetural em relógio universal.

No corte da pesquisa, a revisão 05 era um Internet-Draft ativo do grupo RATS, atualizado em 3 de julho de 2026 e com expiração em 4 de janeiro de 2027. O Datatracker mostrava “WG Document Doc Shepherd Follow-up Underway” e estado IESG “I-D Exists”, sem area director responsável ou telechat. O cabeçalho dizia Standards Track, enquanto o campo de status RFC pretendido estava vazio. A divergência é parte do registro; nenhum desses fatos prova deployment.

Fontes