Resumen

  • IESG abrió el 2 de septiembre la consulta final de la revisión 29 del borrador de atestación en solicitudes de certificado; el plazo termina el 16 de septiembre.
  • Si varios verificadores admiten el mismo identificador de formato, corresponde a la especificación de ese formato resolver cómo escoger el destinatario.

Para sustituir un servicio de verificación no basta necesariamente con encontrar otro que lea los mismos datos. También hay que entender la regla que hace llegar cada solicitud al servicio adecuado. Esa parte de la compatibilidad aparece de forma expresa en un borrador que acaba de entrar en consulta final en IETF.

El anuncio de IESG del 2 de septiembre solicita comentarios sobre draft-ietf-lamps-csr-attestation-29 hasta el 16 de septiembre. Se estudia su avance como Proposed Standard. Sigue siendo un borrador: el anuncio no equivale a una RFC aprobada ni acredita su implantación.

La propuesta permite transportar atestaciones remotas, tanto en formatos normalizados como propietarios, dentro de solicitudes PKCS#10 y CRMF. Una autoridad de certificación o de registro, CA o RA, puede realizar la verificación o recurrir a un verificador externo. Hay, por tanto, margen para distintas configuraciones de servicio.

Quién completa la regla de selección

La sección 4.3 de la revisión 29 señala la ambigüedad que puede surgir cuando varios verificadores aceptan el mismo identificador de objeto, u OID, de un formato de atestación. Recomienda distinguir tipos de verificador o de verificación mediante OID diferentes, aunque la estructura subyacente sea idéntica, o incluir una indicación explícita en una envoltura. La especificación de cada formato debe concretar los mecanismos de encaminamiento y selección del nonce.

El OID no es una dirección de servidor. Identifica una forma de representar los datos que puede ser comprensible para varios servicios. La elección del contexto de procesamiento necesita un acuerdo adicional. El documento común sitúa ese trabajo en las especificaciones de formato, en lugar de decidirlo para todas ellas.

Esto da contenido operativo a una pregunta de gobernanza: ¿quién mantiene la correspondencia entre lo que llega y el servicio que lo evalúa? Cambiar esa correspondencia puede cambiar el destino de una solicitud sin modificar su formato. Una lista comercial de formatos admitidos resulta incompleta si no explica la convención de selección y el comportamiento ante indicaciones ausentes o contradictorias.

El registro exterior no es un directorio de verificadores

La tabla de atributos S/MIME de IANA sigue mostrando el número 59 como id-aa-evidence. El borrador solicita renombrarlo id-aa-attestation conservando el valor. Se trata del atributo exterior del CSR, no de una decisión sobre qué servicio recibirá las pruebas.

Los identificadores de los formatos internos pertenecen a otra capa. La sección 4.2 deja su asignación a los autores de esos formatos, dentro de ramas de identificadores que controlen. Consultar la inscripción del atributo exterior no revela, por sí solo, las reglas de selección de una instalación.

La arquitectura de RFC 9334 permite entender por qué importa esa separación. El propietario del verificador establece la política para evaluar las pruebas; el de la parte que utiliza el resultado determina cómo aprovecharlo. La selección puede llevar los datos a un contexto de evaluación concreto, no simplemente a un programa capaz de decodificarlos. Los papeles pueden reunirse en una organización sin que sus responsabilidades sean idénticas.

Una prueba útil para el operador sería conservar el formato y variar las condiciones de selección documentadas, comprobando el destino efectivo. Es una propuesta de comprobación de este análisis, no una nueva obligación de IETF. La revisión 29 mantiene, además, en la CA o RA la responsabilidad de validar la vinculación entre las atestaciones y la clave pública solicitada.

Las fuentes revisadas no demuestran un incidente de envío erróneo ni cuantifican costes de sustitución. La novedad informativa es la frontera de diseño sometida ahora a consulta: compartir el transporte facilita la integración, pero escoger el servicio sigue requiriendo una convención precisa.

Fuentes

  1. Consulta final de IESG
  2. Borrador de atestación del CSR, revisión 29
  3. Arquitectura RATS, RFC 9334
  4. Asignaciones SMI de IANA