Microid mailing list

["Eran Sandler" <eran AT yedda.com>]

Regarding the hashing algorithm, even if we use HMAC and SHA256 we will
still have the same problem of just using SHA256 but with the additional
secret key, but it will still be, potentially, be broken if someone would be
able to prove that SHA256 suffers from the same problems as SHA1.

Specifying the algorithm used will help us, if necessary, to move to a
different algorithm in a newer version of the microid spec, while still
retaining backwards compatibility.

If I were to base things on what Yaniv have suggested (his revised version),
having an identifier which is a string specifying what is the type of item
encoded should suffice.

For example, this will tell us that this is a combination of an email and
the resource URI (in this case a URL):
<meta name="microid"
content="email+url:sha256:e5de55ef248b5f8b06d38253cac0ae725d6455fb">

This will tell us that this is a combination of an openid (instead of Email)
and a resource URI (in this case a URL):
<meta name="microid"
content="openid+url:sha256:e5de55ef248b5f8b06d38253cac0ae725d6455fb">


This way we have all the necessary meta data to make a programmatic decision
and identify which path to go, while still retaining the ability to be
backwards compatible if we were in need of changing the hashing algorithm.

Eran


-----Original Message-----
From: Peter Saint-Andre [mailto:stpeter AT jabber.org] 
Sent: Wednesday, December 06, 2006 6:13 PM
To: eran AT yedda.com
Cc: microid AT lists.ibiblio.org
Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization

Eran Sandler wrote:
> HMAC needs an underlying hashing function such as SHA256 or (the already
> problematic) MD5 and SHA1.
> It has the additional value of a secret key but it is still as strong as
the
> underlying hashing function.

Sure. In Jabber we recently specified the use of hmac-sha256.

> As far as I understand HMAC, the key is needed in both places, the place
the
> generates the hash and the place that creates it to verify it.
> This means it will raise problems in distributing this key in a secure
> manner and will make it harder for implementers of microid and validation
> implementers.

Er, yes. In our Jabber use case, the key is something shared within a
particular trust domain.

> I think that by using just a hashing algorithm it should be fine and make
> the code a lot easier to write for implementers.
> The one thing we do need to give thought to is being able to replace the
> hashing algorithm when (or if) it is not considered safe for usage anymore
> (like SHA1 and MD5).

Yep. We could do SHA256 to start but eventually even that may be found
insecure.

> For that we will need the ability to describe the hashing function used,
> just like Yaniv previously suggested, i.e.:
> 
> <meta name="microid"
>        content="sha256:openid:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/>
> 
> or, more correctly presented (after discussing it with Yaniv :-) ):
> 
> <meta name="microid"
>        content="openid:sha256:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/>
> 
> So that the data being hashing will be first, and then we will have the
> hashing algorithm.

That's fine by me. But we do need to think about the data definitions.
I'm thinking especially of OpenID. For example, how do we clearly
differentiate between a regular old HTTP URL and an OpenID URL (the
latter is simply an instance of the former, but how to we know that
programmatically)?

Peter