atom feed13 messages in org.foaf-project.lists.foaf-protocolsRe: [foaf-protocols] The Universal Ke...
FromSent OnAttachments
Melvin CarvalhoMay 6, 2011 2:53 pm 
peter williamsMay 6, 2011 5:20 pm 
Melvin CarvalhoMay 6, 2011 5:32 pm 
peter williamsMay 6, 2011 5:49 pm 
Melvin CarvalhoMay 6, 2011 5:54 pm 
peter williamsMay 6, 2011 6:22 pm 
peter williamsMay 6, 2011 6:28 pm 
Melvin CarvalhoMay 6, 2011 6:42 pm 
Henry StoryMay 7, 2011 12:34 am 
peter williamsMay 7, 2011 3:23 am 
peter williamsMay 7, 2011 1:47 pm 
peter williamsMay 9, 2011 5:39 pm 
Henry StoryMay 10, 2011 7:03 am 
Subject:Re: [foaf-protocols] The Universal Key : how to securely create one key for PGP , X.509 and WebID
From:Melvin Carvalho (
Date:May 6, 2011 6:42:43 pm

On 7 May 2011 03:28, peter williams <> wrote:

Here is one trust metric

There are a thousand more. Just look.

My general point is that PGP trust metric is useless beyond 10 people, working in general society. But, you start to see what the elements of the dynamic system need to be. They are a balancing act. IN general, no one has found a balancing act that fits a large number of normal-life needs.

But, that TBL's job. Did it once before.

Thanks for the pointer! Graph Theory was always my favorite subject at uni.

I guess there's a few approaches. But we dont need to go from 0 to 100% in one iteration. We just need to do enough to make a system usable practical and extensible.

I'll do some thinking and see if I can create a practical prototype that can add some value to the ecosystem..

-----Original Message----- From: peter williams [] Sent: Friday, May 06, 2011 6:22 PM To: 'Melvin Carvalho' Cc: '' Subject: RE: [foaf-protocols] The Universal Key : how to securely create one key for PGP , X.509 and WebID

Absolutely. Given a chain of certs (woops, I mean linked data graph relating webids), do what DARPA had RSA do 2 decades ago for a series of n DNs related by a cert chain (.p7c file). For each such file (link set) you can find in your cache, given n links in m chains ( of a different (n) links), find out which chain is "strongest". Use that one (not the n-1 other) when deciding if its pubkey is "authentic". Thereafter, assume that some signed service is not spoofed (because its endpoint ties by math to the certified key, which is at confidence level C, which is  greater than your minimum for confidence).

If you look at the GNU-PGP (command-line) implementation, it kinda illustrates how the "contribution of n recommendations" gets reduced to a metric. If n people black ball P on M's keyring, and the n people are all have good reputations from M's perspective, than its bye bye P-peter, in terms of reputation.

Anyone caring to ask M for his opinion about P gets "how M would have behaved" in the circumstances.

It' just a variant of experimental theory. Score the results a particular way, in order to tease out the "significance" of some dominating factor in a set of not-independent factors. Perhaps you discover the formulation of penicillin, finally. Or, pick some other experimental design, teasing out causal relations that imply a different qualify of trust. Or, follow the Gaddaffi rule...(eliminate false positives).

-----Original Message----- From: Melvin Carvalho [] Sent: Friday, May 06, 2011 5:54 PM To: peter williams Cc: Subject: Re: [foaf-protocols] The Universal Key : how to securely create one key for PGP , X.509 and WebID

On 7 May 2011 02:49, peter williams <> wrote:

Of course not.

What I described was OCSP ( a kind of webservice), in which criteria for issuing the signed response of "good status" is that PGP key ring says: pubkey has power-level P, under PGP trust metric (and P is above the requesting parties threshold).

The original OCSP was written over a weekend, by Microsoft/VeriSign. For all million certs (not self-signed at that point), compute the authorities trust metric at 0 hours GMT (didn't use the PGP trust metric, at that time). Millions times, Sign a canned response for an awaited webservice call (a restful GET. over https). The response contains the metric value.

Today, we can do better.. We can compute the metric on the fly, sign the response on the fly, and tune the response to do what was know at the time as "contextual" validation. That is, given a pubkey about webid W to test, and the requesting parties P name, find P threshold by local look, calc PGP trust metric for W , and sign go/nogo if metric.W < threshold.P

No private key involved (except the web service agent signing responses).

Yes, I suppose one would argue that the service agent's signature would ideally be supported by a webid in its signing cert - inducing a second call to a second responder to qualify if the web service party A was "authoritative" for trustmetrics about W given R. This is requires an reputation service that qualifies whether A has any basis to speak about the reputability of W. But, perhaps wait a decade for that.

Sounds pretty interesting.

I dont know much about the PGP and X.509 trust metrics other than the basics.

I know that in OpenPGP you sign each other's keys and assign trust values (1-5) and I know that in Thawte used to have a points system and notaries for signing X.509 certs.

Are you saying that you think it's possible to take some of these existing metrics and build on top of it, using linked data?  If we can work out the rules, I could possibly put together a prototype key server.

               -----Original Message-----                From: Melvin Carvalho []                Sent: Friday, May 06, 2011 5:32 PM                To: peter williams                Cc:                Subject: Re: [foaf-protocols] The Universal Key : how to securely create one key for PGP , X.509 and WebID

               > Someone else can then write a webservice, that front that key ring.                > Asked for the GNU+PGP trust metric for the pubkey (given keyring                > contents), the webservice responds with the GNU-PGP metric. An                > "enhaced" webid VA might refuse to handle an inbound client cert if                > the trust metric reported for said self-signed cert (by "webservice")                > is not above threshold T, stored in the account of the service                > consumer. Ideally, service consumer invokes service using webid...and https.

               Surely you dont want to expose your private key to a web service?