La bozza delle specifiche per l'integrità delle risorse secondarie è semplice :
This document specifies such a validation scheme, extending two HTML elements with an integrity attribute that contains a cryptographic hash of the representation of the resource the author expects to load.
Tale soluzione è molto statica. Se un fornitore affidabile vuole modificare il proprio JavaScript, deve aggiornare l'hash di integrità e distribuirlo a tutti i possibili utenti. In sostanza l'oggetto a quell'indirizzo era meglio non cambiare mai, mai. Se aggiorni la tua risorsa, dovresti dargli un nuovo indirizzo insieme al suo nuovo hash. (Il che mi fa pensare a IPFS , ma sto divagando.) Nel (quasi) peggiore dei casi lo sviluppatore intelligente, ma ignorante, genererà dinamicamente il hash da qualunque documento sia ospitato in un dato momento.
Sono scettico su questo approccio, però - Posso mandarti un documento firmato con la mia chiave privata e tu, avendo la mia chiave pubblica, puoi fidarti del pedigree di quel documento tanto quanto ti fidi della mia chiave pubblica per essere mia . Non c'è modo di sfruttare la firma delle chiavi asimmetrica per offrire un'esperienza migliore agli sviluppatori web senza compromettere la sicurezza?
Ipoteticamente, quale sarebbe l'impatto sulla sicurezza se (al posto dell'SRI) il seguente comportamento venisse inserito nei web user agent:
Una risposta del server Web principale includerebbe un elenco di chiavi pubbliche mappate alle sue sottorisorse. Queste risorse dovrebbero essere documenti firmati. In caso contrario, o se la firma non corrisponde alla chiave prevista, l'agente utente adotterebbe misure protettive simili a quelle proposte dalla bozza SRI.
In definitiva sto cercando di capire come fornire gli hash statici di ogni documento sia meglio della firma delle chiavi in questo caso.