Resumen

  • CRL Number sigue siendo obligatorio en una CRL de RPKI, pero el validador solo comprueba que no sea crítico y que contenga un entero no negativo dentro del límite; no puede ordenar con él.
  • La CRL aplicable debe ser simultáneamente el destino del CRLDP del certificado y el objeto listado, con hash coincidente, en el manifiesto vigente del emisor.
  • Una selección correcta aún no demuestra ausencia de revocación, validez de un objeto firmado, autorización de origen, aplicación de política ni resultado de tráfico.

La prueba no es cuál cifra parece más nueva

Partamos de una prueba de laboratorio: se entregan al RP dos CRL firmadas por la misma CA. El archivo ajeno al manifiesto lleva el número más grande. El archivo listado por el manifiesto tiene un número menor y coincide exactamente con su hash; además, el CRLDP del certificado lo identifica. Si el RP escoge el primero, ha obedecido un dato bien formado y violado el contrato de RPKI.

No es un incidente ni describe un producto. Es la frontera que fija RFC 9829. La ficha del RFC Editor y el registro del Datatracker lo sitúan como estándar de julio de 2025 que actualiza RFC 6487. El historial, las referencias, los documentos posteriores y la consulta de erratas conservan procedencia documental. Al congelar las fuentes no aparecía ninguna errata; eso no certifica implementaciones.

La regla general de RFC 5280 explica la tentación. CRL Number es una secuencia creciente para distinguir qué CRL sustituye a otra cuando varias pueden ser utilizables. Pero RFC 6481 organiza el punto de publicación de una CA RPKI y RFC 9286 introduce un manifiesto firmado que enumera cada objeto vigente mediante nombre y hash. Su fileList incluye una sola CRL actual.

La estructura elimina la elección que justificaba el contador.

Bien formado no significa competente

Cada CRL RPKI debe contener exactamente AKI y CRL Number. El RP procesa AKI. En CRL Number verifica dos cosas: que la extensión sea no crítica y que su entero sea no negativo y no exceda 2^159-1. Después debe ignorar el valor.

Por tanto, un campo puede ser obligatorio, válido y, aun así, incompetente para una decisión concreta. Este matiz impide convertir cualquier señal disponible en mando.

RFC 9829 recomienda igualar CRL Number con el manifestNumber que incluirá la CRL. Esa correspondencia ayuda a localizar errores de publicación. No cambia el verbo normativo: el RP no selecciona por CRL Number. Ante una discrepancia debe registrar evidencia, no resucitar “el mayor gana”.

Dos referencias deben apuntar a los mismos bytes

RFC 6487 define el certificado de recursos y su CRL Distribution Points. La actualización de RFC 9829 exige identificar la CRL actual mediante el manifiesto vigente del emisor y el CRLDP del certificado.

El CRLDP delimita aplicabilidad. El manifiesto delimita la publicación vigente y compromete los bytes. El nombre sin hash no impide sustitución. El hash sin manifiesto válido carece de una firma de publicación aceptada. El manifiesto sin CRLDP no basta para asociar cualquier certificado. La autoridad aparece cuando todas las piezas convergen.

El orden no desaparece del sistema: cambia de lugar. RFC 9286 usa manifestNumber, thisUpdate y nextUpdate para comparar y acotar manifiestos. El RP valida la firma y el certificado EE del manifiesto, su tiempo y su relación con estados anteriores. Solo entonces su fileList puede seleccionar objetos.

El artículo ya publicado sobre RFC 9981 analiza el techo de manifestNumber, el cambio de nombre y una nueva época de comparación. Esta pieza no ocupa ese terreno. Pregunta qué ocurre dentro de una época válida cuando dos CRL compiten por parecer actuales.

El hash expresa intención con alcance limitado

El hash del fileList vincula los bytes recuperados con la intención firmada de la CA. Ayuda a detectar sustitución antigua, borrado o modificación. RFC 9829 lo usa para eliminar vectores de repetición derivados de tener más de un criterio de selección.

Pero no sustituye los demás controles. Hay que validar el manifiesto, su frescura y certificado; verificar la CRL, AKI, firma y clave; y buscar el número de serie del certificado. La clave pública que valida la CRL debe ser la misma que valida el certificado. Solo la presencia del serial en esa CRL aplicable determina revocación.

RFC 3779 define extensiones para recursos IP y AS. Esas extensiones no describen una ruta BGP ejecutada. Una decisión de revocación correcta es una entrada de la validación posterior, no un resultado de red.

Una descarga correcta solo crea una copia

RFC 8182 ofrece RRDP para transportar objetos del repositorio. También existe el camino rsync. Ninguno decide qué manifiesto es vigente. Diferencias de caché y tiempo pueden hacer que dos RP trabajen con vistas distintas; el recibo útil incluye época de manifiesto, hash y regla de caché.

La cobertura anterior de RFC 9589 conserva su asunto: hora de firma CMS, mod-time y cambio RRDP–rsync. Citó RFC 9829 para mostrar que la fecha de un archivo no selecciona la CRL. Aquí se analiza el mecanismo completo que aquella mención dejó como apoyo: por qué tampoco la cifra CRL Number puede ser el selector.

Más abajo, RFC 6811 combina datos de origen validados y una ruta para producir un estado. RFC 8210 lleva información del caché al router. Aún faltan recepción, política, RIB, FIB y observación del plano de datos.

Por eso el recibo debe preservar diez eventos: publicación; transporte; selección del manifiesto; convergencia CRLDP/fileList/hash; validación de CRL; consulta del serial; validación del objeto; cálculo de origen; entrega al router; decisión y efecto observado.

La norma se hizo más pequeña para ser más fuerte

RFC 9829 no añade una capa de gobierno. Quita una. Conserva CRL Number por compatibilidad de perfil, pero limita lo que puede decidir. Minimum Initial Specification de Heng Lu ayuda a leer esa resta como disciplina: compartir el mínimo imprescindible. Reality Layers separa símbolo, selección, validación y consecuencia. Running-Code Primacy exige observar qué selector ejecutó el RP y qué hizo el router.

Una suite de conformidad debe colocar deliberadamente el mayor número en la CRL no listada y variar por separado hash, frescura, firma, clave y pertenencia del serial. Cada fallo necesita un código causal. “CRL aceptada” no ofrece una prueba suficiente.

Fuentes