Resumo

  • Na RFC 9763, quem solicita um novo certificado demonstra controle da chave privada de um certificado anterior; a autoridade pode então gravar no novo certificado o hash do certificado anterior inteiro.
  • A extensão registra uma associação feita na emissão. Ela não obriga o uso conjunto, não comprova que as duas chaves agiram na sessão e não escolhe se uma autenticação basta ou se ambas precisam vencer.
  • O registro defensável separa prova de cadastro, política da autoridade, bytes exatos, caminhos de confiança, atos atuais das chaves, negociação e decisão final do verificador.

Uma equipe recebe dois certificados, calcula o resumo indicado e encontra correspondência perfeita. O teste é objetivo e reproduzível. Mesmo assim, a pergunta mais importante permanece aberta: o que esse resultado autoriza o endpoint a fazer?

A resposta curta é: nada por si só. A RFC 9763 define o atributo relatedCertRequest e a extensão X.509 RelatedCertificate. Juntos, eles dão garantia adicional de que dois certificados de entidade final pertencem à mesma entidade. O próprio RFC diz que os mecanismos apenas expressam uma relação e não realizam uma função de segurança sozinhos.

O pedido contém duas ações distintas

O cenário começa com o Certificado A, já emitido, e um pedido do Certificado B. A migração de criptografia tradicional para pós-quântica é o exemplo central: o titular quer preservar compatibilidade e, ao mesmo tempo, introduzir outra chave.

O pedido comum de B inclui a nova chave pública. No PKCS#10 da RFC 2986, a assinatura liga nome, chave e atributos e demonstra posse da chave privada correspondente à chave solicitada.

A RFC 9763 acrescenta uma prova sobre A. relatedCertRequest traz emissor e número de série de A, instante do pedido, localização e assinatura. A chave privada de A assina a concatenação, em DER, do identificador de A com o BinaryTime.

Segundo a RFC 6019, BinaryTime conta segundos desde o início de 1º de janeiro de 1970 UTC, sem segundos intercalares. O formato é comum; o limite de idade aceitável é política local da autoridade. Por isso, guardar apenas “prova fresca” não basta. É preciso registrar instante, janela e versão da regra.

A autoridade produz uma trilha de decisões

Uma autoridade que aceite o atributo deve obter A, validar seu caminho conforme a RFC 5280, comparar emissor e série com certID, aplicar sua regra de frescor e verificar a assinatura com a chave pública de A.

Cada etapa responde a uma pergunta. Quais bytes foram obtidos? O caminho termina numa âncora aceita sob quais parâmetros? É o certificado nomeado? O pedido está dentro da janela? A chave de A assinou aqueles dados? Um único estado “relação validada” apaga a causa quando algo falha.

A RFC 5280 trata âncoras e políticas como entradas. Um caminho que cumpre condições mínimas pode não servir a toda aplicação. Quando key usage e extended key usage aparecem juntos, ambos restringem o uso.

Após a verificação, a autoridade pode emitir B com a extensão. Ela só pode apontar para A, deve conferir compatibilidade dos usos de chave e deve verificar a validade de A na emissão. O período de sobreposição útil entre A e B, porém, é responsabilidade do assinante.

Assim, A válido hoje não garante par utilizável amanhã. Expiração, revogação ou reemissão de A podem encerrar a combinação operacional, embora a emissão histórica de B continue correta.

O resumo identifica uma emissão exata

A extensão em B contém o algoritmo de resumo e o hash do certificado A completo. Não é apenas a chave pública ou o nome do titular. É uma sequência exata de bytes.

O verificador consegue refazer o cálculo localmente. Essa é a força do mecanismo: a camada comum não precisa de interpretação online. Mas uma reemissão de A, mesmo com nome e chave iguais, pode mudar série, validade, extensões e assinatura. O novo objeto terá outro hash e não será o certificado apontado por B.

Inventários por “identidade” frequentemente escondem essa diferença. A observabilidade precisa conservar impressões dos artefatos, não apenas nomes de dispositivos. A extensão também não deveria ser crítica, para preservar interoperabilidade com implementações antigas, e só aparece em certificados de entidade final. Ser ignorada sem erro não significa ter sido verificada.

A correspondência não encerra o protocolo

Num protocolo com autenticações múltiplas, o endpoint recebe A e B, procura a extensão, calcula o hash de A e compara. O que fazer com o resultado fica fora do escopo. Um par pode exigir duas autenticações; outro pode aceitar pelo menos uma.

