Quando a credencial dura além da atestação

Summary

Um Internet-Draft individual propõe que um Identity Document Service compatível com RATS transforme um Attestation Result aceitável em chave, token ou credencial comum para serviços que não entendem RATS.
Depois da emissão surge uma lacuna: a credencial pode continuar aceita por suas regras nativas mesmo após mudança na Evidence, na política de avaliação, no local da carga ou numa alegação essencial.
Daniel Kade propõe um arrendamento entre atestação e credencial, vinculando duração, status e revogação a épocas de evidência, versões de política, classes de alegações, chave da carga e eventos de mudança. É uma proposta editorial, não uma regra do IETF.

A confiança se divide na fronteira

O exemplo de migração não depende de ataque. A carga apresenta Evidence, um Verifier a avalia e um Identity Document Service (IDS) aceita o resultado. A chave privada permanece com a carga, o canal pode estar corretamente protegido e a credencial emitida pode ser perfeitamente autêntica. Em seguida, o orquestrador faz uma mudança rotineira de local.

O draft-bdnr-rats-trustworthy-credentials-02 observa que uma migração ao vivo da Alemanha para a França pode invalidar Country=Germany, embora Region=Europe continue correto. Isso não produz uma resposta única. Uma capacidade europeia pode permanecer; uma permissão vinculada à Alemanha precisa ser reavaliada. A consequência depende da relação entre cada alegação e cada parcela de autoridade.

O serviço antigo não enxerga essa relação. Ele recebe um certificado ou token válido segundo o modelo que já aplicava. O projeto o manteve fora de RATS de propósito. A governança falha quando também deixa invisível quem deve converter uma mudança de confiança numa ação que esse serviço entenda.

Compatibilidade é uma restrição de implantação

Há bons motivos para não modificar todo consumidor. Aplicações de terceiros, binários imutáveis, linguagens sem suporte, processos regulatórios e divisões entre equipes podem tornar a introdução de Evidence e Attestation Results lenta ou inviável. Se cada cliente e servidor tiver de dominar RATS, a parte mais rígida passa a controlar o cronograma.

O borrador propõe um Credential Broker, Key Broker ou Credential Authority que acumule os papéis de RATS Relying Party e IDS. A carga prova seu estado ao intermediário; quando o resultado passa pela política, recebe um Identity Document reconhecido pelos colaboradores existentes. Esse documento pode ser chave, token ou credencial, de curta ou longa duração. As variantes incluem intermediação de chave, credencial de prova de posse previamente provisionada e emissão de nova credencial de posse ou token portador curto.

O ganho é reduzir o raio de impacto. TLS, PKI, tokens e autorização já presentes continuam operando, e a chave privada pode ficar dentro da carga. A proteção de Evidence sensível também não precisa ser replicada em todos os consumidores.

Essa vantagem deve ser preservada. Mas o intermediário assume uma obrigação correlata: se escondeu a atestação na entrada, precisa traduzir mudanças posteriores em expiração, redução de escopo, status ou revogação nativos. A complexidade muda de lugar; não desaparece.

Três relógios governam um único acesso

RFC 9334 distingue o Appraisal Policy for Evidence, aplicado pelo Verifier, do Appraisal Policy for Attestation Results, aplicado pela Relying Party. O primeiro produz uma interpretação; o segundo decide se ela basta para um uso específico. Autenticidade e autorização não são sinônimos.

A Evidence requer frescor adequado e o Attestation Result possui um limite de validade. O RFC reconhece uma corrida inevitável: estado ou política pode mudar logo depois da emissão do resultado. Não usar o resultado além da validade é essencial, mas não garante que tudo permaneça estável durante o intervalo.

Quando o IDS emite uma credencial, nasce um terceiro relógio. Certificados têm início e fim; tokens expiram; listas e serviços de status atualizam em outro ritmo. O sistema legado lê esse relógio, não o instante da Evidence nem a versão das duas políticas. Se a credencial vale oito horas e uma alegação material merece cinco minutos de confiança, a conversão apenas oculta a diferença.

Credenciais breves diminuem a exposição, sem definir a ligação. Um token de dez minutos ainda ultrapassa um fato confiável por cinco. Atestação contínua detecta mudanças, mas não escolhe o destino da credencial em circulação. Revogação funciona somente quando o IDS conhece as dependências e cada consumidor aplica o canal de status.

Uma assinatura correta pode carregar sentido antigo

JWS, em RFC 7515, protege integridade e autoria criptográfica de um objeto. A validação de certificados em RFC 5280 considera cadeia, nomes, restrições, período e revogação conforme a configuração. Prova de posse demonstra controle da chave privada. Nenhum desses testes repete a avaliação da Evidence que fundamentou a emissão.

Por isso, o serviço legado pode agir corretamente e manter autoridade ultrapassada. Se a credencial não venceu nem foi revogada, aceitá-la é coerente com sua visão. Seria contraditório poupá-lo de RATS e depois responsabilizá-lo por não perceber uma migração ou alteração da política.

O IDS segue na cadeia de confiança após emitir. Ele uniu um lado dinâmico—Evidence, valores de referência, Endorsements, Verifiers e políticas—a outro composto por vencimento, rotação, introspecção e revogação. Essa união deve sobreviver como estado operacional capaz de disparar ações. Um registro histórico consultado só depois do incidente não encerra autoridade.

Alegações envelhecem em ritmos diferentes

País e região não são dois nomes para o mesmo semáforo. O provedor de execução pode mudar enquanto o componente medido permanece. Uma configuração pode degradar sem romper o boot seguro. Uma revisão de política pode excluir um algoritmo e conservar outras propriedades. Cada mudança precisa alcançar apenas a capacidade que dela depende.

