On 27/09/11 18:10, Phillip Hallam-Baker wrote: > 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.
But it also makes the identifiers less human readable and much longer than they could otherwise be. > 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. Why does it take so many bytes to determine between a very small number of options? Worrying about clashes in the text-based identifiers people use seems somewhat unnecessary. How many hash algorithms with the same name (or without an obvious canonical name) are there? If this was really a problem, we could have a microformats-like wiki registry: http://microformats.org/wiki/existing-rel-values > 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 :-) Then why use ASN.1 at all? Counter-proposal: how about: digest:SHA1,<base64 string of digest> Like a data: URL, except without the option for ASCII/URL encoding: http://en.wikipedia.org/wiki/Data_URI_scheme For bonus points, allow multiple comma-separated digests to ease algorithm migration. Simple :-) Gerv _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
