<no hats> I agree with the motivation but not the design. A while ago I posted my idea for a design for this. [1] It may become a work item for the DECADE WG, ... or not, we'll see.
S. [1] http://tools.ietf.org/html/draft-farrell-ni-00 > 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 > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
