Re: Signature Link Relation for Cryptographic Resource Verification

There are several issues here:

* SHA-1 is no longer secure. "In 2005, cryptanalysts found attacks on
SHA-1 suggesting that the algorithm might not be secure enough for
ongoing use. NIST required many applications in federal agencies to
move to SHA-2 after 2010 because of the weakness." (Wikipedia, SHA-1)
* The values of link relations must be links, not arbitrary data. You
would have to use a hash URI scheme of some kind, and of course to do
so would be a trivial change.
* Hashes for the integrity of content are already being investigated
by the Subresource Integrity group. http://www.w3.org/TR/SRI/

Since the work of the SRI team is so similar to that suggested by my
Internet-Draft, I am starting to discuss the use case with them. Some
further information can be found here:

https://github.com/w3c/webappsec/issues/449#issuecomment-163279813

And there has been discussion on the WebAppSec mailing list.

On Wed, Dec 9, 2015 at 11:29 AM, Safwat <softwatt@gmx.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 12/08/2015 05:42 PM, Sean B. Palmer wrote:
>> https://www.ietf.org/id/draft-palmer-signature-link-relation-00.txt
>>
>>
> This draft has great potential if expanded.
> I propose three additions. The rationale for each of them is explained
> in the next section.
>
> 1 - Why limit this to PGP? Simple hashes like SHA1 should also be
> possible.
>
> 2 - Inlining a checksum should be possible.
> <a href="/download/example.tar.gz"
> rels="signature-sha1 f572d396fae9206628714fb2ce00f72e94f2258f">
> Click here to download</a>
>
> 3 - This should also work for <img> tags.
> <img src="/static/hello.png"
> rels="signature-sha1 f572d396fae9206628714fb2ce00f72e94f2258f">
> Click here to download</a>
>
>
> Rationale:
>
> 1 - SHA1 is shorter. Allowing compact inlining. This makes "2" feasible.
>
> 2 - Inlining means less page requests, this would allow signatures to
> be used on multiple <img> tags without performance degradation. This
> makes "3" feasible for websites with many images.
>
> 3, a - Websites often have images which are fetched from external
> websites. Currently, these images are not verified at all, and the
> external server can modify them at will. Adding this mechanism
> resolves this.
>
> 3, b - Currently, https-encrypted sites which use external CDNs for
> images must employ some certificate witchcraft. With this change,
> https sites can safely link to images hosted in unencrypted servers.
> Those images will be verified by the checksum. Of course, this
> shouldn't be done for an image whose URL is supposed to be secret.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWaBCKAAoJENivoBfRYOGKW40QAJPOuMefsYLjOg3B7Wep3zWN
> yxkh3K2OJgKiuKzljpQPJGmo7LsAjYCxV2MMjcGAI5NpoDNN+mhmI0M8WZPkFAqB
> DhAGa1iaT4Zbz4zyCXPUtpmIhStf4gcv090ij+iJAceH3to9Ac6M4fz60pVEv+iR
> /d0NgVPQKBRY4tsO5yKXKlz8BrUsg9YY/heENC41+M9UXW7rL3EtLlMMiKvT0XZw
> YCbRGF2FmtQFA5DisL/2/k1qX1wAeRBXNG5hRkEGCFYj0Xm1uGziNsshj0jE19b+
> 1UTS8dM9HM0jl7IlfYjwrvO8rBArmW1PdQWYZFOA201qoplWvy7Wl2HZyqy1Wxrn
> gJTToFoId4aKUNNyM2zkPLBHgYzQOyIQuN31bWzTwNeXuyY2ffeYSHVvu36pJVvP
> rVGRoRDOvLXK6hpbcAMp0mhtbNf3ZPLX9sTFY9tPy3thIQW2M4SZNAld4H30Feab
> PuxgKtH888LJxbthYXhxfvcQMP+3DxU9H8auFB7FDfaIdZVMlTo4On4IMfcJJzby
> V8sncw8bQkcxmp4jgRBbq9jbJMVyDX8RsXA/tQFvBs5s2qmK8Gm4NrvtLgA2kQ/G
> fRsrXIxKw/YAsbCjEZ++GJhNdyDYZv+ieDqZBBqmBISJqitPT9DdwJIzucaNzCeC
> m2aNv4vdaKpVh4e1q0O/
> =624t
> -----END PGP SIGNATURE-----



-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Wednesday, 9 December 2015 15:11:27 UTC