[rdfweb-dev] pgp signing

[Bill Kearney]

> I don't want to do this, I don't want people to know my public key, they
> might use it for something, the only reason I have a public key is for
> signing RDF, I don't want _people_ to know my key, just the robots.

Err, isn't this what a public key is for? Is there some risk with the key being
known? And how is a robot going to "knit together" the link from your document
to your key unless they can find it to begin with? Doing lookups of your e-mail
against the keyservers would work, I suppose, but it adds a layer of complexity.
Your foaf contains an mbox_sha1 that has to be resolved "locally" to the real
mbox. That gets queried against the keyserver to extract the hex_ID and/or
digital fingerprint or other details. The trouble is a query of
cerserver.pgp.com shows there to be quite a few Jim Ley's listed. Only one with
the jibbering.com domain though. So yes, you could avoid putting it in the file
and for any other signed documents (RDF or otherwise) it might make sense to
avoid bothering. But for the fragment of RDF that /defines you/ it seems like a
shorter process to just include the public key.

The worst thing people could do with your public key is sign something TO you.
But they've got to sign with their own key to do it. Given most spammers aren't
at all interested in being tracked down it seems rather unlikely they're going
to do this. And in the case of e-mail this isn't a failsafe against using
whitelisting or other inbox management techniques.

> This is difficult, it means that I cannot say that a particular document
> can be trusted unless I also created it, it seems reasonable for a tool
> or my secretary to create a document, and me then sign it off as being
> true by signing it (or US Chief Exec's signing of their accounts as they
> now have to, do they also have to create them all when they publish in
> RDF?).

Quite rightly, but doesn't that get deeper into per-fragment signing? This is
an area where XMLDSIG does seem to have covered a lot of ground. I've seen
various vendor solutions that handle the flow and signing of such things.
AssistantA creates the document, signs it and forwards it to SupervisorB with
instructions to sign a portion within the document. The framework application
handled the dirty work.

> I also don't see what's gained by having the information of the creator
> of the doc in terms of how trusted the document is, the key identifies a
> person, is that not sufficient?

If there's not a way to determine what an individual claims then how will it be
possible to avoid hijacking someone else's triples? Or to at least check the
provenance of them to /try/ to get an authoritative source. As long as you're
consistent there shouldn't be a problem with your signature being linked in this
manner. As in, if you consistently sign enough (not everything needs signing)
things with the same URI/key then it'd be possible to draw a clear picture about
what you're being authoritative about.

-Bill Kearney