[foaf-protocols] Self-signing certificates

[Peter Williams]

FOAF+SSL relies on the fact that the certificate and the FOAF file
confirm each other.

It cannot prove whether or not somebody is TimBL, but it can prove that
they have write access to TimBL's FOAF file.



[Peter Williams] 
[Peter Williams] 
Not really, as not all foaf cards are persisted as files (or even persisted
e.g. sixpart, or semantictwitter). But, at this early stage, it's a good
enough design metaphor (it "can", not that it "does"). Lots of communities
go through this idealized world view, of how simple public key crypto is.
Trust in PGP culture, a few trust files, key signing parties, and life is
good for 6 billion people to use PKC.

The key thing, which _is_ being achieved, is to get into the mindset of
"being a relying party" (relying on client certs as signed-names in some or
other name form, and relying on server-certs from transport channels as
signed assertions about the name-form known as domain-names and its binding
to a local socket/endpoint).

All the foaf card is in foaf+ssl ... is a trust store of (unsigned) pubkeys
- a resource keyed off the URL in the SAN (just like any other web
resource). It's no different to the trust store in a replicated/distributed
ActiveDirectory entry, keyed off the UPN name form in the SAN. The
foaf+ssl's trust store stores mod/exp, whereas the distributed
multi-mastered directory stores (self)signed certs (with mods/exps within).
Not sure there is gounds for a patent here; as the webid is a mere
embodiment of very old teaching.

The process of validating a client cert from SSL is different in foaf+ssl
(and we know the foaf+ssl behavior concerning SSL CA and cert selectors is
the default operating mechanism of commodity, $20 a year, OS products, like
Windows).. 

IN the foaf_ssl case, there is stuff about using mods/exps and doing integer
compares using some rdf logic.  It is required to use the type system
reasoning of rdf reasoned (even when comparing a signed and unsigned ints).
In the UPN world, the SSL server simply computes the inbound client cert's
fingerprint, finds the cert by fingerprint in the trust store cache
deferenced by the UPN, confirms the fingerprint match, and then verifies
that the self-signed cert does self-sign. In more advanced cases where the
client cert is not self-signed, for a chaining cert there is process
recursion, using the certs' "issuer backpointer" to locate and deference the
linked assertion of a inbound cert arc, in the trust chain. Having found it,
and having resolved its name form (which may now not be a URI, but may be a
GUID tied to the activedirectory system), one does another round of
validation... In dynamic systems, the backpointers may be an expression
rather than a fixed value, which guides discovery of an earlier trust point,
in the trust fabric available to server.