Resumen

  • La revisión 21 define un C509 reversible al DER firmado y otro firmado de forma nativa sobre CBOR.
  • Poder decodificarlo y verificar una firma no basta: RFC 5280 sigue gobernando la validación de ruta y los certificados en parámetros COSE siguen siendo entrada no confiable.
  • Un número de registro identifica una sintaxis; no recomienda el algoritmo ni concede permiso de uso.

El objeto firmado no es el mismo

El tipo 3 es una recodificación invertible de un certificado X.509 DER. El receptor reconstruye exactamente el objeto DER y verifica la firma original. El tipo 2 firma el grupo CBOR TBSCertificate directamente. Ambos conservan la semántica de X.509, pero una prueba operativa debe anotar el tipo y los bytes exactos sometidos al verificador. “Se pudo leer C509” no dice qué se firmó.

La reducción utiliza conocimiento del esquema: elimina campos estáticos, convierte muchos OID en enteros breves y comprime fechas y ciertos puntos de curva. Es una ganancia de representación y transporte. No demuestra custodia actual de la clave, competencia del emisor, vigencia, propósito ni autorización de una acción.

El borrador exige la misma validación de ruta de RFC 5280 antes de considerar confiable un certificado. Esa evaluación reúne anclas, restricciones de CA, tiempo, nombres, políticas, extensiones críticas y uso. La firma es necesaria, pero no decide todo lo demás.

Una cabecera no puede nombrar su propia raíz

Los parámetros COSE c5b, c5c, c5t y c5u transportan certificados o referencias. Siguen siendo entrada no confiable. Un certificado autofirmado recibido allí no puede ampliar el almacén de anclas sin una autorización distinta. Proteger la cabecera autentica el contenedor; no entrega al contenedor la potestad de elegir su autoridad.

Los nuevos tipos de medios, formatos CoAP, tipo de certificado TLS y selector TLSA solucionan identificación e interoperabilidad. No sustituyen DNSSEC ni las reglas DANE, la identidad del servicio o la política de la aplicación.

La especificación también advierte que registrar un algoritmo en IANA no equivale a recomendarlo. Algunos algoritmos obsoletos tienen códigos para poder recodificar certificados existentes. El registro TLS muestra hoy C509 Certificate como valor 4 y Recommended = N. Ese valor no afirma que C509 sea defectuoso; tampoco es una aprobación universal. Nombre, recomendación y permiso local son planos separados.

Menos bytes no significa un resultado medido

Los ejemplos muestran grandes reducciones en ciertos certificados IoT perfilados. Brotli, por su parte, puede comprimir repetición entre certificados de una cadena. En cadenas FN-DSA y ML-DSA dominan claves y firmas casi aleatorias, por lo que ambos métodos ahorran poco. La tabla no prueba ahorro energético, menor latencia o compatibilidad en una red concreta.

Una pasarela heredada puede traducir C509 a X.509 para que el extremo antiguo no cambie. El borrador avisa de que ese modelo necesita certificados sin cifrar y puede perjudicar la protección de identidad. En protocolos que cifran certificados de extremo a extremo, ambos extremos necesitan soporte real. Conversión correcta, parser seguro y confianza continúan siendo tres comprobaciones.

La revisión 21 se publicó el 24 de septiembre de 2026. Está aprobada por el IESG, en la cola del RFC Editor y bloqueada a la espera de los autores. Es un estado editorial, no un RFC, una retirada ni evidencia de despliegue.

Fuentes