Microid mailing list

[Peter Saint-Andre <stpeter AT jabber.org>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature