• Keyoxide

  • Shifting to signatures as primary source of cryptographic material

I am strongly considering putting a higher emphasis on signatures as supports of identity claims and other material that needs cryptographic verification.

The problem with notations

There are multiple reasons for this, the main one having to do with notations themselves. After a year of Keyoxide development, I consider notations an "exotic" feature of OpenPGP: barely used by any project — still haven't heard of any other project using them besides Keyoxide —, not supported by any of the major OpenPGP GUIs, barely supported by OpenPGP libraries — I only know of openpgp.js and Sequoia-PGP.

I find it hard to make a strong case for supporting notations as the primary source of identity claims. The best argument is that notations live inside public keys and there's already extensive infrastructure to publish and distribute OpenPGP public keys.

The case for signatures

Signatures have two significant benefits over OpenPGP notations:

  • widely supported by libraries (nearly all libraries support signing documents)
  • opens Keyoxide up to other protocols (minisign, SSH)

The "only" thing really missing is infrastructure. There are no servers where people can easily upload and distribute signatures (like HKP) and also no protocol to host and discover signatures on own servers (like WKD).

A big problem to solve with "signature distribution servers" would be avoiding/handling spam, if uploading a signature could maybe be as easy as a HTTP PUT request.

yarmo changed the title to Shifting to signatures as primary source of cryptographic material .

If signatures can be made to work for our use case, I think that could be good.

Can you outline how you envisage it working on a technical level? I can sign my own key, but can that signature contain information beyond "I assert that I trust this key"? (Since that's the primary purpose of signing keys in the standard PGP model.) Is it possible to add the "claim" information (URI, basically) that we currently add in notations?

The "only" thing really missing is infrastructure. There are no servers where people can easily upload and distribute signatures (like HKP) and also no protocol to host and discover signatures on own servers (like WKD).

That's a major drawback, indeed. But I think it actually only applies to keys.openpgp.org. I can upload a key to my own WKD server with whatever signatures I want (well, I could if I didn't delegate my WKD server to keys.openpgp.org... 🤔). The "old" keyservers (the SKS pool) also host signatures, though those servers are obviously legacy and also operating in violation of GDPR.

