Resumo

  • Com os OIDs novos de política e extensões, o RFC 8360 permite que uma relying party compatível calcule o Verified Resource Set e prossiga com a parte comprovada de um certificado de CA que sobredeclara recursos.
  • O algoritmo não autoriza o excedente: toda ROA precisa manter seus prefixos dentro de VRS-IP, todo certificado de roteador precisa manter seus ASNs dentro de VRS-AS e o perfil antigo continua sujeito à rejeição integral.

A diferença entre a lista e o direito

Certificados de recursos da RPKI ligam chaves públicas a blocos de endereços IP e números de sistemas autônomos. Uma autoridade não cria esse direito apenas escrevendo um conjunto no certificado. A declaração precisa caber no que o emissor recebeu e continuar cabendo em cada etapa até uma âncora de confiança. O RFC 3779 definiu as extensões; o RFC 6487 organizou o perfil usado na RPKI.

No procedimento original, qualquer recurso a mais tornava inválido o certificado de CA. Como os descendentes dependiam desse caminho, a falha atingia inclusive certificados e objetos relacionados apenas aos recursos que continuavam corretamente delegados. Quanto mais alto estivesse o certificado, maior poderia ser a subárvore atingida.

O excesso pode nascer de operações comuns. Uma transferência reduz a carteira de recursos do pai; o filho demora a renovar seu certificado; bancos de dados e sistemas de emissão ficam momentaneamente desencontrados. Em 2018, os autores do RFC 8360 consideravam baixa a probabilidade, mas alto o impacto potencial. Sua resposta não foi confiar na informação errada, e sim separar o erro de tudo o que ainda tinha uma cadeia válida.

Geoff Huston, George Michaelson, Carlos Martinez, Tim Bruijnzeels, Andrew Newton e Donald Shaw assinam o RFC 8360 em conjunto. O mecanismo alternativo usa o Verified Resource Set, ou VRS. Em vez de tomar o conjunto declarado como autoridade final, o validador calcula a interseção sustentada pelo caminho de certificação.

A interseção trabalha em duas dimensões

VRS-IP cobre recursos de endereços, enquanto VRS-AS cobre números de AS. Quando não há sobredeclaração, o algoritmo novo termina no mesmo ponto do RFC 6487. Quando há, a diferença entre a declaração e o VRS é marcada e retirada do conjunto utilizável.

A mudança é explícita no certificado. O RFC 8360 criou uma política de certificados versão 2 e novos OIDs para extensões de recursos. Diante desse perfil, uma relying party que implemente o RFC emite um aviso com o excesso e continua usando a interseção. Diante da política antiga do RFC 6487, precisa rejeitar. Portanto, não existe uma tolerância geral aplicada por conveniência a certificados legados.

Nem um VRS vazio abre exceção. O RFC permite não rejeitar imediatamente o certificado de CA, porque o estado pode resultar de uma transição temporária. Mas um conjunto vazio não sustenta qualquer autorização subordinada. Manter o nó na árvore não lhe entrega um recurso provisório.

No exemplo normativo, uma CA filha declara 192.0.2.0/24, sustentado pela cadeia, e 198.51.100.0/24, que não é. O primeiro permanece no VRS; o segundo é excluído. Uma ROA para o bloco legítimo pode validar. Uma ROA para o outro não pode. O ganho de disponibilidade está todo do lado comprovado da fronteira.

A ROA ainda enfrenta sua própria prova

A sobrevivência do certificado de CA não transforma os objetos abaixo dele em válidos. O RFC 6482 define a ROA, e o RFC 8360 exige que todos os seus prefixos estejam dentro do VRS-IP do certificado de entidade final. Misturar um prefixo válido com outro excluído pode invalidar a ROA inteira.

Daí vem uma recomendação prática: separar ROAs por recursos independentes pode reduzir o raio de falha. Se um prefixo sair da delegação, suas autorizações deixam de arrastar outras no mesmo objeto. Certificados de roteador BGPsec seguem raciocínio semelhante. Todos os ASNs declarados precisam caber em VRS-AS; certificados distintos por ASN podem conter a perda.

O escopo também tem limites. O cálculo acontece sob uma única âncora de confiança. Reivindicações sobrepostas provenientes de várias âncoras ficam fora do RFC 8360. E uma configuração local da relying party não substitui a cadeia como fonte de autoridade. O algoritmo conserva apenas o que essa cadeia comprova.

A ordem da migração não pode ser invertida

Os OIDs novos exigem software novo. Um validador que desconheça o perfil alternativo rejeitará o certificado. Por isso, o RFC orienta atualizar as ferramentas das relying parties antes de as CAs emitirem certificados com os OIDs v2. A capacidade do produtor de publicar não prova a capacidade dos consumidores de interpretar.

Isso não obriga uma virada simultânea. A escolha é feita certificado por certificado. Uma raiz pode conservar a política antiga e uma CA subordinada adotar a nova, desde que os validadores entendam o algoritmo. Assim, a contenção pode começar onde uma inconsistência teria mais descendentes.

O RFC 8488 registra como um validador expunha essa tensão em 2018. A descrição do RIPE NCC Validator citava uma opção operacional de validação estrita e, fora dela, um uso configurado do algoritmo alternativo. É evidência histórica de uma implementação específica, não garantia sobre a versão atual do produto nem regra que substitua a sinalização por OID do RFC 8360.

Bruijnzeels e seus coautores mudaram a unidade do fracasso. O erro continua aparecendo como erro; o recurso indevido continua sem autoridade; só a parte corretamente herdada permanece disponível. Em segurança de roteamento, essa precisão importa: conter não significa perdoar.

Fontes