FOAF + Encryption

2010-01-19

The second part about the original proposal for encrypting parts of a FOAF document I dislike is that it requires to specify in XML the key of the recipient. ASCII-armored PGP output already contains that information; it adds nothing to readability or security to duplicate it. So don’t.

What may be of interest are either a more generic <encrypted> tag, that specifies via an attribute the exact encryption method used. One advantage of that would be that there are already well-known specifiers for encrypted data, namely mime-types such as application/pgp. Specifying a type attribute would make sense for either external references or embedded encrypted data.

I have fewer criticism for the original proposal for signing FOAF documents with PGP. Again, I’m not much in favour of requiring an external signature file, although I recognize that again processing becomes harder when you embed it.

In either case I favour the easily copyable nature of single, complete files over the cost of slightly more complex validation. One aspect of this is that I’ve found mobile platforms such as iPhone OS to be fairly bad at requesting multiple files, whereas downloading one larger file is usually faster. Similar finding have led people to embed multiple files in a single HTTP response, etc. Anything that simplifies the networking part of distributing information seems like a no-brainer to me, while slightly increasing local client-side processing seems comparatively cheap.

Regardless of these slight differences, though, encrypting part of a FOAF file with PGP is awesomely useful. PGP has the nice property that you can name multiple recipients/keys with which to encrypt data, without duplicating the data itself. That’s done by encrypting the data with a symmetric key and then encrypting that symmetric key with the public key of each recipient. In that way, I can grant fine-grained control over who can see the list of people I know, or my own contact details.

When I briefly discussed this with Dan, he mentioned that he found it undesirable to embed the access control list in the document. With PGP, that’s definitely the case: the keys of the recipients become an integral part of the document.

It turned out that his objection wasn’t so much a question of tight coupling, but one of dealing with groups of people. One might want to publish a document for use of a company, regardless of who is currently employed at that company.

The simplest option is of course to separate the encrypted data from the encrypted symmetric key into independently maintained files. It may seem rather ironic for me to suggest that after I just criticized the original encrypted FOAF for requiring separate files.

I think there is a crucial difference here, though: one separates encrypted from plain text information in order to make processing easier. The other separates data from an ACL for that data.

It would require two steps to make that possible. The first and simple step is to add an attribute to the above XML that specifies the ACL data:

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

The file pointed to via the acl attribute would simply be PGP encrypted data, where the data is the symmetric key for the original information, and it’s encrypted with the key of all intended recipients of the original information. So far, so good.

But crucially, PGP-encrypted data already includes information about the keys with which the data was encrypted. As such, using the application/pgp format for the encrypted data is not going to work. We may need a different format, that contains just the cipher text and nothing else. I’ll get back to that later.

The bigger problem with this approach is endemic, however: if you encrypt sensitive data with a symmetric key, and then distribute the symmetric key, anyone who ever got access to it will be able to access the encrypted data. The only way to prevent this is to generate a new symmetric key each time the ACL changes, and therefore re-encrypt the sensitive data. As a result, while you strictly speaking separated the ACL from the document, they’re so tightly coupled that you might as well not bother.

The other option, of course, would be to not bother generating a new symmetric key when the ACL changes. And there is a simple argument for that: if I ever had access to the symmetric key, and decrypted the sensitive data, nothing prevents me from copying the resulting plaintext. In other words, once you hand out a key, you irrevocably hand out trust over the plaintext anyway — there is no way around it.

Note that this does not mean that you should always encrypt future revisions of the sensitive data with the same key as previous revisions. If the data changes, then using a new key to encrypt it would prevent automatically granting people who have access to one revision access to the next. You may actually want that. But you definitely must use a new key if both the data and the ACL change at the same time, or lose the security encryption grants you.