Resumo

  • Na situação descrita pela RFC 5217, a PKI2 participa de dois domínios. Isso permite construir um caminho da PKI1 à PKI3, mas a validação sob a política do domínio 1 não pode ter sucesso porque as pontas não compartilham esse domínio.
  • Certificação cruzada e Bridge CA criam conectividade assinada. A aceitação depende ainda da âncora, dos mapeamentos e restrições, da filiação aos domínios, da revogação e da decisão executada pela parte que assumirá o risco.

A cerimônia terminou antes da autorização

Os certificados cruzados haviam sido emitidos, os repositórios estavam acessíveis e o validador conseguia montar uma cadeia completa. Para a equipe de integração, parecia faltar apenas transformar o resultado em produção. O teste de política, porém, rejeitou o certificado final.

A rejeição não desfez o trabalho técnico. Ela mostrou que o trabalho técnico não respondia sozinho à pergunta de confiança.

Na RFC 5217, a PKI2 integra os domínios 1 e 2. Há um caminho da PKI1 até ela e outro dela até a PKI3. O algoritmo pode concatenar os trechos. Mas PKI1 e PKI3 não dividem a filiação ao domínio 1. Quando a validação usa a política desse domínio, o resultado não deve ser sucesso.

O caminho prova que a infraestrutura alcança o destino. Não prova que o principal autorizou a dependência.

Construção e validação não são sinônimos

Construir um caminho significa descobrir uma sequência ordenada entre uma âncora de confiança e um certificado de entidade final. Validá-lo significa aplicar políticas, restrições de nome, finalidades, datas e estado de revogação àquele candidato.

Uma ponte pode reduzir o número de relações bilaterais e facilitar a busca. Uma malha pode oferecer mais opções. Esses ganhos de topologia não equivalem a uma decisão para toda aplicação.

A RFC 5217 preserva a política e a CA principal de cada PKI. Antes de estabelecer confiança externa, as partes examinam documentos de certificação e governança e definem como os níveis de garantia se relacionam. O certificado cruzado formaliza o acordo limitado; não transforma todos os usos em equivalentes.

A filiação dupla amplia o grafo

Quando a PKI2 pertence a dois domínios, ela cria uma passagem lateral. Sem limites explícitos, um construtor pode descobrir uma rota que faz a confiança local parecer transitiva. As assinaturas de cada elo permanecem corretas, mas a autorização do conjunto não aparece por soma.

A RFC 5217 aponta para restrições assinadas em certificados cruzados: mapeamentos de políticas, policy constraints e name constraints. Se um domínio quer impedir determinado caminho, não deve depender apenas da esperança de que cada relying party tenha configurado a mesma regra local.

Mudanças de filiação alteram essa superfície. A entrada ou saída de uma PKI em outro domínio deve ser comunicada. Os certificados afetados precisam ser reavaliados; se o conjunto permitido mudou, a resposta é revogar e reemitir com os limites corretos.

Assinar a relação não elimina a necessidade de acompanhar sua vigência.

Bridge CA não é raiz universal

No modelo de ponte, uma Bridge CA administra certificações cruzadas e mapeia políticas, reduzindo a explosão de acordos diretos. Ao mesmo tempo, a RFC 5217 determina que ela não seja a âncora de confiança dos domínios participantes e não emita certificados comuns para entidades finais.

O desenho evita que centralidade operacional vire soberania. Cada relying party parte da âncora escolhida pelo seu domínio. O caminho pode atravessar a ponte, mas carrega as condições assinadas de ambos os lados. A ponte coordena; não decide sozinha o risco aceitável.

Toda lista de confiança tem um principal

No modelo local, cada relying party instala e mantém suas âncoras. É simples e dispensa certificação cruzada, mas distribui a manutenção. Uma Trust Authority gerencia uma lista para vários participantes e pode aplicar uma política comum.

Nenhum arranjo dispensa a análise. Antes de incluir uma PKI, é preciso revisar sua política, garantia, obrigações para quem confia, garantias oferecidas e avisos de revogação ou comprometimento. A revisão continua ao longo do tempo. Se a organização não quer herdar confiança nos demais membros, deve inibir o mapeamento de políticas.

Adicionar uma CA pode autorizar novas transações; removê-la pode interromper serviço. A lista não é um catálogo neutro, mas uma superfície de poder que exige dono, motivo e trilha de mudança.

Um recibo para a autoridade de aceitar

Guarde a identidade da aplicação e da relying party, instante da decisão, versão do validador, impressão e origem da âncora, domínio pretendido, finalidade e políticas iniciais. Registre o caminho exato e o processamento de cada mapeamento e restrição.

O recibo inclui ainda a fotografia de filiação, versão da lista ou Trust Authority, emissão e revogação dos certificados cruzados, atualidade de CRL ou OCSP, resultado final, razão precisa e ação posterior.

Uma cadeia construída e recusada não deve ser apagada. Ela documenta que o sistema encontrou conectividade sem convertê-la em permissão.

Escopo da conclusão

A RFC 5217 é informativa e aceita outras formas de interoperabilidade. O mesmo caminho pode ser válido para outra âncora, comunidade ou finalidade. Não há aqui alegação contra uma CA, produto ou implantação específica.

O ponto operacional é separar quatro registros: assinatura, caminho, filiação e aceitação. Um painel que os funde em verde fabrica uma autoridade que nenhum certificado concedeu.

Fontes

Registro complementar de normas

  1. RFC 5217 em texto puro
  2. Registro informativo da RFC 5217
  3. Registro no IETF Datatracker
  4. Histórico no IETF Datatracker
  5. RFC 4949: glossário de segurança da Internet
  6. RFC 5914: formato de âncoras de confiança
  7. RFC 5934: requisitos de gestão de âncoras
  8. RFC 6024: requisitos do protocolo de gestão de âncoras
  9. RFC 5055: validação de certificados baseada em servidor
  10. RFC 6818: atualizações da RFC 5280
  11. RFC 6960: protocolo OCSP
  12. RFC 5019: perfil leve de OCSP
  13. RFC 6962: transparência de certificados
  14. RFC 7030: inscrição por transporte seguro