As I mentioned previously, the need to refer to a static data object by means of a digest comes up frequently. Rather than re-invent the mechanism for creating a reference each time we need one, it would be better if we had a single format that could be re-used.
We used to have this back in the days when we trusted MD5 since we used that everywhere as a 'fingerprint'. Then things got muddy after the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it will be very muddy. This would be relevant to the cert pinning debate. I wrote a draft making the proposal: http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt On the digest front the objective would be to make it possible to use the URI format with any digest at all in theory but strongly encourage people to only use the digests IETF is confident in. Use of OIDs as the identifier has the nice property that anyone can get an identifier to distinguish their algorithm from other people's but getting an OID does not produce any paper trail that can be used to imply an IETF endorsement. We could add in support for the text based identifiers as well, but since the only identifiers that I would want to encourage are SHA2 and SHA3, I don't see a need. For all applications that make sense it is going to be perfectly OK to simply generate the prefix for the identifier part as a static array of octets and append / verify it as such whenever it is needed. I do not see any need to write ASN.1 handling code for these apps :-) The basic idea here is that we need to allow for algorithm agility and to prevent a content substitution attack. So imagine that we have web page A linking to some off site static content via a digest. Site A regards the static content as a PNG and has checked out the page and it works fine. What they don't know is that buried in the PNG there is some malicious Jscript and if the content server delivers it as application/script the result will be a series of syntax errors (that are silently ignored because the app is stupid) and then it finds the malicious code... ooops. OK, so maybe not an attack that you find to be a worry in every circumstance, but it is definitely an attack vector we should address in a general purpose crypto building block. Having produced a static building block like this it is very easy to generate a fingerprint for a static data object in a cut and paste ready format. I don't need a separate tool to generate digest identifiers for WebSec vs other applications. In terms of ease of use we get back to what things were like when we used MD5 fingerprints. It is also quite easy to make use of truncated fingerprints should that be necessary. For example, to put on a business card. -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
