Essentially, proposal to allow the signer to assign a resource uuid to the content they are hosting, and allow the embedder to specify this uuid. i.e. I want this file (location), with this uuid, signature verifiable by public-key.
In this case the uuid becomes the what to our resource request so that the resource path, (or even hosting server) is free to change (e.g. between development/production environments). If different development/production versions of a resource are required (i.e. the development one has less restrictions for example) then these should have different uuids because they are fundamentally different resources, and the requester should dynamically change the uuid to correspond to the resource that they expect for the situation (as well as the resource location if necessary. (This could perhaps also be done with some resource versioning extension).
The signer of the resource makes the statement "this is a valid version of the resource that I have assigned the unique identifier uuid, here is the signature proving so".
I think this addresses the content substitution attacks (to the extent described in #5), without locking the signature to a specific URL/path.
E.g. (stealing the example from #5)
needsAuth.js has resource identifier abcdef, say
function needsAuth() { return true; }
and
noAuth.js has resource identifier hijklm, say
function needsAuth() { return false; }
Then, one might use something like
<script src="https://my.cdn.com/needsAuth.js" integrity="uuid-abcdef, ed25519-[base64-encoded public key]" crossorigin="anonymous">
or maybe even
<script src="https://my.cdn.com/needsAuth.js" integrity="resource-identifier-abcdef, ed25519-[base64-encoded public key]" crossorigin="anonymous">
When my.cdn.com wishes to update the resource they would use the same uuid (since the intent here is to identify the resource, not necessarily the content byte-for-byte).
my.cdn.com should ensure that they create unique identifiers for each resource.
One should ensure that this identifier is part of the signed body, so perhaps inclusion in a header would be fine provided that the headers (or a subset of them) are signed, which is probably a reasonable goal anyway.
An extension to this may be to allow resource versioning as part of the signature, so that the user of the resource could specify a minimum version to use (i.e. a go at tackling rollbacks to old vulnerable versions). Though this of course places a burden on the resource user to update the version number periodically, and also doesn't address roll-forwards to vulnerable versions (from the perspective of a resource user). Say if the resource user specified 13.5.0^, the latest is 13.5.5, but a vulnerable version 13.5.4 was released and then patched (even if 13.5.0 doesn't contain that vulnerability, the an attacker could give the resource user the "newer" vulnerable version).
Essentially, proposal to allow the signer to assign a resource uuid to the content they are hosting, and allow the embedder to specify this uuid. i.e. I want this file (location), with this uuid, signature verifiable by public-key.
In this case the uuid becomes the what to our resource request so that the resource path, (or even hosting server) is free to change (e.g. between development/production environments). If different development/production versions of a resource are required (i.e. the development one has less restrictions for example) then these should have different uuids because they are fundamentally different resources, and the requester should dynamically change the uuid to correspond to the resource that they expect for the situation (as well as the resource location if necessary. (This could perhaps also be done with some resource versioning extension).
The signer of the resource makes the statement "this is a valid version of the resource that I have assigned the unique identifier uuid, here is the signature proving so".
I think this addresses the content substitution attacks (to the extent described in #5), without locking the signature to a specific URL/path.
E.g. (stealing the example from #5)
needsAuth.jshas resource identifierabcdef, sayand
noAuth.jshas resource identifierhijklm, sayThen, one might use something like
or maybe even
When
my.cdn.comwishes to update the resource they would use the same uuid (since the intent here is to identify the resource, not necessarily the content byte-for-byte).my.cdn.comshould ensure that they create unique identifiers for each resource.One should ensure that this identifier is part of the signed body, so perhaps inclusion in a header would be fine provided that the headers (or a subset of them) are signed, which is probably a reasonable goal anyway.
An extension to this may be to allow resource versioning as part of the signature, so that the user of the resource could specify a minimum version to use (i.e. a go at tackling rollbacks to old vulnerable versions). Though this of course places a burden on the resource user to update the version number periodically, and also doesn't address roll-forwards to vulnerable versions (from the perspective of a resource user). Say if the resource user specified
13.5.0^, the latest is13.5.5, but a vulnerable version13.5.4was released and then patched (even if13.5.0doesn't contain that vulnerability, the an attacker could give the resource user the "newer" vulnerable version).