Resumen

  • RFC 9734 registra id-kp-imUri, OID 1.3.6.1.5.5.7.3.40, para identificar certificados destinados a firmar credenciales de identidad de mensajería instantánea sin darles una finalidad TLS general.
  • La EKU contesta para qué puede utilizarse la clave. El identificador de la cuenta aparece en subjectAltName; la validación de ruta, la comparación del nombre esperado, el estado actual y la autorización son comprobaciones diferentes.
  • MLS enlaza la clave pública del certificado con la clave de firma del LeafNode, pero deja a la aplicación y al servicio de autenticación la selección y validación de los identificadores aceptables.

Dos empleados comparten un alias operativo durante un relevo. Ambos teléfonos muestran el mismo URI de mensajería. Uno ya fue retirado de la gestión corporativa, pero conserva una clave y un certificado dentro de su período de validez. El panel ve id-kp-imUri y una cadena correcta. ¿Cuál de los dos dispositivos debe entrar en el grupo?

El OID no contiene esa respuesta.

RFC 9734 creó en febrero de 2025 una finalidad extendida para certificados de identidad de clientes de mensajería. La motivación es evitar que una credencial emitida para ese contexto use identificadores generales como id-kp-clientAuth o id-kp-serverAuth y termine aceptada en otro protocolo.

La recomendación de no mezclar esas finalidades es una reducción concreta de superficie. Solo funciona si el emisor mantiene el perfil estrecho y si la aplicación rechaza el certificado presentado fuera de ese perfil. El estándar coordina una condición necesaria; no ejecuta la política.

La finalidad, el nombre y la decisión viven en lugares distintos

RFC 5280 define Extended Key Usage como la lista de finalidades de la clave certificada. Define subjectAltName como el lugar donde se vinculan identidades al sujeto. Cuando la identidad es una URI, aparece como uniformResourceIdentifier.

Por tanto, un certificado puede decir al mismo tiempo:

  • esta clave fue emitida para credenciales de identidad IM;
  • el emisor vinculó al sujeto el URI im: presentado;
  • la cadena llegó a una raíz aceptada;
  • la firma presentada corresponde a la clave privada.

Todavía faltan preguntas: ¿la aplicación esperaba exactamente ese URI?, ¿qué prueba de cuenta usó el emisor?, ¿sigue activa la cuenta?, ¿el dispositivo está autorizado?, ¿puede entrar en este grupo?, ¿el mensaje produjo el efecto esperado?

RFC 3860 define el URI im: como identificador de un buzón instantáneo y recomienda incluirlo en subjectAltName para operaciones S/MIME de mensajería. También deja claro que su servicio abstracto asume entrega fiable y no aporta garantía de entrega en la capa de aplicación. El identificador del destinatario no es un acuse de recibo.

La alternativa XMPP tampoco fusiona identidad y permiso. RFC 6121 utiliza JID para identificar elementos y recursos, pero exige comprobaciones de autorización independientes para operaciones como cambios de roster. Un nombre correcto puede llegar acompañado de una acción prohibida.

El registro coordina semántica; no conoce la emisión

El registro SMI de IANA reserva el decimal 40 bajo el arco PKIX. Así, bibliotecas, emisores y clientes reconocen el mismo id-kp-imUri. IANA no verificó la cuenta del titular ni el software que consumirá el certificado.

RFC 9734 permite que el emisor marque la EKU como crítica o no crítica. RFC 5280 permite que una aplicación exija una finalidad particular. El resultado operativo depende de la combinación: perfil emitido, parser, política local y comportamiento de rechazo.

Una métrica de «certificados con el nuevo OID» es incompleta. Hace falta saber cuántos contienen además clientAuth, serverAuth o anyExtendedKeyUsage; cuántos validadores ignoran una extensión crítica desconocida; cuántas rutas aceptan un certificado sin la finalidad requerida; y cuántas claves se reutilizan en otros protocolos.

Una ruta PKI no aporta el identificador de referencia

Una ruta válida prueba que determinadas firmas, fechas, restricciones y políticas fueron aceptadas desde el certificado final hasta una ancla elegida. No revela qué cuenta quiso autenticar la aplicación.

RFC 9525 distingue, en su ámbito de identidades de servicio, identificadores presentados e identificadores de referencia. La aplicación sabe qué esperaba; el certificado ofrece nombres que deben compararse. Esta separación también aparece de forma normativa en MLS.

Un certificado con dos URI no permite escoger uno por intuición. Un alias renombrado no se vuelve actual porque la cadena siga firmada. Un nombre visualmente parecido no debe normalizarse sin una regla conservada. El registro de validación necesita ambos lados: referencia, valores presentados, algoritmo de comparación, política, tiempo y motivo del resultado.

MLS confirma una clave y devuelve la política a la aplicación

RFC 9420 exige que la clave pública del certificado final en un X509Credential sea idéntica a la signature_key del LeafNode. Esa igualdad evita una sustitución básica entre credencial y firma de grupo.

Después interviene el servicio de autenticación. La aplicación mantiene identificadores de referencia para el miembro. La credencial presenta identificadores. El servicio valida que la credencial representa legítimamente esos nombres y que satisfacen la referencia. Los nuevos certificados y los sustitutos deben validarse en los eventos definidos de incorporación y actualización.

El expediente de admisión debe separar:

  1. clave de certificado igual a clave del LeafNode;
  2. ruta, fechas, restricciones y EKU aceptadas;
  3. URI presentada igual a referencia bajo una regla conocida;
  4. cliente autorizado para el grupo, rol y epoch concretos.

La misma cuenta puede estar presente en varios dispositivos. RFC 9420 avisa que una identidad de aplicación no tiene por qué identificar de forma única al cliente. El índice de hoja también cambia de significado entre epochs. Cuando el riesgo depende del dispositivo, se necesita un identificador adicional de enrolamiento o cliente.

La cuenta puede cambiar mientras el certificado permanece

El momento de emisión no congela el directorio de cuentas. Una persona abandona un equipo, un teléfono se pierde, un alias se reasigna o un tenant migra. La clave continúa firmando hasta que otra capa cambie el resultado.

RFC 6960 limita cuidadosamente el significado de OCSP. Un estado good indica como mínimo que el número consultado no figura revocado dentro de su intervalo; no confirma necesariamente la emisión ni toda la validez. unknown no es good. La frescura se interpreta con thisUpdate, nextUpdate y producedAt.

El borrador citado por RFC 9734, draft-barnes-mimi-identity-arch-02, examina credenciales cortas, OCSP y CRL para identidad de extremo a extremo. Sigue siendo trabajo en curso. Su utilidad aquí es mostrar que la revocación es información externa: el certificado no puede actualizarse solo cuando deja de ser aceptable.

Convertir el verde en una cadena auditable

La emisión debe guardar URI solicitado, método de prueba, autoridad, política, clave, subjectAltName, EKU y serial. La validación debe guardar referencia, nombres presentados, ancla, cadena, resultado EKU, estado y frescura. MLS debe guardar grupo, epoch, LeafNode, credential, decisión del servicio de autenticación y regla de admisión. La entrega debe guardar únicamente su propio evento observado.

El texto, el XML, la ficha editorial, los errata y el historial IETF acreditan el documento, no una implantación.

La primacía del código en ejecución exige observar qué controles rechazaron realmente una credencial. La especificación inicial mínima permite compartir el OID sin centralizar las decisiones locales. Las capas de realidad mantienen separados registro, extensión, nombre, autorización y resultado.

El logro de RFC 9734 no es certificar más. Es permitir que el certificado afirme menos y con mayor precisión.

Fuentes