Resumo

  • draft-nikolaichuk-scitt-continuity-receipts-01 propõe uma declaração assinada para a recuperação de um ativo com estado e um Receipt da RFC 9942 que comprova o registro dessa declaração em um serviço de transparência.
  • O subject estável e a cadeia prev-event ajudam a reconstruir a linhagem, mas também podem revelar onde, quando e com que frequência o ativo foi recuperado. Pseudonimizar reduz a correlação e cria novos custos de continuidade.
  • Um retorno HTTP 202 com entry identifier ainda não é Receipt. Mesmo depois do Receipt, ocorrência, atestação favorável e fidelidade do ativo continuam sendo verificações separadas.

A continuidade que atravessa regiões deixa um mapa

Considere um ativo selado em uma região e recuperado onze meses depois em outra, porque a conta original foi encerrada. Para o operador, a cadeia é valiosa: mostra que se trata do mesmo ativo, que uma recuperação anterior existiu e que a declaração atual entrou em um registro verificável.

Para um observador, essa mesma cadeia pode revelar uma relação entre provedor e cliente, uma mudança de jurisdição, a frequência de recuperação e até afinidades de hardware. A continuidade não é apenas uma propriedade de integridade. É também um padrão de movimento.

Essa tensão aparece em draft-nikolaichuk-scitt-continuity-receipts-01, publicado em 29 de setembro de 2026. Trata-se de um Internet-Draft individual, com status pretendido Informational, não de adoção pelo grupo SCITT nem de RFC. O texto define claims para uma Recovery Statement e usa a arquitetura existente de SCITT e Receipts COSE; não cria um novo serviço de transparência, formato de atestação ou decisão de liberação de chaves.

Sua contribuição é útil porque não promete uma escolha sem custo. Para tornar a recuperação auditável, alguém precisa decidir o que entra no registro, o que fica fora e quem ainda conseguirá verificar a história anos depois.

O evento termina nos bytes, não no anúncio

A Recovery Event começa quando o material de chave é liberado e termina quando os bytes recuperados existem e foram medidos. Antes disso, o Attester do ambiente produz Evidence, e um Verifier emite Attestation Results. Depois, a Recovery Authority cria os claims, assina a Statement e a envia ao Transparency Service. O Receipt surge apenas após o registro.

O fluxo separa funções. O mecanismo de chave autoriza acesso ao material selado. O ambiente produz o resultado. A Recovery Authority afirma o que observou. O serviço testemunha o registro. O Relying Party decide se aceita o conjunto de provas e, por fim, alguém libera o ativo para um consumidor.

Não há razão técnica para transformar essa cadeia em uma única autoridade. O registro não acompanhou a recomposição dos dados. O Verifier não necessariamente viu o ativo final. O custodiante pode assinar uma afirmação legítima e ainda estar errado. A thin common layer, no sentido defendido por Lu Heng, deve padronizar o mínimo determinístico sem tomar para si a decisão de risco de quem opera e responde pelo efeito.

O que fica comprovado no log

O Continuity Receipt comprova que uma Recovery Statement específica, assinada por um Issuer específico, foi registrada em um Transparency Service específico, numa posição específica de seu log append-only, e que o serviço assinou a prova desse fato.

Ele não comprova que a recuperação aconteceu. Não compara os bytes com o original. Não diz que os Attestation Results foram verificados nem favoráveis. Não certifica o estado real do ambiente. Também não mostra que a Registration Policy examinou essas proposições.

O valor do Receipt permanece considerável. A afirmação passa a ser atribuível, ordenada, permanente e difícil de retirar sem deixar contradição. O testemunho cria uma superfície de responsabilização. O erro seria apresentá-lo como auditoria do conteúdo.

Uma interface responsável deve preservar três classes: o que o Issuer afirmou, o que outra evidência estabeleceu e o que continua sem verificação. Um selo único chamado “verified” desfaz a arquitetura.

Antes do Receipt existe uma decisão de disponibilidade

O SCRAPI atual permite que o serviço aceite a Statement e responda HTTP 202 com um entry identifier, deixando o Receipt para resolução posterior. O identificador torna possível consultar o andamento. Não comprova inclusão.

O rascunho exige que o Issuer escolha: esperar pelo Receipt antes de liberar o ativo ou prosseguir e registrar a recuperação como unwitnessed. O 202 não pode ser tratado como Receipt.

Em uma falha regional, esperar pode contrariar o objetivo da recuperação. A organização pode ter justificativa para liberar o ativo a um conjunto reduzido de consumidores. Mas isso precisa virar um evento próprio: autoridade da exceção, motivo, prazo, perímetro, controles compensatórios e obrigação de reconciliar. Sem esses elementos, o RTO se transforma em licença implícita para abandonar a prova quando o ambiente está sob maior pressão.

O entry identifier é a promessa de um objeto futuro. Se o Receipt nunca chegar, o sistema precisa continuar mostrando a dívida, não apagar o estado intermediário.

