[foaf-protocols] how would foaf protocols cooperate with a national id world that was ISP mediated?

peter williams home_pw at msn.com
Wed Mar 9 17:09:57 CET 2011


Millions of people's browsers already use their ISP's proxy server; it comes
built into DHCP and proxy config. How might one leverage this, in a foaf
protocol?

 

If the ISP proxy itself has an https server cert from an EV CA (say), and
that CA sets the proxy server's cert-minting bit and the basicConstraints
ca-pathlen to x+1, this authorizes the proxy to spoof resource sites -
without browsers noting anything amiss. Spoof is the wrong word. Assume that
"education" is used to characterize this as "ISP-mediated identity", or some
such termin. The x+1 limit means the ISP cannot grant further CA privileges
to other proxies.

 

There are strong hints in the US national id plan that ISPs are intended to
play a major role in the national trust infrastructure. Let's imagine what
it might look like, and project it onto the semantic web and the use of foaf
cards.

 

Let's say that the ISPs must use BGP signing (to be classified as an
"authorized, _regulated_ ISP"), and lets now assume the plan would require
them to publish the home user's modem's temporary IP lease in DNS (which
they already do), but now the entry is signed with dynamic DNSsec. (Signing
1000 RRs a second  is really not that much of a burden these days; being a
$1000 HSM).

 

Let's say the ISP populates that RR with a persistent public key for the
subscriber account (using the likes of an inherited X.500 subentry), keeping
the persistent private key of said user in the proxy HSM array - capable of
holding 10 million signing keys, and capable of doing lots of SSL handshakes
and SAs in parallel. (This "class" of "telco grade" equipment _was_ on show,
at RSA Conference, note, delivering 40Gbps today -  with folks expecting
100Gbps within the year, using EC+AES ciphersuites). 

 

Should the ISP's http/https proxy exploit its server cert (now armed with
the cert minting key usage remember), it can now respond to https events
from the browser "acting as" the named resource server site, doing the usual
SSL MITM bridging and dynamically re-signing the content server's real
server cert. 

 

The proxy can, furthermore, now bridge https to that server upstream using
an EC-DSA signature for client authn (using the user's stored private key)
presenting to the resource server the subscriber's dynamic IP address (as
normal), which of course has an DNSsec entry in support now - that the
resource server can locate using the usual DNS-reverse lookup - to do a
SAN_DNS style cert pingback. The scheme doesn't need webid assumption (doc
=> user has write acls) as the RR has signed zone support, providing a
DNSSec chain to the root key for the TLD.

 

 

Ok. To do this, what are folks waiting on? Surely, it's really only the
capabilities of the SSL accelerator units capable of doing this, for a
relatively large number of full handshakes, and lots of stored crypto keys.

 

This is the kind of thing I'd do, if I were trying to create a
per-subscriber, targeted intercept point for CALEA that (i) has the
cleartext it needs, AND (ii) also creates a reasonably trustworthy client id
for use in the delivery of e-gov services etc. But, to make it viable, it
has to be bigger than e-gov consumer sites.

 

So next, I'd probably coopt the 5-10 biggest IDPs as be willing and able
recipients of the above, expecting them to do what they do today -  which is
upon user authentication turn around and issue saml/openid/.. assertions -
to the myriad of smaller RP sites that they federate with.

 

At that point one, essentially one has a national 4 corner validation
network. (1) Browser, (2) RP sites, and the two intermediaries that gate
access to each of their last miles: (3) ISP (gating access to subscriber
last mile - the broadband circuit), and (4) IDP (gating user access to
"governed networks" of small RESTful RPs working on HMAC'ed tokens like SWT,
delivered over clientless https. I'd make the RP sites subject to the IDP's
projected privacy policy, concerning their profile re-use, storing and
forwarding, etc, making the IDPs traffic cops, essentially)

 

So finally, we see where a foaf protocol might fit in - enforcing that
limited use regime on the foaf card attributes. It would have to compete
however with the IDP-issued asserted-token that just project's user
attributes to RP sites, where, like openid AX, the protocol has a session
manager built in.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110309/80bda960/attachment.htm 


More information about the foaf-protocols mailing list