Resumo

  • O RFC 9345 permite que o titular de um certificado assine uma credencial estreita. A chave privada correspondente pode concluir handshakes TLS/DTLS 1.3 compatíveis, enquanto o peer continua validando a cadeia original e a identidade esperada.
  • Sete dias são o máximo padrão, não uma revogação imediata por credencial. Quem rouba a chave delegada pode personificar o peer até o vencimento; revogar antes pelo mecanismo exige atingir também o certificado que a assinou.
  • A cadeia de prova deve registrar opt-in do certificado, bytes e assinatura da credencial, origem e circulação da chave, conjunto de edges, negociação, CertificateVerify, fallback, resumption e rejeição após a expiração.

A diferença entre assinar e entregar a identidade

Considere um serviço que guarda a chave do certificado em um back-end de assinatura. O back-end autoriza uma nova chave pública por um intervalo curto. A borda detém a privada correspondente e pode assinar CertificateVerify localmente. O ganho é claro: não há consulta ao detentor da chave longa em cada handshake, nem cópia dessa chave em todo ponto de presença.

Mas a borda não passa a renovar o certificado, alterar nomes, escolher a CA ou produzir sua própria sucessora. A chave curta serve para um papel, um algoritmo e uma janela. Delegated Credential também não é um certificado X.509 menor: o RFC criou uma estrutura propositalmente limitada, ligada aos bytes completos do certificado e a um contexto separado para autenticação de cliente ou servidor.

Essa restrição evita uma ambiguidade comum em terceirização. O provedor pode executar a autenticação de transporte e, ainda assim, não ser o principal que detém a identidade. Capacidade de execução e mandato são registros diferentes.

O certificado abre a primeira porta

Antes de qualquer distribuição, o certificado de entidade final precisa conter DelegationUsage e KeyUsage digitalSignature. O endpoint deve recusar a credencial se faltar um deles. O opt-in impede que acesso temporário a uma chave comum ou um oracle em protocolo antigo ganhe, sem autorização, poder de emitir delegações futuras.

Para autenticar servidor, o cliente anuncia a extensão 34 e algoritmos aceitáveis no ClientHello. Só depois o servidor pode inserir uma credencial no CertificateEntry da entidade final. Para autenticação do cliente, o servidor anuncia suporte no CertificateRequest. Receber sem pedir produz erro; tolerância não cria autoridade.

O validador ainda verifica cadeia e identidade do certificado. Em seguida confere relógio, vida restante, limite do certificado, relações de algoritmo, extensão e assinatura da credencial. A chave pública delegada é usada somente no último passo, para CertificateVerify.

Assim, CA, titular, edge e aplicação exercem poderes distintos. A CA sustenta o certificado. O titular assina a permissão. O edge prova a posse. A aplicação decide o que o canal autenticado pode fazer. Uma camada não substitui a seguinte.

Curta duração limita dano, não recolhe cópias

Sem profile diferente, a credencial não pode ficar válida por mais de sete dias a partir da verificação nem ultrapassar o certificado. Cloudflare documenta uma política em que suas credenciais Keyless se tornam inválidas em até 24 horas após desativar o produto. É uma escolha operacional mais curta, não a duração universal.

Nem sete dias nem 24 horas significam revogação instantânea. O RFC não oferece uma lista própria para retirar uma única DC. Parar emissão e remover configuração afetam o caminho legítimo, não uma cópia já exfiltrada. Pode-se esperar o vencimento ou revogar o certificado, com impacto maior.

O relógio participa da autoridade. valid_time deriva do notBefore do certificado, e cada client decide com seu tempo. Perto do limite, skew transforma uma credencial aparentemente saudável em falha para parte dos peers. A janela de refresh precisa de margem e telemetria real.

Resumption também merece controle. Se o peer reutiliza e revalida a cadeia em uma sessão retomada, deve carregar e revalidar a DC associada. Caso contrário, uma decisão baseada em permissão vencida pode continuar sem novo handshake completo.

Quem gera a chave define a evidência

O RFC 9677 descreve dois modelos em CDNs interconectadas. No primeiro, o downstream gera o par e encaminha a pública para assinatura. A privada não trafega, mas o enrollment da pública precisa autenticar o destinatário. No segundo, o upstream envia uma privada cifrada junto com a credencial. A criação fica centralizada, mas aparece um ciphertext durável e uma chave de transporte crítica.

O RFC desaconselha transportar privadas pela interface de metadados. Se a opção for usada, exige cifragem forte, sem oferecer forward secrecy contra comprometimento futuro da chave de decifragem. Expirar a credencial encerra uso novo; não apaga arquivos.

Compartilhar uma credencial com muitas máquinas reduz carga e aumenta blast radius. Uma por edge melhora atribuição e contenção, mas multiplica assinatura, entrega, inventário e risco de expiração. A granularidade segura é aquela que o sistema consegue renovar quando o signer falha e parte da borda está desconectada.

A compatibilidade mantém outro caminho vivo

A DC só funciona em TLS/DTLS 1.3 e depois de anúncio. Registro recomendado na IANA prova semântica atribuída, não market share. Cloudflare cita Firefox 77 ou posterior, mas também diz que poucos clients e poucas CAs suportam a extensão.

Logo, fallback é componente permanente na fase atual. Remote signing devolve dependência e latência ao back-end. Colocar a chave longa na borda devolve exposição. Manter outro certificado devolve inventário e trabalho de revogação. Nenhuma alternativa desaparece porque o painel mostra mais handshakes delegados.

Os testes BoringSSL recusam uso em TLS 1.2, separam os dois algoritmos e escolhem certificado comum quando não há DC adequada. O NSS usa a privada delegada para assinar e a pública para verificar. Ter o code path não comprova que uma conexão real o percorreu; isso precisa de evidência do handshake.

O livro de uma credencial

Guardar fingerprint, serial, nomes, validade, KeyUsage e DelegationUsage do certificado; hash da DC e da SPKI; papel, algoritmos, vencimento; aprovador e evento da chave longa que assinou.

Guardar se a privada nasceu no delegate ou foi entregue, canal, edges autorizados, confirmações e fan-out. Para handshake, separar anúncio, seleção, validação, CertificateVerify, versão e fallback.

No encerramento, registrar fim de novas emissões, remoção por node, último instante possível, decisão de revogar o certificado, resumption e teste negativo após o vencimento. Tela vazia prova uma configuração local. Não prova que todas as cópias perderam efeito.

Fontes