FOAF + Encryption

2010-01-19

Let’s first talk briefly about FOAF+SSL. There’s an article describing FOAF+SSL in detail, but I can summarize. You authenticate with a web server via an SSL client certificate, and all sensitive FOAF data is returned via that encrypted channel. The identity embedded in the client certificate can be used to selectively grant or deny access to certain information.

In principle, it’s a good solution. What I strongly dislike about it, however, is that it necessitates a fair amount of processing on the server side. Gone are all the features I listed earlier as bits I really liked about FOAF. And the same would apply if you used any other authentication method, such as OAuth or OpenID schemes.

I briefly toyed with the idea of mixing either of them with FOAF before I knew of FOAF+SSL, but you would end up with something just complicated enough that few people would run it on their own servers. It would open the doors for some service provider such as LinkedIn, XING or Facebook to provide FOAF files rather than each person hosting their own. And while I have nothing against offering such services, I’m not entirely happy about all but neccessitating such services.

So to me, FOAF+SSL is a non-starter.

Luckily PGP has demonstrated quite neatly that it’s entirely possible to distribute information in such a manner that it only reaches the recipients you want it to reach, while keeping the information freely copyable and thus able to live at any location. The simplicity goes out the window, at least to a degree: I don’t think anybody would perform encryption or cryptographic signing by hand with realistic key sizes.

And this has been recognized before I happened to think of it again. There’s a specification/proposal for encrypting FOAF files with PGP keys. And while that’s already pretty good, there are a few bits about it I’m not too keen on.

And finally we’ve reached what I really wanted to write about. But we had to be on the same page before I started, right?

First of all — and that’s the most petty of reasons, I admit — I’m not a huge fan of necessitating external files. In the proposal, you point to an external file that contains the encrypted information:

  <foaf:document rdf:about="http://heddley.com/edd/foaf-private.rdf.asc">
    <!-- encrypted for the #foaf community -->
    <wot:encryptedto>
      <wot:pubkey wot:hex_id="6C7F734E">
    </wot:pubkey>
  </wot:encryptedto>
</foaf:document>

What bothers me about this is that it’s an approach to encrypting parts of a file that’s both fairly specific to RDF and to FOAF. I would much prefer a more generic XML vocabulary. The actual changes I would proposing are not all that big¹, but the semantics change considerably:

<asdf>
<!-- *Allowing* external references is awesome -->
  <crypto:pgp_external src="http://...">
 
  <!-- But I'd like to be able to embed data -->
  <crypto:pgp_encrypted><!--[CDATA[
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (Darwin)
 
g5DqOp+RqcKYutEHdOeaDIxOAPNcxZyOrEIG4q2pKCjnwAAjLYqkoBe3dGhp5TO7
...
elf1eqg7I2iR/lQK2zC9NH1oGcEwYplZQarwHDUHvElzMeZ72bgynt0=
=AxgK
-----END PGP MESSAGE-----
  ]]--></crypto:pgp_encrypted>
</crypto:pgp_external>
</asdf>

The semantics of both the proposed <pgp_external> <pgp_encrypted> for a processor are identical: take the encrypted data, decrypt it, and add the resulting XML nodes as children of the original node. If you can’t decrypt it, make the original node empty. In other words, the above might be turned into the following before processing:

<asdf>
<!-- We didn't have a key for the external file, so the node is now empty. -->
  <crypto:pgp_external>
 
  <!-- However, the embedded stuff could be decrypted -->
  <crypto:pgp_encrypted>
     <foaf:person rdf:about="#me">
      <foaf:name>Jens Finkhäuser</foaf:name>
      <foaf:title>Mr.</foaf:title>
      <foaf:givenname>Jens</foaf:givenname>
      <foaf:family_name>Finkhäuser</foaf:family_name>
      <foaf:surname>Finkhaeuser</foaf:surname>
    </foaf:person>
  </crypto:pgp_encrypted>
</crypto:pgp_external>
</asdf>

It’s a small change, but why limit the use of a specificatin for encrypted parts of an XML file to FOAF?

XML-savvy people may point out two problems with embedding encrypted information in XML like that. First of all, it would make validating the XML a lot harder — you’d have to hook a specialized decrypting step into the XML-parsing process before you can validate a complete document.

You don’t have that same problem with external references: they’re completely transparent to the XML validation, as they are treated as separate documents. The issue can be illustrated by assuming that the embedded encrypted information would be decrypted to a simple String: <asdf>

Clearly in that case, the XML with the encrypted part untouched would be valid, while after substituting it with it’s decrypted counterpart would result in an invalid document.

Personally I don’t find that to be an argument for disallowing embedding. It does make validation a bit harder, but we’re talking about XML here. It’s not as if validating XML was easy. But I can understand if people heartily dislike the embedding part of my proposal above: the point about not tying encrypted parts of an XML document to either RDF or FOAF remains strong.