I’ve been thinking about signing XML nodes. The existing mechanisms are either really complex (XML-DSig) or over-verbose (Magic Sig). This could be useful in RSS/ATOM feeds, XMPP, and other XML-based communication formats. The purpose of this proposal is to provide a lightweight signing (and optionally, encyption) mechanism for embedding inside XML nodes, while not inventing any new XML namespaces, elements, or attributes, not inventing a new envelope format for the signature data, and not suggesting a new way of transmitting octet streams in a text safe way.

Normalization

In order to preserve the form of the XML being signed, an exact textual representation of the XML tree to be signed must be included in the signature packet (“opaque signing”). This is similar to the strategy employed by Magic Sig.

It is recommended that the fragment be encoded as a valid standalone XML document, so that parsers can easily feed the unwrapped content to an XML parser and use the tree that results, without having to graft the text back into the original XML document for parsing.

Envelope format

Rather than inventing a new envelope to mark up what algorithms were used to generate the signature, I suggest using the standard OpenPGP packet format from RFC4880. This standard is well-deployed for use in Email and other cryptosystems, and there are implementations, or partial implementations, in many languages, including PHP.

Inclusion in an XML node

An opaquely signed XML fragment is just an alternative representation of the node it wraps. This relationship is well modelled by the ATOM link element (namespace http://www.w3.org/2005/Atom) with the rel attribute set to alternate.

RFC3156 defines an Internet media type for encrypted and/or signed OpenPGP data as application/pgp-encrypted. This makes an appropriate content for the type attribute.

Text-safe encoding of octets

Protocols may wish to include the OpenPGP packet directly in the XML document, instead of linking to an external resource. In fact, this is probably the normal case. RFC2397 defines a useful mechanism for encoding arbitrary octet streams (such as those used in the OpenPGP binary packet format) as URIs for use anywhere a URI is expected, such as the link element’s href attribute. The media type included in the data URI should be application/pgp-encrypted.

Example

Below is an ATOM fragment demonstrating this recommendation:

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Test Feed</title>
<entry>
<title>Test Entry</title>
<link rel="alternate" type="text/html" href="http://example.com/item1" />
<published>2010-03-26T06:47:47+03:00</published>
<link rel="alternate" type="application/pgp-encrypted" href="data:application/pgp-encrypted;base64,owGbwMvMwMF4UUZT8FzgnHuMa/4msZUY6VXk5nhvuC9pYw9kKJSlFhVn5ufZKhnqGSgppOYl56dk5qXbKoWGuOlaKNnbcdmk5pUUVSoA1eYV2ypllJQUWOnrl5eX65Ub6+UXpesbGRiY6juW5OcqAdWWZJbkpNqFpBaXKLiCtNnoQ0S4bHIy87IVilJzbJUSc0pSi/ISS1KVFEoqC1JtlUpSK0r0M0pyc5QUMopS0+CWpFYk5hbkpOol5+fqZ5ak5hoqKegDTSooTcrJLM5ITbEzMjA00DUw1jUyCzEwszIxByJtA2MrAwMbfYQiLht9sA/suDqZZFgYGDkY2FiZQP5n4OIUgAXN+W/8v5h/vXu4cBXbrfUVT0yXTKsI+h1Qw2/zdYZ9h/yJ+/r5L7U1xc/sWMTh4Du1MXjKWsMHP2KZ0ooy7ZVFz0ps011ZaZDUl78y5JbdCbeMNcEcjb0tS1yEu7hfZX6Wsi+qeMDRZO1/1+Lt8c1fqloOLHSqe6YyX8dsp9HmtZlXkxdZVT/67Jcnxig59Rj/Gv0Nr0RPdSg68a/r3vKvV3tavvvyXP6wtWu3NHJrFR25euzI/VdnVMzjuDYt47gjxnm956jU72cvfXj7Dk79+yqfkyPCxfyo/ZFdTJtfK1ncYgur6Dqp47r4EcfZ2pDNwk4n5vYwOfjuWM09Ye6ij+nnbi2Zn2ld/zhx4o+Z2XoF6Twucayxa80urHWeMF0nw/mq2fLFhuv1PWaXRtoHHr9qMc9e+tjdD5KhxQV3Jr49d2YZ2+WjD49UfqtLYVxfxzy3iiG4YWvZHfl2g/yPtx3M+rqVuVbM2Vpzq9q76OytfQsjm769Ely2PGDTmg8ak2frnfL9/49VPKPU8vj0Y0diN213uNkrfeH15TbjM09el/2rCF5v/Uryd3XXB8OfbedesyRJH1s7dWPB04JFvA9Zp6y7IfI2VDo8VHiHVpmqR+aERRt/7Dy1NtmV+48KH8/l7ebCr4KNb7v3SSqfdWDey7lkQ+Nzwdfb1vOlTzXU1zyx0kVX3v2t9h+f1T1px+KuX7rw8gOb17St+69/kvkKAA" />
</entry>
</feed>


First off, why would one want to do this? Well, cryptographic security is useful in communications medium other than email, and sometimes one may not have an email address for the person one is contacting. Also, a public key got from someone’s profile page is more likely to be their current key than the one got off a keyserver. Finally, if the discovery is done over TLS (or upcoming XRD signing techinques) then one can use the PKI to verify that the public key is, at very least, the one the owner of the URL claims. Which, for pseudonymous communications, may often be enough.

I will here propose three different ways to make this discovery work. Consumers must try all three. Publishers may publish more than one.

Content Negotiation

A public key represents a person. If a URL represents a person (such as on a profile page), then were that page’s data to be represented in the OpenPGP key format, one would get the user’s OpenPGP public key.

Send the header Accept: application/pgp-keys along with an HTTP GET request. If the Content-Type on the response is application/pgp-keys then the body is the user’s OpenPGP public key.

Links

If a GET or HEAD request is performed on the URL and in the headers is a Link header with rel=me and type=application/pgp-keys, then the URL of that link is the user’s OpenPGP public key.

If the Content-Type header of the GET request is text/html or application/xhtml+xml, then look in the page for <a> and <link> tags with rel=me and type=application/pgp-keys. If there is such a tag, then its href attribute is the URL to the user’s OpenPGP key.

LRDD+XRD

If LRDD discovery is performed on an endpoint, leading to the discovery of an XRD document containing a section like the following:

<Link>
<Rel>http://www.iana.org/assignments/relation/me;
<MediaType>application/pgp-keys</MediaType>
<URI>...</URI>
</Link>


Then the URI is the URI of the user’s OpenPGP key.

Security Considerations

The URLs used in all methods above should be either HTTPS URIs secured using TLS and a certificate issued by a CA known to the client, or data URIs.

Application to Other Crytography Schemes

Everything in this document applies equally well to public keys for any cryptography scheme, as long as the MIME types are changed appropriately.

So, one of the things I decided to do with the transition to my new PGP key was add a small JPEG photo (my common avatar, which is indeed a photo of me) as a UID. This is something OpenPGP keys have supported for some time, it doesn’t add too much to the keysize (as long as you keep the photo small, which I did), it helps people to identify me, and ties the key more firmly to my IRL identity.

I then discovered a problem: some old keyservers, like pgp.mit.edu, *will not* accept keys with photo UIDs. It’s not that they ignore the photo, it’s that they simply refuse the key!

So, with the help of Daniel Kahn Gillmor, I have discovered the strategy for uploading these keys to the old keyservers using the CLI interface to GnuPG (which is what I normally use for my OpenPGP stuff).

cd /tmp/
mkdir -m 0700 testring
gpg --export KEYID | GNUPGHOME=/tmp/testring gpg --import
GNUPGHOME=/tmp/testring gpg --edit-key KEYID

# Select the photo UID by typing it’s number

deluid
save
GNUPGHOME=/tmp/testring gpg --keyserver pgp.mit.edu --send KEYID
rm -rf /tmp/testring