Rel-publickey and Rel-pgpkey Specification

Rel-publickey and Rel-pgp are a simple open format to indicate that a link points to an individual’s or entity’s PGP or other public key.

Specification 6-Sep-2013


Mark Burnett (


This specification is released into the public domain per the Creative Commons Public Domain License or any later version published by Creative Commons; with a waiver of rights, and an assertion that no rights attach to this particular work.


This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.


The Rel-publickey attribute is to be used with HTML A and LINK elements to describe a public key related to the current document’s author, role, or entity. The link’s href attribute contains the URI of the key in either plain text or binary formats as indicated by the type attribute as shown in this example:

<a href="" rel="publickey" type="text/plain">My PGP Key</a>

The type attribute should be one of the following depending on the format of the certificate:

MIME Type Encoding Extension
text/plain ASCII .asc, .txt
text/xml XML (XKMS) .xml
application/pgp-keys Binary (PGP) .pgp, .gpg, .pub
application/pkix-cert Binary (DER) .cer
application/x-x509-ca-cert Binary (DER) .crt, .der, .key, .cer
application/x-x509-user-cert Binary (DER) .crt, .der
application/x-pem-file Text (PEM) .pem
application/x-pkcs7-signature Binary (DER) or Text (PEM) .p7s

Specifying Key Owner

The owner of the linked public key should be identified by the full name, e-mail address, or certificate id and may be specified in the title, id, or name attributes or within the anchor text. The author might also be assumed through a rel-author value elsewhere, an author meta tag in the page header, in an embedded hCard, or the owner of a domain or blog that uniquely identifies a single individual or entity.

Rel-publickey vs Rel-pgpkey

Due to the ambiguity of the text/plain format, one could alternatively use rel=”pgpkey” to explicitly define the key as a PGP/GPG key. When using rel=”pgpkey” the type must be specified as either text/plan or application/pgp-keys. The rel=”publickey” form may be used with any public key format.


Link to PGP key:

<a href="" rel="publickey" title="" type="text/plain">My PGP Key</a>

Use as a hidden link in the page header:

<link  href="" rel="publickey" title="" type="text/plain">

See Also

RSA’s Distributed Credential Protection: Yeah They Are Overselling it a Bit.

RSA recently announced their new Distributed Credential Protection (DCP) product which they proudly tout as a “revolutionary” way to secure user credentials. But looking closer (especially at that $160,000 per license price tag), I’m not so sure this product will do much to protect anyone’s credentials.

But let me say this first, the technology itself is absolutely brilliant. Without getting into the details of threshold cryptography (there’s an excellent article by Peter S. Gemmell on page 7 of this PDF), what it does is allow you to split up a secret into any number of parts but you only need a specified number of parts to reproduce the data.

“…let me say this first, the technology itself is absolutely brilliant”

It’s kind of like how you see nuclear missile launches in movies: two people have to insert and turn their keys at the same time to initiate the launch. But threshold cryptography is even more advanced, it would be like handing out 5 keys but you only need any 2 of them to fire the missile. What makes the technology so cool is that it gives you redundancy, integrity, and secrecy but no single piece is useful for obtaining the secret. This technology has many uses in cryptography (it would be perfect for Bitcoin) but I think that RSA’s claim that it will revolutionize password protection is greatly overstated.

The problem is that yes, you are splitting up credentials into multiple parts but all of those parts are components of the same system. It would be like handing both missile launch keys to the same person. Yes, someone would have to steal both keys, but if they can steal one from you couldn’t they just steal the other?

Now one of the claims RSA makes is that if you suspect that an attacker has compromised one of the databases, you can immediately randomize and rescramble the pieces so when they grab the second database the data is useless. So yeah if you happen to catch an attack right after an attacker grabs the first bundle of data but before they grab the second bundle, and you are able to immediately identify all points of intrusion and lock out the attacker so they can’t go back in and re-grab the first bundle, then yes this will work. What are the chances of that happening? Slim to none.

Splitting the databases into two locations is not particularly helpful because both must be accessible to the web server, which is usually the point of entry in these types of attacks, and therefore if an attacker can access one database they can likely access them both. Again, it’s like handing both keys to the same person.

The thing is that RSA’s DCP product is addressing the wrong problem with the wrong solution. The reason most companies get their data leaked is because they have poorly secured their public-facing servers and applications and that they don’t follow best practices for storing user credentials. Both of these problems already have solutions and any organization would be better off spending their money on some code audits and pen-testing.

The fact is that if you have problems with hackers getting into your databases, I think you will still have problems even after shelling out $160,000 for DCP. If you don’t have that problem because you have proper security controls and practices already in place, chances are you don’t even need DCP.

To be fair I have to mention that I have not seen or reviewed this implementation in depth so I could in fact be completely wrong with my criticisms. Perhaps this system could be deployed in such a way that it is much more resilient than I am supposing. And certainly RSA acknowledges that this product is just one layer in a multi-layered defense-in-depth strategy. But I still come back to the fact that you are giving both keys to the same person.

What I would like to see is this technology implemented in a much smarter manner. For example, distributing credentials across multiple distinct trust authorities. For example, it would be a great way to overcome many of the weaknesses and distribution issues we see with SSL certificates. Having multiple holders of a secret not only better protects the secrets but upholds integrity in the case a small number of authorities are compromised. This technology could be helpful for preventing insider attacks and would be useful if you have your servers at third-party data centers that you may not completely trust. There are also some legal advantages with having databases distributed across multiple jurisdictions. And hey, if this technology prevented just one attack, in the absence of other attacks it would probably be worth the expense.

There are many other areas that could greatly benefit from threshold cryptography, but splitting credential storage within an organization is probably not one of them. The concept of a black box authentication appliance (although this is vm-based) is a great direction to be going, considering how many organizations simply don’t implement credential storage correctly, but they seem to be overselling (and overpricing) what this product really can accomplish.