Resumen

  • Una RSC válida demuestra que una parte con control suficiente de la CA emisora firmó una lista que vincula un subconjunto de AS o direcciones IP con hashes exactos de objetos digitales. No demuestra identidad real, titularidad, poder societario, verdad del contenido ni integridad del expediente.
  • La aceptación exige registrar por separado la validación CMS y del certificado, la coincidencia de cada archivo y sus advertencias, y la fuente externa que identifica al actor y confirma su mandato para el propósito concreto.

Imaginemos una revisión previa a la compra de activos de red. Es un caso ilustrativo, no un hecho real. La contraparte entrega una hoja de cálculo de direcciones, un archivo comprimido con inventario técnico y un objeto .sig. La herramienta confirma los dos hashes, la cadena RPKI, la CRL y que los recursos declarados están contenidos en el certificado EE.

La lista firmada contiene una tercera entrada cuyo archivo no llegó. Según RFC 9323, eso no invalida necesariamente la verificación de los dos objetos suministrados; la implementación debería advertir que la lista es mayor que el conjunto presentado. El comité, sin embargo, registra que la contraparte es dueña, puede vender y entregó un expediente completo.

La firma funcionó. La organización hizo que respondiera tres preguntas ajenas.

Recursos, algoritmo y lista

La RSC es un objeto firmado RPKI protegido con CMS. Usa id-ct-signedChecklist y el OID 1.2.840.113549.1.9.16.1.48. El registro RPKI de IANA incluye Signed Checklist y .sig; el tipo de medio es application/rpki-checklist.

El bloque de recursos debe contener identificadores de AS, bloques IP o ambos. Cada recurso del eContent ha de ser subconjunto del correspondiente recurso RFC 3779 en el certificado EE. No se permite inherit. El firmante no puede ampliar con el RSC el alcance que la cadena le ha delegado.

La lista contiene una o más entradas con hash obligatorio y nombre portátil opcional. Los nombres presentes son únicos entre entradas nombradas; los hashes sin nombre son únicos entre entradas anónimas. El objeto identifica bytes bajo un alcance de recursos. No contiene una identidad mercantil ni una finalidad contractual.

El verde se construye en capas

RFC 6488 exige CMS SignedData en DER, atributos permitidos, exactamente un certificado EE correspondiente al firmante, firma correcta y ruta válida hasta un ancla RPKI. Esas condiciones son necesarias pero no suficientes: el tipo de objeto añade reglas.

RFC 9323 verifica estructura, recursos, lista y ausencia de SIA en el certificado EE. El certificado debe estar vigente y no revocado. Si caduca o aparece en la CRL, un objeto antes válido deja de serlo.

Después se calcula el hash sobre los bytes recibidos. Con nombre, el modo filename-aware exige una única entrada coincidente con exactamente ese nombre. Sin nombre, filename-unaware exige una única entrada coincidente que omita el nombre. Forzar otro modo cambia la semántica de la prueba y debe quedar registrado.

Todavía falta el cuarto plano: decidir quién presentó el objeto, si puede obligar a la entidad y si los archivos satisfacen la finalidad comercial o legal. Un sistema serio muestra los cuatro resultados; no los comprime en un icono.

El hash conserva también una falsedad

El algoritmo no interpreta el contenido. Un inventario falso conserva exactamente su falsedad cuando el hash coincide. La hoja puede listar recursos que la contraparte no puede vender, aunque sus bytes sean los firmados.

También ocurre lo contrario: dos textos que una persona considera equivalentes pueden diferir en saltos de línea, codificación o espacios y producir otro digest. RFC 9323 recomienda compresión sin pérdida para texto, reduciendo canonicalizaciones accidentales. Esa medida protege octetos, no afirmaciones.

El nombre de archivo solo añade una condición de correspondencia. Que una entrada se llame inventario no prueba que enumere todos los activos.

Una verificación parcial no es una diligencia completa

RFC 9323 permite que no se utilicen todas las entradas en una operación. Es útil cuando cada receptor necesita un subconjunto distinto. La advertencia por entradas no presentadas entrega la decisión al usuario.

La empresa debe definir fuera de la RSC qué constituye un expediente completo: registros de recursos, asignaciones a clientes, gravámenes, litigios, propiedad de equipos, incidentes, accesos y poderes. La RSC puede demostrar que los archivos entregados coinciden con su lista; no define qué debía entregarse.

El informe separa cuatro conjuntos: entradas presentadas y coincidentes, archivos presentados sin coincidencia, entradas RSC sin archivo y requisitos de negocio ausentes incluso de la RSC. Solo así el responsable ve qué vacío está aceptando.

Control de CA no equivale a identidad

RFC 9323 advierte que los datos son autoafirmados. El relying party no debe suponer nada salvo que el firmante tuvo control suficiente de la CA para crear el objeto. La CA superior no comprobó el contenido.

RFC 9255 explica que la I de RPKI significa Infrastructure, no Identity. La infraestructura autoriza afirmaciones sobre recursos, pero no autentica al titular real ni una transacción.

En RPKI alojada, una cuenta puede pedir al servicio que firme sin que el usuario posea la clave. Las credenciales pueden estar en manos del dueño, de un administrador de red con atribuciones limitadas, de un proveedor o de un intruso. Incluso el administrador legítimo quizá no pueda vender activos o firmar contratos.

Los nombres Subject e Issuer tampoco son identidad descriptiva según RFC 6487. Hace falta una autoridad exógena: registro mercantil, mandato del consejo, poder contractual, orden judicial o autenticación conocida. La comprobación debe abarcar actor, entidad, acción, propósito y vigencia.

Distribución invisible, revocación acoplada y tiempo incierto

Las RSC no se publican en el sistema de repositorios RPKI. Quien no recibe una copia puede ignorar su existencia. Un salto de seriales de certificado o una entrada CRL sin objeto público no demuestra que exista una RSC.

El canal de entrega es otra evidencia. Portal autenticado, correo conocido y enlace anónimo pueden transportar los mismos bytes con distinta fuerza sobre quién los presentó. El canal no sustituye la validación; la validación no sustituye el canal.

El modelo de certificado EE de un solo uso permite que revocar el certificado revoque el objeto. Una CA puede reutilizar técnicamente una clave para varias RSC, pero entonces no puede revocarlas individualmente. Ahorrar una emisión acopla decisiones independientes.

RFC 9589 hace obligatorio signing-time y elimina binary-signing-time, pero no exige que el valor sea correcto. No es una fecha fiable de la firma. Tiempo de validación, vigencia, CRL y cronología contractual siguen separados.

El expediente debe registrar la no-prueba

La aceptación conserva RSC y hash, canal, OID, certificado, cadena, CRL, momento, recursos, algoritmo, bytes, nombres, modo, coincidencias, entradas no utilizadas, advertencias, fuente de identidad, mandato y decisión. Además declara expresamente que no se probaron propiedad, verdad, completitud, representación legal, fecha fiable ni autorización de origen BGP.

La RSC no es débil por esos límites. Es fuerte porque su alcance puede verificarse sin ambigüedad. La debilidad aparece cuando el receptor rellena con suposiciones todo lo que la estructura dejó fuera.

Fuentes