[foaf-protocols] virtual hosting in modern browsers

Sun Jan 30 19:55:02 CET 2011

Lets go though certs 201 - touching on authentication, statement making, name handoffs, and then trust (with certs and kerberos). Why? becuase a billion PCs are using it every day.... This is not academic, or research. This is reality. The research phase happened 30 years ago.

The logic of authentication (with full power formal semantics) has been studied for about 30+ years. Some of the main intellectual contributors in W3C are infamous for developing it. There are various elements in the language, such as statements, channels, and speaks-for. It was developed as a study of what formal methods might bring to the table in analysis, and formal methods as a design method in its own right. It was part of NSA program to define trusted systems, in an era which assumed that users of the system are trying to subvert its security. 

Certificates are a part of that world - applied to the web in 1993/4/5. So was kerberos (and its US military equivalent from the late 80s: KMP).  In general certs and kerberos are links in a handoff logic, in which statements made by one are referenced by another to form a link chain. The references chain together, so there is a chain between "trust-points" in a shared name space (see below). Many folks mis-understand this. They either impose intuitive notions of trust from the schoolyard, or they impose a DNS-like zone hierarchy interpretation, and talk about big brother CAs. Folks worried abotu the latter have some legitimacy, as FBI spent $50M lobbying for that just that, in 1997-2000. Several of leading in IETF TLS WG were part of the escrowed encryption initiative (the plan to limit your crypto - including UK crypto - to devices that FBI could control).

The "foaf-agent" that "issues" a certificate is making a statement. Its a statement "about" a "subject" who has claimed a name, that is recorded in a registry. In the webid protocol, one makes a statement about oneself - using a self-signed cert with URL pointer to a resource. The name now exists, in a namespace. Call it URIs, if you must. Its a name and a reference at the same time.

The party about whom the certificate was issued can leverage this statement by the third party to authenticate to a second party who is suspicious. This is known as solving the mutual suspicion problem. It requires making additional statements, dynamically. 

What do folks do, with certs (apart from authenticate people, authenticate agent-entities, originate data, authenticate handshake flows)? In the protocol they sign using their "signing" authority - just like client auth in SSL has you sign an SSL message. That message is a limited statement, released to a particular audience. If you design the sequencing right (and 10 other designs have failed, subtly), certain security properties emerge in handshake design, allowing one to claim, formally, there was "peer entity authentication". Stronger claims can be made if additional design elements are used.

https is interesting becuase certs were used for statement making. Just as client auth from the SSL layer signs to make statements (above), SSL entities (which can be foaf-agents) can sign their own certs (referring to themselves).

certs have long been used to "control" behaviour, of which the FBI policy for social control was just one. Not to berate FBI, its a political issue, about which folks vote... on intractable issues. For example, the cert issued to a bank in 1994 had to work with browsers issued to UK folk, who were not allowed American crypto in the software. To dumb the transatlantic crypto used on the wire down, the bank server minted another server cert, on the fly, using its statement making power. So literally, the cert  chain sent in the SSL cert message got one more entry in than the same message sent to American browsers going to the same banking site. The extra cert was a statement by the server, using "authority" delegated to it for that purpose, by the superior statement maker (VeriSign in all probability). I authorize you to be an "agent" (in pseudo-speak), so we jointly comply with export regulations concerning US-UK traffic.

That practice of "foaf-agents" (called SSL servers, historically) minting certs on the fly became generalized, and certain ciphersuites negotiatiable in the SSL handshake are known as "ephemeral" - becuase the agent can mint such "extra cert" in the chain - provided its valid only for a limited audience (for that session/handoff, even). Its minted by an foaf=agent NOT authorized otherwise to manufacture "certs," using their signing key. its a limited delegation of power, that is - done to fashion some or other control regime.

Being software, the enforcement logic for control regimes doesnt know or care about the social motives of the control policy. Its just goes klunk, and enforces it during connection establishment.

The trick now is take all this "apparatus" and mix it with the kinds of logics that folks in the semweb are used to designing. Then, we get a modernized https that can both leverage the semweb, and semweb that gets an https that fits its needs.

