El borrador de especificaciones para la integridad del sub-recurso es sencillo :
Este documento especifica dicho esquema de validación, extendiendo dos HTML Elementos con un atributo de integridad que contiene un criptográfico. hash de la representación del recurso que el autor espera cargar.
Tal solución es muy estática. Si un proveedor confiable desea cambiar su JavaScript, debe actualizar el hash de integridad y distribuirlo a todos los usuarios posibles. En esencia, el objeto en esa dirección nunca debería cambiar, nunca. Si actualiza su recurso, debe darle una nueva dirección junto con su nuevo hash. (Lo que me hace pensar en IPFS , pero estoy divagando). En el (peor) caso, el desarrollador web inteligente pero ignorante generará dinámicamente el hash de cualquier documento que esté alojado en un momento dado.
Sin embargo, soy escéptico de este enfoque: puedo enviarle un documento firmado con mi clave privada y usted, al tener mi clave pública, puede confiar en el historial de ese documento tanto como confía en que mi clave pública sea mía . ¿No hay forma de aprovechar la firma de claves asimétricas para proporcionar una mejor experiencia para los desarrolladores web sin socavar la seguridad?
Hipotéticamente, ¿cuál sería el impacto en la seguridad si (en lugar de SRI) el siguiente comportamiento se incluyera en los agentes de usuarios web?
Una respuesta del servidor web principal incluiría una lista de claves públicas asignadas a sus sub-recursos. Se espera que esos recursos sean documentos firmados. Si no, o si la firma no coincide con la clave esperada, el agente de usuario tomaría medidas de protección similares a las que propone el borrador de SRI.
En última instancia, estoy tratando de entender cómo proporcionar hashes estáticos de cada documento es mejor que la firma clave en este caso.