Resumen

  • La firma PKCS#10 acredita la posesión de la clave; BPKI autentica al representante y enlaza la solicitud con el registro del miembro en AFRINIC.
  • AFRINIC emite el certificado sólo si los recursos pedidos son un subconjunto de los registrados, pero el certificado público no acredita la identidad de la organización ni de una persona.
  • Una ROA válida autoriza a un ASN a originar prefijos; no demuestra que la ruta se anuncie ahora, que sea alcanzable o que todo el AS_PATH sea seguro.
  • Un recibo de procedencia podría guardar versiones, huellas, decisiones y tiempos sin revelar identificaciones, contactos privados ni credenciales.

Un nombre ilegible puede ser exactamente lo previsto

La Declaración de Prácticas de Certificación de AFRINIC dice que el nombre de sujeto de un certificado de suscriptor puede generarlo el emisor y no tiene que ser legible. La razón es funcional: estas credenciales sirven para autorización en seguridad de enrutamiento, no para identificación. Salvo los registros, no acreditan la identidad organizativa; tampoco la identidad individual.

La página de certificación de recursos repite la frontera. Son certificados especializados para verificar el derecho de uso de direcciones IP o números AS, no certificados de identidad. El verificador público necesita saber qué recursos quedaron ligados a una clave, no recibir archivos corporativos o documentos personales.

Siete afirmaciones que no deben fundirse

La primera es posesión: la solicitud PKCS#10 se firma con la clave privada correspondiente a la pública solicitada. No concede representación ni recursos.

La segunda es autenticación del representante. Sólo una persona con certificado BPKI de AFRINIC puede pedir el certificado RPKI. La tercera es el enlace de ese BPKI con la base de miembros donde AFRINIC conserva sus registros de asignación.

La cuarta es el alcance. El certificado se emite únicamente cuando el conjunto solicitado está contenido en los recursos registrados para el miembro. La quinta es validez criptográfica y jerárquica: RFC 6487 exige extensiones IP o AS y que los recursos del emisor abarquen los del hijo a lo largo de la cadena de confianza.

La sexta es la ROA. RFC 9582 la define como autorización para que un ASN origine rutas hacia prefijos, con posibles longitudes máximas. La séptima es lo observado: RFC 6811 extrae el origen de una ruta BGP recibida y lo compara con cargas ROA validadas.

Una prueba correcta no se convierte en la siguiente. La firma no nombra al representante; BPKI no amplía el inventario; el certificado no selecciona un origen; la ROA no anuncia; el resultado Valid no certifica la ruta completa ni obliga a una red a aceptarla.

BPKI es la unión privada detrás del objeto público

La falta del nombre de la empresa admite dos malas lecturas: creer que el certificado identifica legalmente al titular, o creer que AFRINIC no comprobó autoridad. El CPS describe otra arquitectura. BPKI identifica a personas que representan miembros y autentica solicitudes de emisión, renovación y revocación. La base de miembros aporta el estado de los recursos. La prueba de subconjunto limita el resultado.

RFC 6480 explica que RPKI brinda autorización, no autenticación, y evita que el nombre distinguido pretenda ser una identidad descriptiva. Ese nombre puede servir al emisor para volver a su registro interno.

Ese registro tampoco debe convertirse en un título jurídico. Es el registro operativo con el que AFRINIC administra asignaciones. Puede sustentar una decisión de emisión, pero no sustituye una sentencia, un poder corporativo ni todas las relaciones externas.

La ROA permite; BGP muestra lo que ocurrió

RFC 9582 señala que la PKI de validación de ROA aporta autorización, no autenticación ni no repudio. Una ROA válida expresa permiso para una relación ASN-prefijo. Para saber si existe un anuncio hace falta una observación BGP con fuente y hora.

Valid, Invalid y NotFound son resultados de comparar esa observación con VRP. Alimentan la política local y no validan todo el AS_PATH. El TAL de AFRINIC fija la entrada a la jerarquía de confianza; la reproducción exige además el estado del repositorio, manifiestos, CRL, ROA y la muestra BGP.

Un recibo de autorización con privacidad

La propuesta editorial es exportar una cadena tipada, no meter más identidad en el certificado. El bloque registral incluiría hora y huella de la clave, referencia BPKI o rol no secreto, resultado de autenticación, versión o huella del registro del miembro, instantánea de recursos, solicitud, resultado de subconjunto y datos del certificado: serie, SKI, extensiones y vigencia.

El bloque de validación guardaría punto de publicación, manifiesto, CRL, TAL y hora. Para la ROA: certificado EE, ASN, prefijos, maxLength, huella y resultado. Para el origen: fuente BGP, hora, punto de observación, prefijo, origen visto y comparación.

El miembro conservaría la versión completa; el público podría recibir sólo referencias y huellas. Un auditor no necesitaría documentos de identidad, contactos ni secretos. Una corrección enlazaría el recibo sustituido. Cada bloque declararía su límite: no es propiedad legal, anuncio actual, seguridad de camino ni visibilidad mundial.

Fuentes