Dominio principal
Seguridad
En la faceta Dominio principal, los análisis de Seguridad se agrupan por dominio principal para que los lectores puedan seguir un área concreta de la infraestructura de Internet, la gobernanza, los mercados de conectividad o el capital digital. La página reúne artículos relacionados, evidencia pública, instituciones, empresas, personas, exposición regional, dependencias operativas y contexto de mercado que de otro modo aparecerían en páginas de categoría separadas. Explica el dominio, la clase probable de actor, el contexto de mercado o de gobernanza y el material de origen que los lectores deben usar al comparar señales. Operadores, analistas y lectores de gobernanza pueden ver cómo el mismo dominio aparece en eventos, perfiles, cambios de mercado, evidencia de fuentes públicas, dependencias regionales y decisiones de infraestructura de ciclos más largos a lo largo del tiempo.
IETF
Rich Salz y el requisito de TLS 1.3 que no era un comprobante de despliegue
Una norma puede fijar una regla exigente sin fabricar la prueba de que esa regla ya se cumple en cada sistema que está funcionando. La distinción no debilita la norma: evita que una decisión de protocolo se convierta en una afirmación de despliegue sin observación. El RFC 9852…
IETF
Nancy Cam-Winget y el evento SCIM que no era un recibo de conciliación
Que un dominio de identidad comunique un cambio no demuestra que el dominio receptor ya lo haya incorporado. Aún debe identificar el recurso, conciliar esquemas, decidir si necesita una consulta de vuelta, aplicar su regla local y observar su propio estado. El RFC 9967, coescrito…
IETF
Chris Wendt y la respuesta firmada que no autenticaba el audio
El hecho de que una llamada llegue a una respuesta no resuelve por sí mismo una cuestión de identidad. Aún quedan por determinar el destino real, la autoridad de quien lo afirma, el nivel de riesgo que el llamante aceptó y el origen del medio que sigue a la señalización. RFC…
IETF
Michael Prorock y el identificador de algoritmo que no escogía una política de confianza
Una etiqueta criptográfica puede ordenar una verificación entre sistemas distintos. No puede explicar de dónde procede una clave, por qué merece confianza, qué afirmaciones son pertinentes ni qué medida debe tomar quien verifica. RFC 9964, firmado por Michael Prorock y Orie…
Expediente
El token llegó antes que la llamada. La verificación tuvo que esperar: RFC 9888
El servicio de destino ya guardaba una afirmación firmada cuando la llamada aún no había aparecido. RFC 9888 permite que STIR sobreviva a rutas donde SIP no cruza de extremo a extremo. La utilidad nace de separar los caminos; la obligación operativa consiste en no fingir que esa…
IETF
Dan Harkins y la clave de arranque que no podía acreditar su propia custodia
Que un dispositivo demuestre controlar una clave privada no explica quién entregó su clave pública al servidor, si esa entrega fue íntegra ni quién autorizó el acceso posterior. RFC 9966 deja esa frontera a la vista: convierte una clave de arranque en una prueba TLS acotada, no…
Expediente
La solicitud estaba firmada. La otra clave privada seguía siendo una afirmación: RFC 9883
Una firma válida puede demostrar quién formuló una declaración sin demostrar que la declaración sea cierta. RFC 9883 convierte esa diferencia en un mecanismo de emisión: una clave firma; la posesión de otra clave se afirma. La autoridad certificadora debe hacerse responsable del…
Expediente
RFC 9882 obligó a escribir SHA-512, no a usarlo siempre
Un campo rellenado conforme a la norma puede no describir la operación criptográfica ejecutada. RFC 9882 convierte esa posibilidad en una regla explícita: en una ruta de CMS el firmante declara SHA-512 para facilitar la interoperabilidad y el verificador debe ignorar la…
Expediente
RFC 9879 modernizó el MAC, pero no jubiló al lector heredado
Una hoja de migración puede decir «compatible» porque el archivo se abrió. Esa palabra no cuenta si el lector verificó la integridad, ignoró un fallo que no entendía o simplemente llegó a una clave cifrada. RFC 9879 mejora el mecanismo de PKCS #12 sin convertir esas tres rutas en…
Expediente
El paquete traía dos formas, pero aún no una sola clave: RFC 9935
Una clave privada ML-KEM puede viajar como semilla, como clave de desencapsulado expandida o con ambas representaciones. Que el contenedor acepte las dos no demuestra que correspondan: esa relación nace sólo cuando el receptor vuelve a derivar y compara.
Expediente
El OID nombró el paquete de claves. No autorizó su uso: RFC 9939
El inventario mostró una etiqueta CMS reconocida y una estructura PKCS #8 que el lector pudo analizar. Esa evidencia nombra un objeto. No demuestra que alguien controle la clave privada ni que su siguiente uso esté permitido.
Expediente
El recurso nombró a su servidor de autorización. No concedió un derecho: el límite de descubrimiento de RFC 9728
Un recurso puede indicar correctamente dónde debe mirar un cliente y aun así no haber autorizado nada. RFC 9728 ordena ese descubrimiento de OAuth. Sus metadatos son una señal de coordinación: no son un token, ni una aceptación del servidor de recursos, ni una prueba de que una…
Expediente
La conversación de autorización seguía pendiente. No era un derecho de API: el límite de continuación de GNAP
Un cliente puede estar facultado para continuar una conversación de autorización sin estar facultado para invocar la API solicitada. RFC 9635 separa ambos hechos: la credencial de continuación mueve una solicitud ante el servidor de autorización; el derecho sobre un recurso, si…
IETF
Sean Turner y la prueba de clave privada que no autorizó el certificado
Entre la clave pública que aparece en una solicitud y el certificado que finalmente emite una autoridad hay una serie de decisiones. Verificar la firma demuestra control de una clave; no concede el nombre, los usos ni la confianza que figurarán en el resultado.
IETF
Panos Kampanakis y la sesión SSH con tres comprobantes de seguridad
Una sesión SFTP puede terminar con el mensaje «conectado» después de negociar ML-KEM, pero ese resultado no dice por sí solo qué servidor fue aceptado ni qué usuario recibió permiso. SSH resuelve esas preguntas en capas distintas, y una migración rigurosa debe conservarlas así.
IETF
Bas Westerbaan y el TLS híbrido que no convirtió el certificado en poscuántico
Una captura de paquetes puede mostrar dos datos a la vez: `X25519MLKEM768` en el acuerdo de claves y una firma clásica en la autenticación del servidor. El primer dato no invalida al segundo; simplemente protege otra parte del protocolo. El error aparece cuando una etiqueta…
IETF
Daniel Fett: la MFA autenticó al usuario, no el contexto del QR
El atacante no necesita robar el segundo factor cuando puede conseguir que la víctima lo use correctamente. En un flujo entre dispositivos, una autenticación impecable puede terminar entregando la capacidad al equipo equivocado.
Expediente
El certificado verificó al par. La PSK externa seguía necesitando un custodio: RFC 9973 y la autoridad en TLS
Un tablero de operaciones puede mostrar cinco casillas verdes: certificado válido, identidad PSK seleccionada, binder correcto, Finished recibido y canal cifrado. Es una buena noticia para el transporte. No resuelve quién decidió que ese secreto podía vivir en el dispositivo, en…
Expediente
La cookie llegó con la solicitud. No había decidido por nadie: RFC 10025 y la autoridad ambiental
Un cambio delicado puede entrar por una ruta legítima, con TLS, una cookie de sesión reconocida y una respuesta HTTP correcta. Esa combinación no prueba que la persona adecuada quiso el cambio, que la sesión seguía habilitada para hacerlo, que la regla de negocio lo autorizó ni…
Expediente
El cifrado llegó a la clave. No nombró a quien lo envió: RFC 9180 y la autoridad que falta en el modo Base de HPKE
Una aplicación puede descifrar un mensaje HPKE sin error y aun así no tener base para atribuirlo a una persona, una empresa o una instrucción vigente. RFC 9180 protege una transición criptográfica concreta; el nombre del emisor, la vigencia y la autorización de actuar siguen…