Resumo

  • CRL Number permanece obrigatório na CRL RPKI, mas o RP verifica somente que a extensão não é crítica e contém inteiro não negativo até 2^159-1; seu valor não ordena listas.
  • A CRL aplicável é o único objeto apontado pelo CRLDP do certificado e listado com hash correspondente no manifesto atual da CA emissora.
  • Seleção, revogação, validação de objeto, estado de origem, entrega ao roteador, política e efeito no tráfego são comprovantes diferentes.

O atalho sobrevivia no manual de recuperação

Considere um procedimento de emergência que diz: “havendo duas CRLs, use a de maior número”. A regra veio do X.509 geral e parece segura. Num teste RPKI, porém, a CRL de maior número não aparece no manifesto atual. A outra aparece, bate com o hash e também é indicada pelo CRLDP. O manual transformou um campo redundante em autoridade paralela.

O caso é construído, não uma ocorrência atribuída. RFC 9829 retira exatamente essa autoridade. A página do RFC Editor e o Datatracker registram um RFC Standards Track de julho de 2025 que atualiza RFC 6487. Histórico, referências, documentos posteriores e errata documentam o texto. Não havia errata correspondente no congelamento; isso não prova conformidade de software.

RFC 5280 dá ao CRL Number sua função original: sequência monotônica para decidir qual CRL substitui outra quando várias podem ser utilizáveis. O RPKI restringe o conjunto. RFC 6481 organiza o ponto de publicação da CA e RFC 9286 define o manifesto assinado com nome e hash de cada objeto atual, inclusive a CRL mais recente.

Se há uma única CRL autorizada no conjunto atual, o contador não precisa votar.

Obrigatório para o perfil, proibido para a escolha

Cada CRL RPKI ainda contém exatamente AKI e CRL Number. O RP processa AKI. Para CRL Number, confirma marcação não crítica e inteiro não negativo dentro do limite. Depois ignora o valor para ordenar.

Presença, sintaxe e competência decisória precisam de campos de auditoria separados. Um parser pode aceitar o número sem permitir que o seletor o consuma.

RFC 9829 recomenda que CRL Number seja igual ao manifestNumber do manifesto que incluirá a CRL. A igualdade melhora reconciliação e diagnóstico, mas não cria fallback. Se os números divergirem, o operador investiga a publicação; o RP não escolhe o maior.

A CRL corrente tem duas testemunhas e um compromisso de bytes

RFC 6487 define certificados de recursos e CRL Distribution Points. Com a atualização, a CRL relevante é identificada pelo manifesto atual do emissor e pelo CRLDP do certificado.

CRLDP sem manifesto aponta um local, não a publicação atual. Manifesto sem CRLDP não prova aplicabilidade ao certificado em exame. Nome sem hash permite troca de conteúdo. Hash em manifesto inválido não tem autoridade validada. A decisão exige que referência, fileList e bytes convirjam.

O manifesto possui sua própria ordenação. manifestNumber, thisUpdate, nextUpdate, assinatura e certificado EE delimitam o estado corrente. O RP compara a sequência com manifestos previamente validados e aplica regras de cache quando a atualização falha.

O artigo sobre RFC 9981 já trata do teto de manifestNumber e da abertura de nova época por nome de arquivo. Aqui o objeto é outro: dentro de uma época válida, nenhum CRL Number pode disputar com o manifesto.

O hash comprova intenção, não todas as consequências

RFC 9286 usa o manifesto para detectar remoção, alteração e substituição por objeto antigo. RFC 9829 diz que o hash expressa criptograficamente a intenção da CA sobre sua CRL mais recente e remove possíveis vetores de replay.

Esse comprovante tem alcance delimitado. Hash correspondente não verifica sozinho a atualidade do manifesto, assinatura da CRL, relação de chave, AKI nem presença do serial. A CRL precisa ser válida; a chave pública que verifica sua assinatura deve ser a mesma que verifica o certificado; a revogação decorre do serial listado nessa CRL aplicável.

RFC 3779 define extensões de recursos IP e AS. A decisão no caminho de certificação não afirma qual rota está sendo anunciada ou encaminhada.

Transporte, validação e roteamento não formam um único evento

RFC 8182 transporta material por RRDP. Rsync oferece outra via. Download bem-sucedido prova entrega de bytes, não sua autoridade. RPs podem manter caches de épocas diferentes; por isso a divergência deve ser investigada por manifesto, hash e regra de cache, e não pelo número aparente da CRL.

A cobertura de RFC 9589 continua proprietária de signing-time, mod-time e transição RRDP–rsync. Ela citou RFC 9829 apenas para limitar o valor probatório do tempo de arquivo. Este texto desenvolve o mecanismo próprio: CRL Number perdeu a capacidade de selecionar.

Depois da revogação, RFC 6811 combina dados validados e rota BGP para formar estado de origem. RFC 8210 entrega dados do cache aos roteadores. Recebimento, política local, RIB, FIB e observação de pacotes continuam separados.

O recibo integral registra publicação, transporte, manifesto validado, convergência CRLDP/nome/hash, validação da CRL, busca do serial, objeto assinado, estado de origem, entrega ao roteador, ação e resultado.

A simplificação só existe no código em execução

RFC 9829 fortalece o contrato removendo um oráculo redundante. A Minimum Initial Specification de Heng Lu explica por que o invariante comum deve permanecer estreito. Reality Layers impede confundir número, compromisso, validação e efeito. Running-Code Primacy exige provar qual caminho o RP executou.

O teste essencial dá o maior número à CRL não listada. Depois altera, um por vez, hash, tempo, assinatura, chave e serial. O resultado deve dizer qual fronteira falhou. Um único indicador “CRL válida” não demonstra que o segundo oráculo foi realmente removido.

Fontes