using the identity url to contain a key fingerprint
brad at danga.com
Tue May 24 13:42:01 PDT 2005
[ Security people, sanity-check me..... ]
Because the key could change, and it'd be a pain for the people running
the ID server to have to notify all their users to go change their link
But perhaps we could add:
<link rel='openid.pubkey_signedby' value="93:AC:3A:B8:....." />
And fingerprint of the CA that's supposed to have signed your public key?
That way if we do use X.509 certs, and people had them signed (using a
signing key they keep locked up on a separate machine/USB
thumbdrive/CD-ROM) or Thawte or somebody, then they could rotate their
public key as often as they want (or whenever they got hacked), and they'd
never have to have their users update their links tags, assuming the
signing authority's signing key didn't change?
Security people, did I get that anywhere near right?
I'm reluctant to go down the road of full PGP/PKI/SSL, but I'll listen for
awhile and learn and make sure we do something that's at least extensible
later, if needed. In the end I want OpenID to be the pragmatic identity
solution, though, not some academic/tinfoil-hat-wearing answer that nobody
actually every deploys. So keeping that in mind, what should I consider
On Tue, 24 May 2005, Imran Ghory wrote:
> One of the assumptions this protocol makes is that the page at the
> identity url is secure (otherwise someone could change the id server,
> etc.), so if that's the case why not store a fingerprint of the id
> server key alongside the id server identity that would essentially
> remove the problem of key distribution from our protocol ?
> MSN: tickletux at hotmail.com
> AIM: tickletux1
> yadis mailing list
> yadis at lists.danga.com
More information about the yadis