Isn't webid protocol exciting. It's the first time https.next design has been formally designed by a public standards process. The last time (1994) it was a private little group intiially, and then an NSA-influenced exercise in the SSL v3 (Netscape) and PCT v1 (Microsoft) era. Hard to complain they did a bad job (....16 years later, and still going strong). But, its time to fundamentally review https, so it ready for another duo-decade of applicability.

> Subject: Re: [foaf-protocols] virtual hosting in modern browsers
> From: dirk-willem.van.gulik at bbc.co.uk
> Date: Sun, 30 Jan 2011 16:31:19 +0100
> CC: foaf-protocols at lists.foaf-project.org
> To: home_pw at msn.com
> 
> 
> On 29 jan 2011, at 19:01, Peter Williams wrote:
> 
> > > From: Dirk-Willem.van.Gulik at bbc.co.uk
> 
> > > Lets try to reset this a bit. I think we have a couple of related though somewhat orthogonal issues:
> > > 
> > > 1) We want to do mass virtual hosting on SSL - but not the cost of many IP addresses and config hassle.
> > > 2) Is the use of SNI fine for foaf-protocols from a technical/security perspective
> > > 3) Is the cost of SNI for the server managers low enough ?
> > > 4) Is it supported by enough browsers.
> > > 5) What if not ?
> > > 
> > > To go through these:
> > > 
> > > 1) We want to do mass virtual hosting on SSL - but not the cost of many IP addresses and config hassle.
> > > 
> > > In HTTPs - If you want the server to authenticate and have a PKI style trust established you need to have a server side certificate which matches the hostname or IP (but strangely not the port). Thus nomal SSL thus requires a unique TCP endpoint per server (cert). And as we do not like funny port numbers (e.g. anything but default port 443) we would need an IP address per host-part in the FQDN.
> > 
> > For the longest time, the fiddle that avoided this was the wildcard cert *.verisign.com. It nicely solved all problems: no cert dialogs, one cert, virtual hosting, 1 external IP, URL (MVC) or HTTP (host-header) switching of "sites".
> 
> Except for one crucial case - a wildcard cert only lets you do alice.blogspot.com, peter.blogspot.com, etc, etc - the tail part of your FDQN needs to be identical.
> 
> While SNI allows any name - just like normal vhosting.
> 
> > > Now IP addresses are not 'free' or in endless demand as they carry quite a bit of organizational/governance/communication overhead and coordination. 
> > > 
> > > There are various fiddles possible - and one of those is SNI - which was designed with just this issue in mind.
> > 
> > SNI exist to avoid the wildcard cert cost. Period. To arm all the benefits above, the monopoly CAs ran riot with their pricing plans for the wildcard cert. SO, competition...removed their monopoly :-)
> > 
> > SNI allows the server farm in exactly the same setup as above to either have 1000 certs (with 1 private key, even), one per tenant - sending the right one back to the browser in the handshake that occurs before HTTP requests even get released to the internet.
> 
> Ok - as far as I know this is a bit hard to know with the normal tools - and I do know that some CA's will reject a CSR (a certificate request) which has a non-unique public key - but I guess that is not a technical hurdle.
> 
> > SNI is also interesting because those 1000 certs dont have to be pre-issued. They can be manufactured on the fly by the server, using what is called the "ephemeral" ciphersuites. Certs are just a chain of statements, and the last statement maker can add another on the end of the chain, dynamically. its up to the verifier (browser) to track the chain and determine that this is not spoofing, which brings us to "authority".
> 
> Ok - I've lost you here - so exactly what are you doing here ? Are are you doing what normal (legal) intercept systems do - assume the pretense of a CA certificate (trusted by the browsers as indeed a CA) which auto-signs any 'new' domains on the fly ? (E.g. much like companies can be allowed to issue certs within their own company - which are a sub-ca of a normal CA) 
> 
> In that case - be aware that those beasts are rare and secondly - that this is not tied to SNA - it can be done with normal SSL certs too ? Or am I missing something ?
> 
> Dw.

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