Of course, the reason Hagrid (primarily keys.openpgp.org) does not support distributing signatures, is because they're intended to be added by other people, not by the key owner. Which in itself is a terrible thing for the reasons we discussed earlier on Matrix (basically, to summarize, other people can unilaterally publish signatures on my key and I can't opt out of it) and also because of the potential for spam. (https://keys.openpgp.org/about/faq#third-party-signatures)
Of course, it might be possible to persuade the folks at keys.openpgp.org to make an exception for self-signed signatures? I don't know.
Note also that they explicitly don't support identities other than email addresses (https://keys.openpgp.org/about/faq#non-email-uids).

In the end, does switching to signatures but using them in a non-standard way constitue an improvement over using notations? I'm not sure.

Is it possible to add the "claim" information (URI, basically) that we currently add in notations?

Yes, we can bend signatures to our will by not signing keys but rather text documents. Currently, Keyoxide supports so-called signature profiles, here's an example:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey there! Here's a signature profile with proofs related to the DOIP project (https://doip.rocks).

Verify this profile at https://keyoxide.org/sig

proof=dns:doip.rocks
proof=https://fosstodon.org/@keyoxide
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEENjcgJSPnwTCat56Z7y3FgntEX0sFAl/7L0MQHHRlc3RAZG9p
cC5yb2NrcwAKCRDvLcWCe0RfS3iYC/0QQqz2lzSNrkApdIN9OJFfd/sP2qeGr/uH
98YHa+ucwBxer6yrAaTYYuBJg1uyzdxQhqF2jWno7FwN4crnj15AN5XGemjpmqat
py9wG6vCVjC81q/BWMIMZ7RJ/m8F8Kz556xHiU8KbqLNDqFVcT35/PhJsw71XVCI
N3HgrgD7CY/vIsZ3WIH7mne3q9O7X4TJQtFoZZ/l9lKj7qk3LrSFnL6q+JxUr2Im
xfYZKaSz6lmLf+vfPc59JuQtV1z0HSNDQkpKEjmLeIlc+ZNAdSQRjkfi+UDK7eKV
KGOlkcslroJO6rT3ruqx9L3hHtrM8dKQFgtRSaofB51HCyhNzmipbBHnLnKQrcf6
o8nn9OkP7F9NfbBE6xYIUCkgnv1lQbzeXsLLVuEKMW8bvZOmI7jTcthqnwzEIHj/
G4p+zPGgO+6Pzuhn47fxH+QZ0KPA8o2vx0DvOkZT6HEqG+EqpIoC/a7wD68n789c
K2NLCVb9oIGarPfhIdPV3QbrA5eXRRQ=
=QyNy
-----END PGP SIGNATURE-----

The "old" keyservers (the SKS pool) also host signatures, though those servers are obviously legacy and also operating in violation of GDPR

How are the old keyservers violating GDPR? In any case, I did not know the old keyservers hosted arbitrary signatures, interesting! The simple fact of hosting user-uploaded signatures does not violate the GDPR, right? Provided users can remove the signatures at will.

In the end, does switching to signatures but using them in a non-standard way constitue an improvement over using notations? I'm not sure.

Is this a non-standard way of using signatures? No, we're indeed not talking about signing keys but rather documents. I don't believe this to be non-standard. gpg --clearsign ./profile.txt is, I believe, the intended use of such functionality.

    yarmo Yes, we can bend signatures to our will by not signing keys but rather text documents. Currently, Keyoxide supports so-called signature profiles

    Ah, I'm sorry, looks like a terminology confusion. When you talked about switching from "notations" (which are inherently part of PGP keys) to "signatures", I assumed you meant signatures on PGP keys too. Now I see you meant the newly-introduced "signature profiles" which are signed text documents containing plaintext claims.

    So, my previous comments are largely irrelevant, but I have a new set of thoughts 😀

    • I think "signature profiles" is quite a confusing name, but I haven't thought of anything better 😄

    • Are you envisaging "signature profiles" eventually fully replacing claims embedded in PGP keys?
      Personally I think both methods have their pros and cons, but I do really like being able to embed claims in my PGP key directly.

    • A disadvantage of "signature profiles" (or advantage, depending on perspective / use case) is lack of discoverability. A PGP key (with claims embedded via notations) can be found by established means such as HKP and WKD. Not so for a "signature profile", which must be distributed manually.

    • It would be great to have an easy way to get a "signature profile" into Keyoxide (web and CLI) for verification, rather than having to copy and paste it. Maybe by providing a link to a text document hosted online? Maybe it would be possible to embed a (single?) claim and a signature in a link to keyoxide-web?

    On the (off-topic as it turns out) subject of the old keyservers hosting third-party key signatures:

    yarmo I did not know the old keyservers hosted arbitrary signatures, interesting

    I'm pretty sure they did, but it turns out (I hadn't realised) that the old SKS pool has actually been taken offline due to GDPR compliance issues. That said, some of the individual keyservers are still online, such as http://keyserver.ubuntu.com/.

    yarmo The simple fact of hosting user-uploaded signatures does not violate the GDPR, right? Provided users can remove the signatures at will.

    Well, firstly, I'm pretty sure it does, if the user didn't explicitly opt into that information being published in the first place. In fact, publishing the key at all is a violation if not authorised (for example, if someone else uploads my key), which is (partly) why keys.openpgp.org doesn't publish PII (name and email) on the keys unless verified. If someone uploads a new copy of my key that they have signed, and the keyserver publishes that, they're publishing information that identifies me as having a relationship with that person, without my authorisation.

    Secondly, I don't think most of the old keyservers do provide a way to remove your key. I don't see that option on http://keyserver.ubuntu.com/ for example.

            I think "signature profiles" is quite a confusing name, but I haven't thought of anything better

            Yeah, I'm definitely open to suggestions.

            Are you envisaging "signature profiles" eventually fully replacing claims embedded in PGP keys?

            Both methods have pros and cons and should co-exist. I imagine OpenPGP notations for the tech-savvy people and signature profiles (sigpros) for the more general population: quick profile creation, small keys using (for example) minisign, easy to replace keys if you happen to lose it.

            A disadvantage of "signature profiles" (or advantage, depending on perspective / use case) is lack of discoverability. A PGP key (with claims embedded via notations) can be found by established means such as HKP and WKD. Not so for a "signature profile", which must be distributed manually.

            It's a disadvantage now. But this is the issue I hope to fix the coming year. With a WKD-like protocol for signatures, it's about as easy as using your email address to discover sigpros. And personally, I really see a HKP-for-arbitrary-signatures happening. I will outline my ideas and requirements in a separate post.

            caesar It would be great to have an easy way to get a "signature profile" into Keyoxide (web and CLI) for verification

            This will happen with WKD-HKP-alternatives for signatures.

                caesar Well, firstly, I'm pretty sure it does, if the user didn't explicitly opt into that information being published in the first place. In fact, publishing the key at all is a violation if not authorised (for example, if someone else uploads my key), which is (partly) why keys.openpgp.org doesn't publish PII (name and email) on the keys unless verified. If someone uploads a new copy of my key that they have signed, and the keyserver publishes that, they're publishing information that identifies me as having a relationship with that person, without my authorisation.

                That's fragile. Help me out here: what if a bad actor created a new key with my own email address but with the name of someone else and for good measure, let's dox them by putting their target's home address as comment (despicable; do not try this at home) and uploaded the key to keys.openpgp.org.

                Obviously, this is a question I could/should ask on the Hagrid IRC channel. Might do that after this. But first, I am curious for your thoughts on this.

                What is keys.openpgp.org to do in this scenario? They are now in possession of PII of someone without their consent, but all their verification methods (ie email check) have validated the "correctness" of the data.

                I imagine one should contact keys.openpgp.org and request them to take down the key to comply with GDPR?

                    yarmo a WKD-like protocol for signatures

                    This sounds very interesting, I like it!

                    yarmo what if a bad actor created a new key with my own email address but with the name of someone else and for good measure, let's dox them by putting their target's home address as comment (despicable; do not try this at home) and uploaded the key to keys.openpgp.org.

                    Honestly, I don't know what would happen. keys.openpgp.org strips most fields where PII could be stored, but obviously misuse of the Name field would be possible, as would arbitrary data as Notations.

                    Obviously IANAL and I don't know how GDPR works here exactly – I do know that "accidentally" collected data is treated differently from data collected in the normal course of doing business, but I don't know much more. There's no obvious way to contact them (though if you look hard enough you can find a support email address hidden at the bottom of the Usage page).

                    Anyway, they're in a far better position than the SKS keyservers which outright refuse to remove data / to honour GDPR requests...