CMS e S/MIME deixam o signatário escolher o material oferecido. Protocolos negociados dão outra voz ao verificador. A RFC 5652 fornece a sintaxe CMS e a RFC 8551 o empacotamento de certificados citado. Nenhuma delas transforma associação em autorização da aplicação.

O texto é explícito: a garantia não é requisito nem mandato para usar um certificado com o outro. Ela diz que podem ser usados juntos porque a mesma entidade controla as chaves. A autoridade responde por essa afirmação na emissão; o endpoint responde pelo risco no uso.

Controle no cadastro não é controle agora

A segurança híbrida precisa de evidência de controle no cadastro, perante a CA, e no uso, perante o verificador. A assinatura de relatedCertRequest mostra a ação da chave de A no primeiro momento. O pedido comum trata a nova chave. A extensão preserva a associação. A sessão futura ainda precisa das provas exigidas naquele protocolo.

Se só a chave tradicional assina, anexar B não cria autenticação pós-quântica. Se chegam duas assinaturas e o software valida uma, a outra não oferece garantia. Se ambas passam matematicamente mas uma cadeia termina numa âncora não aceita, o hash não amplia a confiança.

A diferença para a RFC 9883 é decisiva. Ela permite uma declaração assinada sobre a posse de outra chave de estabelecimento sem prova técnica dessa outra posse. A RFC 9763 usa uma assinatura real da chave de A e, no pedido comum, uma assinatura ligada a B; depois relaciona os certificados. Aqui o risco é promover prova de cadastro a prova de sessão.

A RFC 9955 discute propriedades de assinaturas híbridas e regras de verificação. A RFC 9763 não escolhe um combinador universal; fornece um sinal de relação para regras definidas em outro lugar.

Outra CA significa outra estrutura de confiança

Quando uma organização emitiu A e B, ela costuma conhecer o repositório e as âncoras. Entre organizações, a CA de B talvez não valide A. O RFC admite acordos prévios, contratos, âncoras configuradas e entendimento sobre emissão e aceitação.

Mesmo titular não implica políticas equivalentes. Identificação, proteção da chave, resposta a revogação e obrigações contratuais podem variar. A CA de B deve escolher política comparável à de A, mas essa comparação é decisão responsável, não saída do hash.

Relatórios precisam evitar três atalhos: “mesma entidade” não é “mesmo nível de garantia”; “caminho válido” não é “aceito por esta aplicação”; “relação confere” não é “duas autenticações venceram”.

Buscar A abre uma superfície adicional

O atributo informa onde obter A. Dentro da mesma organização, pode apontar por HTTP(S) para uma mensagem CMS só com certificados. Entre organizações, recomenda-se uma URL data: com certificados e material de revogação; a RFC 2397 define o esquema.

Uma URL assinada ainda pode entregar conteúdo malicioso. O objeto precisa ser analisado e validado integralmente. A busca em rede também pode ser observada, revelando que uma CA está processando relação com um certificado específico. O conteúdo embutido reduz essa exposição, sem eliminar a validação.

Devem ser guardados o modo de localização, hash do objeto obtido, resultado do parser, cadeia, dados de revogação e âncoras. O certificado B sozinho não reconstrói o que a CA avaliou.

Downgrade acontece antes da extensão ajudar

Um par malicioso pode omitir suporte ao algoritmo forte e provocar troca dependente do fraco. A extensão é examinada depois que o certificado chega; não prova quais capacidades foram oferecidas ou protegidas durante a negociação.

O controle está em políticas mínimas, transcrições autenticadas quando disponíveis, telemetria do modo escolhido e alerta de regressão. Número de certificados relacionados mede preparo. Só o tráfego mede adoção.

Isso segue a primazia do código em execução de Heng Lu. A especificação inicial mínima, decisão futura localizada e adoção voluntária sustentam uma relação determinística comum sem entregar a uma autoridade a decisão futura de cada endpoint.

As camadas de realidade exigem separar prova de cadastro, afirmação de emissão, bytes, hash, assinatura atual, caminho, autorização e efeito. São fatos relacionados, não um único status.

Evidência capaz de ser refeita

No cadastro, preservar CSR, identificador de A, tempo, localização, bytes assinados, assinatura e dados do caminho. Na emissão, bytes e hash de A, bytes de B, comparação de usos, política e sobreposição de validade.

No uso, preservar certificados recebidos, resultados dos dois caminhos, comparação do hash, provas realmente executadas, modo negociado, versão da política, decisão e estado da conexão. Assim, um incidente pode ser atribuído ao cadastro, à confiança, à negociação ou à aplicação correta.

Fontes