O digest do resultado precisa nascer do resultado

recovered-digest é calculado sobre o plaintext produzido ao final da recuperação. Copiar o digest esperado de um inventário de backup não demonstra nada sobre os bytes reconstruídos. O esperado serve para comparação; a medição serve para descrever a realidade.

A identidade do ambiente segue a mesma regra. A medição deve manter algoritmo e comprimento nativos. O texto registra que o código adjacente reduz a 32 octetos medições SHA-384 de 48 octetos de AWS Nitro e AMD SEV-SNP. A normalização elimina a igualdade exata com a política que usa o valor completo.

Running-Code Primacy aqui é uma disciplina de proveniência: guardar o que o sistema executado efetivamente mediu e a forma em que a decisão foi tomada, sem completar campos com a especificação desejada.

Atestação: onde guardar muda o que se expõe

Os Attestation Results podem ser referenciados, embutidos ou registrados separadamente. Uma referência mantém a Statement menor, mas exige que os bytes exatos permaneçam recuperáveis. O modo embutido reduz essa dependência e pode publicar detalhes de plataforma. O registro separado dá à atestação seu próprio Receipt e posição, com mais uma relação a preservar.

O campo de freshness usa nonce, epoch ID, timestamp ou none. none informa que a Evidence não foi vinculada a um desafio e pode ser reproduzida. É uma descrição honesta, não sinal de que o resultado seja atual.

Também é possível ter um resultado autêntico e desfavorável. Assinatura, disponibilidade, frescor e conclusão de avaliação precisam aparecer em campos distintos.

O ativo pode operar sem ser equivalente

Se equivalence não aparece, o valor é none. byte-identical requer igualdade entre o digest observado e o digest do plaintext registrado no momento do selo, com comparação feita pelo Issuer. operational significa apenas que um teste definido passou—carregar, iniciar, responder a um health probe—e exige referência para sua definição e resultado.

Não existe código para equivalência semântica ou comportamental. Uma restauração pode ser operacional e produzir respostas diferentes. Uma base pode abrir sem conter todos os registros. A recusa em criar um rótulo forte para um teste fraco impede que a conveniência do formato produza uma garantia imaginária.

O Receipt comprova o registro de uma afirmação sobre equivalência; não transforma a afirmação em fidelidade.

A linhagem do Issuer e a ordem do serviço

prev-event liga Recovery Statements do mesmo subject. Essa Continuity Chain mostra a genealogia que o Issuer declarou. O log mostra a ordem global em que as Statements foram registradas.

Uma lacuna entre as duas é informação. Talvez o Issuer desconhecesse uma recuperação intermediária; talvez não a reconhecesse. O Verifier deve reportar o desvio, não consertá-lo. prev-entry-id e leaf index ajudam a localizar; o digest da Statement anterior cria o vínculo criptográfico.

Ao cruzar dois Transparency Services, a garantia de ordem de um não se compõe com a do outro. E uma verificação de longo prazo exige consistency Receipts entre raízes. Inclusion em uma raiz isolada não prova que a árvore antiga foi estendida em vez de substituída.

Subject estável: continuidade e correlação

Um subject estável reúne todas as recuperações sob um identificador. Essa é a utilidade da cadeia e sua principal exposição. HMAC com uma chave do Issuer pode criar um pseudônimo e impedir enumeração por quem não tem a chave e o identificador.

O preço é estrutural. Dois custodiantes produzirão subjects diferentes e não conseguirão unir a história. A chave vira segredo de longa duração; se vazar, correlaciona retroativamente todos os eventos, e se for perdida, o próprio Issuer perde a capacidade de enumerá-los. A rotação divide a cadeia, salvo se houver um vínculo publicado ou transmitido em privado.

O payload também pode ser attached ou detached. Attached permite política sobre claims e expõe mais informação ao log. Detached protege o conteúdo, impede o serviço de avaliar claims ausentes e cria um canal lateral obrigatório para o Relying Party. Privacidade e verificabilidade são escolhas de arquitetura, não retoques.

O código citado ainda está ao lado da proposta

O documento admite que a referência de código não implementa esta especificação. Ela não produz COSE Receipts RFC 9942, usa outros encadeamentos, deixa incompleta a verificação de atestação e não tem binding por nonce. O componente de reconstrução é uma cadeia de Markov determinística de ordem 3 sobre bytes, não validação de significado.

Isso não prova falha em produção, pois nenhuma produção foi demonstrada. Prova apenas uma divergência documentada entre proposta e código, que deve permanecer visível até que testes de interoperabilidade e implantação existam.

Fontes e limites

As fontes descrevem uma proposta em andamento, arquiteturas existentes e limitações declaradas de um código adjacente. Não comprovam implantação, incidente, ataque, recuperação real, interoperabilidade, adoção ou fidelidade semântica. O dossiê de liberação abaixo é análise operacional de Daniel Kade, não requisito já padronizado.