On Wed, Sep 28, 2011 at 5:32 AM, Gervase Markham <[email protected]> wrote: > 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.
It is a message digest, how readable would you like it to be? We can easily put some of the packing in ascii: DIGEST:SHA-256:text/plain:eiwoeiwoiejfoiwejfiojefiojweoifj== You are still going to end up with an unreadable blob at some point. > Why does it take so many bytes to determine between a very small number > of options? Because of the vanity crypto problem. > 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 We have an IANA registry already. >> 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? Because the crypto APIs use ASN.1 as the identifier that they key off. So if you introduce a text based identifier they have to track two different registries. > Counter-proposal: how about: > > digest:SHA1,<base64 string of digest> It still needs to at least have an option for specifying the content type, this could be made optional though. -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
