Resumen

  • El grupo COSE presentó el 24 de septiembre de 2026 la revisión 21 del borrador C509. La revisión 20 había sido aprobada por el IESG en julio, pero el texto sigue en la cola editorial de RFC.
  • La nueva redacción identifica la secuencia CBOR sometida a firma y fija reglas precisas para el número de serie y la abreviación del campo emisor.
  • Un certificado X.509 recodificado y reversible conserva una firma DER; otro C509 firmado de origen utiliza bytes CBOR. Los dos conservan la necesidad de validar la cadena de certificados.

Hay una diferencia entre recibir un certificado y poder verificar exactamente el certificado que el emisor firmó. En un sensor, vehículo o dispositivo de memoria limitada, ahorrar espacio puede ser decisivo. Pero si se sustituyen representaciones sin controlar la secuencia firmada, la aplicación podría confundir un éxito de lectura con una comprobación criptográfica. La revisión 21 ofrece detalles comprobables para esa transición.

El borrador define dos caminos. En el tipo 3, el certificado X.509 ya fue firmado en DER y después se convierte de forma reversible a CBOR; la firma original acompaña al objeto compacto. Un verificador puede reconstruir la forma DER para comprobarla. En el tipo 2, la firma se calcula sobre el propio CBOR y el tratamiento debe integrarse antes en la emisión. Un sistema que sólo admite DER no pasa automáticamente a entender el tipo 2, aunque el modelo de certificado conserve la semántica X.509.

La novedad concreta de septiembre está en la definición de los bytes. La revisión llama array CBOR al certificado completo, aclara que sus elementos forman una secuencia y delimita la subsecuencia TBSCertificate que se firma sin el valor final de firma. Para los números de serie impone una cadena de bytes incluso si un entero CBOR pequeño bastaría como número. Al reconstruir DER para el tipo 3, el cero inicial se repone cuando lo exige el bit más alto. El emisor puede abreviarse con null únicamente cuando coincide con el sujeto octeto por octeto; una apariencia igual no cumple esa condición.

No hay que leer esos cambios como noticia de un incidente ni como descubrimiento de un ataque. Son aclaraciones del formato. El IESG aprobó la versión 20 el 20 de julio y el documento entró en la cola del editor de RFC. La versión 21 enviada el 24 de septiembre continúa allí: el seguimiento todavía muestra una respuesta de autores requerida y trabajo IANA pendiente. Ni un número definitivo de RFC ni una nueva aprobación constan en ese historial.

También permanece fuera del alcance de la conversión la elección de en quién confiar. Las consideraciones de seguridad del borrador exigen la validación de ruta del RFC 5280 antes de considerar fiable un C509; los encabezados COSE que transportan certificados son entradas no confiables hasta verificarse mediante un mecanismo de confianza. Incluso registrar un algoritmo no equivale a recomendarlo. Los ejemplos de reducción de tamaño ilustran posibilidades, no el despliegue medido de un parque de dispositivos.

Por eso convendría que una prueba local conservara el tipo de certificado, la versión del conversor, una muestra exacta de bytes firmados, la reconstrucción y el resultado por familia de verificadores. Es una propuesta editorial para quien aprueba una implantación, no una obligación nueva del IETF. El ahorro de ancho de banda sólo merece llamarse interoperabilidad cuando ambas rutas de comprobación quedan demostradas.

Fuentes