Resumen

  • RFC 9509 asigna los EKU id-kp-jwt, id-kp-httpContentEncrypt e id-kp-oauthAccessTokenSigning a tres trabajos distintos que antes no tenían identificadores PKIX comunes.
  • 3GPP permite desplegar un certificado por finalidad o uno con varias finalidades; la opción elegida cambia el alcance de una clave comprometida, una renovación fallida o una revocación.
  • La finalidad certificada es solo una capa: confianza inicial, identidad NF, KU/EKU, operación JOSE, claims, política de autorización y resultado del servicio necesitan pruebas propias.

Supongamos que se revoca la clave que firma una Client Credentials Assertion. ¿Debe caer también la sesión TLS de la misma función? ¿Y su capacidad para descifrar mensajes entre redes o para verificar un token emitido por el NRF? La respuesta no está en el número de serie del certificado. Está en la cartera que el operador decidió construir.

RFC 9509 fue publicada en marzo de 2024 como Proposed Standard, según la ficha del RFC Editor y el historial de Datatracker. Su aportación básica puede verse en el registro SMI de IANA: 37 es id-kp-jwt, 38 es id-kp-httpContentEncrypt y 39 es id-kp-oauthAccessTokenSigning.

El primero identifica la validación de una firma JWS sobre un JWT, incluida la CCA. El segundo se aplica al cifrado de objetos JSON con JWE, por ejemplo en el perímetro SEPP. El tercero identifica la firma de tokens de acceso del marco OAuth 2.0. La autenticación TLS de cliente y servidor conserva sus EKU anteriores.

La novedad evita una herencia peligrosa. Una función consumidora con certificado de cliente TLS no debería poder firmar una CCA solo porque la clave permite firmas. Tampoco una credencial de consumidor debería hacer pasar a su titular por productor. RFC 9509 exige coherencia entre finalidad y Key Usage: los trabajos de firma necesitan una KU de firma; el transporte de la clave de contenido JWE usa keyEncipherment.

La cartera es una decisión de diseño

RFC 5280 obliga a satisfacer KU y EKU cuando ambas extensiones están presentes. RFC 9509, sin embargo, no prohíbe añadir otras finalidades. El verificador puede aplicar las listas permitidas y excluidas de RFC 9336, incluidas restricciones sobre combinaciones concretas.

La norma actual 3GPP TS 33.310 V19.5.0 dice expresamente que una implementación puede usar un certificado diferente para cada finalidad o un certificado con múltiples finalidades. La elección alcanza tanto a la confianza inicial como al certificado final de la función.

Separar certificados acota la autoridad y el radio de una incidencia. Una revocación por abuso de CCA puede dejar intacta la identidad TLS; una clave JWE expuesta no se convierte en clave de firma OAuth. Pero crece el trabajo de inventario, inscripción, distribución, renovación, expiración y propagación de revocaciones.

Combinar finalidades reduce objetos y puede simplificar la automatización. También vincula servicios a una sola clave, ruta de validación y fecha. Una renovación tardía o una revocación necesaria para un trabajo puede interrumpir los demás. Ninguna de estas consecuencias convierte una opción en mandato universal; obliga a documentar quién aceptó el acoplamiento.

El OID no contiene la identidad

Antes de emitir, TS 33.310 establece una confianza inicial mediante certificado OAM, parámetros de perfil NF firmados o una clave inicial. La RA/CA verifica la prueba de posesión, el NF Instance ID y, cuando corresponde, el tipo NF. Si la confianza inicial incluye un EKU, puede exigir que la solicitud lo reproduzca antes de emitir el certificado final.

Por eso id-kp-jwt no identifica una función. Solo limita un uso de la clave certificada. La identidad en subjectAltName, la cadena, la vigencia, la revocación y el expediente de inscripción responden a preguntas diferentes.

En ejecución, 3GPP TS 33.501 V19.5.0 define la CCA como un JWT firmado por el consumidor. El receptor valida JWS, identidad y tiempo. En OAuth, el NRF es servidor de autorización, el consumidor es cliente y el productor es servidor de recursos. Antes de ejecutar una operación, el productor comprueba emisor admitido, firma, sujeto, audiencia, identidad de servicio o segmento, scope, acciones adicionales, expiración y, en ciertos casos, la coherencia con la CCA y el certificado TLS.

La TS 29.500 concreta las interfaces de la arquitectura basada en servicios; la TS 29.573 cubre la interconexión PLMN y el contexto SEPP. El EKU de cifrado dice para qué se certificó la clave. No demuestra que un JSON particular fuese admisible, llegara, se descifrara o causara una acción.

Una revocación puede llegar tarde a la selección

TS 33.310 advierte que un NRF puede devolver una instancia productora cuyo certificado ya fue revocado si no conoce todavía el cambio. La vigencia criptográfica y el estado de descubrimiento no son la misma realidad. El recibo completo debe guardar método de confianza inicial, instancia y tipo NF, certificado y cadena, KU/EKU, combinaciones, algoritmo y cabeceras JOSE, claims relevantes, versión de política, evidencia de revocación, petición, respuesta y telemetría.

La finalidad puede quedar expuesta aunque la operación nunca ocurra. TLS 1.2 puede transmitir certificados en claro; TLS 1.3 protege esos mensajes después de ServerHello; Certificate Transparency puede publicar certificados de confianza pública. La observación de un EKU prueba preparación, no uso.

La lectura editorial procede de tres textos declarados: primacía del código en ejecución, capas de realidad y especificación inicial mínima con adopción local. Aplicados aquí, obligan a separar el nombre común del registro, la configuración del operador y el servicio realmente prestado.