[foaf-dev] missing the value - of SOAP tokens cooperating with REST tokens
pwilliams at rapattoni.com
Thu Apr 15 20:54:34 CEST 2010
I've lost the link, but some more interesting PRATICAL cert linking cases are emerging - BECAUSE of browsers offloading ssl-related trust enforcement login now to plugins - such as cardspace plugins.
recently, a browser was interacting with an SSL site. Technically, the browser plugin was doing the SSL interaction (via the browser's comms stack). The common browsers USED NOT to expose to plugins neither their trust stores (of root and intermediate cert stores) nor the entire chain of certs used to descirbe the actual SSL server endpoint (limiting visibility to only the end cert on the chain). Thus, the plugin could not, given a single SSL cert from the server, DISCOVER the path of cert using those cert stores.
two things happened, given these limits:-
1. leveraging platform APIs (on windows),the client plugin could use backpointers within the 1 cert it had to find parents. In the windows world, anyways, the client libraries use the wintrust providers, whose several methods (some of which are patented) to discover a chain of trust handoffs - represented by one cert issuer minting another cert, in some or other trust fabric. In many cases, these methods leverage a backpointer ref within the endpoint's own cert, of which the so-called AIA field is a common one used in IETF-standardized methods of backpointer discovery (its a just a URL to the parent's .cer file on the web). Other methods do synonym searching based on embedding ldap query URI in the cert; others leverage the cert issuer name as an indiex, and some methods use key identifier field. Its all just the usual backwards-reasoning search story...., tuned for cert paths.
2. But not all certs have such backpointers (particularly in more basic mozilla land). This means the plugin would bve uanble to find a wintrust provider that closed, and would implement its own trust store concepts - from which it then performed discovery. Nothing stopped the plugin using a webservice (e.g. SPARQL protocol) to remote that act.
Neither approach was found to be particularly successfully (mostly because noone implementing 2 seems to have thought of using the semweb and foaf card as a ready built infrastructure).
So, folks opened up the browser/plugin API for cert handling - in that the browser can now support the plugin. Optionally, the plugin can now either receive the locally-discovered CHAIN of certs that the browser "would have applied" itself (were it the policy-enforcing client), or one can now consult the browsers/platforms cert stores as a discovery aid (allowing plugins to leverage existing management capabilities in the browser/platform).
More information about the foaf-dev