Resumen

  • El RFC 10031 crea id-on-MACAddress para guardar EUI-48 y EUI-64 como valores exactos de seis u ocho octetos, y define máscaras para restringir esos nombres a lo largo de una ruta de certificación.
  • La validez del certificado confirma la vinculación que hizo la CA según su proceso. No prueba que la dirección sea inmutable, exclusiva o global, que el interfaz esté presente ni que el sujeto tenga permiso para actuar.

Seis octetos sin biografía

La nueva forma otherName evita la ambigüedad de las representaciones visibles. El certificado no guarda guiones, dos puntos ni puntos: guarda seis octetos para EUI-48 u ocho para EUI-64, en orden de mayor a menor significancia. El identificador de objeto es 1.3.6.1.5.5.7.8.12.

La parte que confía compara los bytes de manera exacta. No hay comodines. Una dirección no significa “cualquier tarjeta de este fabricante”, “todos los puertos de este chasis” o “la dirección que use hoy el sistema”. La precisión es una virtud porque obliga a nombrar el objeto pequeño que realmente se certificó.

El RFC exige a la autoridad de certificación comprobar que la dirección pertenece, o se espera que pertenezca, al dispositivo sujeto durante la vida del certificado. También prohíbe usarla en certificados de dispositivos distintos, salvo que compartan la misma interfaz de capa 2.

Ese deber no convierte a la CA en observadora permanente del activo. Una tarjeta puede cambiarse, una dirección puede reasignarse y un puerto puede quedar fuera de servicio mientras la firma y las fechas del certificado siguen siendo válidas. La continuidad operativa necesita un enlace con el inventario y un disparador de revocación o reemisión.

La clave y la trama responden preguntas diferentes

La seguridad del RFC parte de una advertencia: la vinculación es tan sólida como el proceso de validación de la CA, que debe considerar la suplantación de direcciones MAC. Las direcciones compartidas y dinámicas dañan la unicidad y la responsabilidad. Tampoco debe suponerse unicidad más allá de la red local sin información que demuestre estabilidad entre fronteras.

Una prueba de posesión de clave dice que el interlocutor controla la clave privada del certificado. La captura del enlace dice qué dirección fuente apareció en una trama, un puerto o una asociación. La primera no demuestra que la interfaz nombrada transportó ese paquete. La segunda no demuestra que quien emitió la trama posea la clave ni el mandato del activo.

Por eso un certificado autofirmado no cierra el circuito. El RFC exige que incluya la dirección de un puerto físico, pero la autofirma no proporciona por sí misma un ancla confiable ni concede una función dentro de la aplicación.

La privacidad rompe la permanencia a propósito

Apple documenta direcciones Wi-Fi privadas distintas por red y modos apagado, fijo y rotativo. Android habilita por defecto la aleatorización en modo cliente desde Android 10, usa una dirección local unicast y describe persistencia por SSID. Estos sistemas producen variación deliberada para impedir que observadores construyan un historial de actividad y ubicación.

El RFC 10031 reconoce el mismo riesgo. Una dirección fija incrustada en un certificado facilita el seguimiento prolongado del equipo y de su usuario. Por eso propone considerar rotación, certificados de vida corta o aleatorización cuando sea viable.

Certificar la dirección de fábrica conserva una referencia al interfaz físico, pero puede no coincidir con la dirección que se ve en la red. Certificar una dirección privada puede alinearse con el enlace actual, pero dependerá del SSID, del estado del sistema y de la política de rotación. No existe una elección universal. La política debe declarar qué continuidad compra y cuándo termina.

Una restricción de nombres limita emisiones

Para Name Constraints, el RFC combina un patrón de valor con una máscara de bits. Cada mitad mide lo mismo que la dirección; el total es de doce octetos para EUI-48 o dieciséis para EUI-64. Los bits no cubiertos por la máscara no pueden afirmarse en el valor.

Las restricciones permitidas se intersectan al bajar por la cadena. Las excluidas se acumulan. Una CA subordinada puede quedar limitada a una franja parecida a un OUI o a direcciones universales unicast. Es control real sobre el espacio de nombres que puede emitir.

No es control sobre una máquina. Que el camino acepte el nombre no permite conectar el equipo a producción, operar una máquina, cambiar una ruta o firmar una versión. Esa decisión pertenece a la política que conoce el activo, la postura, el rol y el daño posible.

Tampoco basta el prefijo. El propio RFC advierte que los bits universal/unicast no prueban el registro de un OUI. IEEE distingue OUI, CID, EUI concebidos como globales e identificadores locales cuya unicidad depende del administrador. La asignación dice quién administra un bloque; no certifica fabricante actual, dueño, cadena de custodia ni derecho de uso.

No comprimir el desacuerdo

La evidencia útil conserva por separado la huella y el camino del certificado, la política y revocación, la posesión de clave, la dirección del SAN, la decisión de restricciones, la dirección observada, el puerto o asociación, el objeto de inventario, la postura, el inquilino, el rol y la acción solicitada.

Cada elemento cambia con su propio reloj. La dirección privada rota; la tarjeta se sustituye; el certificado caduca; el activo cambia de responsable; la postura envejece; la autorización se revisa. Cuando divergen, el sistema ha encontrado una decisión que necesita dueño. Convertirlos en un “ID de dispositivo” oculta precisamente la información que importa.

El RFC 10031 acierta al ser pequeño. Añade el nombre y las reglas de interoperabilidad que faltaban para casos de capa 2. No crea un pasaporte universal de hardware. La adopción puede ser voluntaria y local, y el código en funcionamiento debe demostrar que soporta reemplazos, múltiples interfaces, privacidad y reversión antes de ampliar el alcance.

Fuentes