The problem with OpenID (TAKE 2)

Mon May 17 17:19:44 UTC 2010

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 fred at example.com 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
<sysadmin at shadowsinthegarden.com> 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>

-- 
Website: http://hallambaker.com/