I m unable to parse this statement. As with many other aspects of OpenID it appears that supposition substitutes for fact. Oh lets casually mention some difficult problems / controversial solutions and hope that those discourage argument. I am sorry, but for me, merely invoking the Trusted Computing Group is not an argument. And as for TTPs controlling any crypto, no TTP in their right mind would ever let themselves control crypto for someone else.
There are two things that a digital Certificate can tell the relying party: * That the connection to the end point is trustworthy * That the end point is trustworthy. You need a trusted third party only in the second case. And then you are going to have a lot of real world problems and accept that 'trustworthy' may be context dependent. For the purposes of OpenID there are two points at which we might use PKI as an authentication technology, if we have [email protected] we can assign a public key to Fred or we can assign the key to the domain example.com. The second one is actually quite straightforward. Please forget for a moment that such a thing as DNSSEC might exist. If DNSSEC is deployed it is possible to do some improvements, but even without DNSSEC it is possible to have a fairly robust scheme that could be used by any Web Service. The domain example.com creates a self-signed cert, for convenience later on, it includes the DNSHASH extension, but this is not essential. The domain then creates a CERTHASH record (needs to be defined) example.com CERTHASH SHA256 29j29sj39jf3922i9e== This alone gives us almost the same degree of assurance as the lowest grade SSL certs in use today in a format that is 100% backwards compatible. When a client attempts to connect to the Web service with SSL it is presented with the SSL certificate, sees that there is a DNSHASH extension and that it can thus verify the applicability of the cert to the service endpoint. One side effect of this approach is that it is no longer necessary to put the DNS name of the site in the cert and so the problem of requiring separate IP addresses for each domain name goes away. This approach is of course vulnerable to DNS spoofing attack. But we can guard against this by introducing a TTP, albeit one that is considerably narrower in scope than SSL CAs are. We introduce a second DNS record, the TRUST record which contains a SHA256 digest and URI for the trust statement of the site. This specified the hash of the offline master root used for generating server level SSL certificates and a list of third party accreditations available. The third party accreditations may be very high grade accreditations designed to establish the accountability of the TTP. Or they may be simply notarization statements to the effect that the site trust statement has been consistent with the current value for the past 4 years. On Mon, May 17, 2010 at 11:19 AM, SitG Admin <[email protected]> wrote: >> The reason i am saying this is because we seem to have got ourselves stuck >> up on the idea that "Only symmetric keys will work". In spite of the fact >> that I am more or less in tune with this idea, have we "investigated the >> fact that asymmetric keys might be the solution to the Identity problem?". > > Nice spin there: investigated the "fact"? > > Controlled by users, doable. Are users ready for that yet? Apparently not, > though you might try asking the folks over at Diaspora. > >> I know this will ruffle some feathers around here, but don't you think we >> need to give it a serious consideration for OpenID. > > Out of scope for now: asymmetric crypto controlled by 3rd parties (worse > than escrow: in OpenID as currently stands, we'd be looking at the > equivalent of Trusted Computing) isn't user-centric identity. If you really > want your identity to *belong* to some 3rd party, consider how difficult it > would be to migrate to a new key based on a *shared* secret. > > -Shade > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- Website: http://hallambaker.com/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
