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

Henry Story henry.story at bblfish.net
Wed Mar 9 17:26:52 CET 2011


Why don't we create a web service to test the services that do this proxying. How would it work? Imagine we have a freedom box at our disposal.

Henry


On 9 Mar 2011, at 17:09, peter williams wrote:

> 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.
>  
>  
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect
http://bblfish.net/

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


More information about the foaf-protocols mailing list