Uma permissão europeia talvez não dependa de país. Um direito de processar dados apenas na Alemanha depende. Quando ambos são colocados numa credencial indivisível, corrigir se torna grosseiro: manter preserva privilégio demais; revogar corta também o que continua justificável. Separar escopos é, portanto, uma ferramenta de governança.

O mapa de dependências evita dois extremos. Revogar tudo a cada variação transforma atestação em causa de indisponibilidade e incentiva equipes a ignorar sinais. Esperar sempre a expiração permite que uma assinatura conserve premissas mortas. O registro deve explicar qual alegação controlava cada poder e por que o evento levou a substituir, restringir, suspender ou não agir.

A identidade da carga não vem do transportador

O draft admite que um cliente EST esteja num hipervisor ou orquestrador fora da base confiável da carga. Ele pode se autenticar para formar o canal. Essa identidade opcional não deve determinar para qual carga se devolve uma credencial; Evidence e attestation estabelecem o vínculo, e a chave privada deve permanecer com a carga.

Após a emissão, eventos também precisam se juntar à credencial pela identidade e chave atestadas, não só pela sessão do orquestrador que carregou o pedido. Caso contrário, todos os canais podem estar autenticados e ainda assim atualizar ou revogar o objeto errado.

O draft LAMPS de atestação em CSR explicita obrigação próxima. Se uma CA ou RA usa attestation, ela responde por ligar as declarações entre si e à chave pública no pedido, além de documentar requisitos em sua Certification Practice Statement. Isso localiza a responsabilidade de vinculação; não prova que o regime posterior à emissão já esteja definido.

WIMSE também separa a credencial que representa identidade de carga do mecanismo de prova de posse. Controlar a chave responde quem apresenta. Não responde se localização, configuração e medição continuam verdadeiras.

O arrendamento de atestação para credencial

A proposta de Daniel Kade é um arrendamento mantido pelo IDS. Ele não cria um novo formato público nem exige RATS do serviço antigo. É o estado mínimo que mantém conectadas a validade dinâmica da atestação e a validade nativa da credencial.

Primeiro, registra identificador e tipo da credencial, identidade da carga, chave pública mantida pela carga e vínculo de prova de posse. Depois, anota época e limite de frescor da Evidence, identidade do Verifier, versão de seu Appraisal Policy for Evidence e versão da política usada pelo IDS para aceitar o resultado. Assim, alterações encontram os objetos que exigem revisão.

Em seguida, associa cada escopo às classes mínimas de alegação: país, região, software medido, proteção de chave ou ambiente operacional. A dependência pode ser obrigatória, informativa ou apenas reduzir a duração. Não é preciso copiar toda a Evidence. Uma referência protegida, época e resumo do resultado preservam o vínculo com limites de privacidade e retenção.

O arrendamento define um horizonte. A credencial não deve ultrapassar sem explicação a dependência material mais curta, salvo quando observação contínua e um caminho de status comprovado forneçam controle equivalente. Não se exige sempre a menor duração; exige-se dizer como a diferença será fechada.

Por fim, eventos recebem traduções. Migração, rotação de chave, nova política, retirada de valor de referência, alteração de software, falha de correção ou mudança de Endorsement podem iniciar nova atestação. A resposta pode ser reemissão, redução, suspensão, revogação ou decisão fundamentada de não agir. O IDS precisa demonstrar que a sinalização nativa foi emitida e alcançável pelos consumidores.

Revogação precisa chegar ao uso

Uma coluna “revogado” num banco não prova que o acesso parou. Há serviços que guardam status em cache, verificam apenas no começo da conexão ou esperam o token expirar. Sessões existentes podem sobreviver. O arrendamento precisa declarar o caminho real de aplicação e o atraso máximo.

Uma auditoria segue o evento desde a origem: quem informou a migração, quanto demorou a reavaliação, qual mecanismo de certificado ou token foi usado, o que ocorreu com sessões e partes offline, quando o objeto antigo perdeu efeito e quando o substituto começou. O sucesso de uma chamada de revogação é início, não conclusão.

Exceções também têm ciclo. Uma falha do Verifier pode justificar trinta minutos de continuidade, com escopo restrito. Autoridade, motivo, expiração, observação compensatória e destino final precisam ser registrados. Repetir uma exceção sem fechamento cria uma segunda cadeia de confiança.

Limites do que está documentado

O draft de trustworthy credentials reconhece pendências: o token portador necessita de outro protocolo ou extensão, e /serverkeygen precisa de maior detalhamento. Trata de canais protegidos e custódia de chaves, mas não apresenta governança completa do período pós-emissão.

Na data de corte, trata-se de Internet-Draft individual sem posição formal do IETF. Os drafts LAMPS e WIMSE também estão em andamento. As fontes não demonstram implantação nomeada, duração habitual, incidente de migração, falha regulatória, desempenho ou adoção. O cenário inicial aplica um alerta do próprio draft, sem atribuir conduta a um operador. O arrendamento é análise editorial, não requisito de padrão.

Uma credencial de carga de trabalho pode durar além da decisão de atestação

Por que isso importa

Summary

A confiança se divide na fronteira

Compatibilidade é uma restrição de implantação

Três relógios governam um único acesso

Uma assinatura correta pode carregar sentido antigo

Alegações envelhecem em ritmos diferentes

A identidade da carga não vem do transportador

O arrendamento de atestação para credencial

Revogação precisa chegar ao uso

Limites do que está documentado

Sources

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance