[OpenID] signing 1 XRD for a million OpenIDs (was host-meta and "acct:")

[Manger, James H]

John,



> I can then sign exactly one document (the "template" XRD), and

> point to it from all of my 1M resources.

> I mark it as cacheable for 1 week and it is used for billions of metadata lookups

> without any HTTP overhead.  Life is good.



Sounds good, but… something is missing.



Signing the “template XRD” doesn’t secure the link from the user’s OpenID identifier to the XRD.

The signed template XRD securely tells an RP which OP the signer says is authoritative for the user’s OpenID identifier.

This is not the same as the OpenID identifier itself securely saying which OP is authoritative.





To get the HTTP cache goodness the template XRD probably needs to be delivered over HTTP, not HTTPS.

Consequently, the 1M user account OpenID URIs need to return, say:

  Link: <http://example.com/template.xrd>; rel=”describedby”

If an attacker tampers with the RP’s subsequent unsecured HTTP request for template.xrd, and returns different meta-data — how can the RP tell it isn’t legitimate?



The 1M user account OpenID URIs have not indicated that:

1)  the XRD needs to be signed; or

2) which signer(s) are legitimate.



We either need to:

* change the theory behind OpenID so one resource (eg template XRD) can say “I’m authoritative for all, say, http://example.com/user/* OpenID identifiers — so RPs don’t have to contact those URI (eg they will never delegate)”; or

* define a new type of link (eg httpi://…) which means “use http, but check the integrity” (it could mean “use http and only accept a signed response, or use https — the client can choose”).









James Manger
James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>
Identity and security team — Chief Technology Office — Telstra



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091106/54532e30/attachment-0001.htm>