What is the purpose of the --sig-notation and --cert-notation options in GnuPG? What are the intended use cases?
In the first part the a @ character is used, so I guess the options are for providing certain e-mail addresses. But which email address should be given?
Notations provide meanings to add information to a signature or certification (which also is a special kind of signature). From RFC 4880, 5.2.3.16. Notation Data:
This subpacket describes a "notation" on the signature that the issuer wishes to make. The notation has a name and a value, each of which are strings of octets. There may be more than one notation in a signature. Notations can be used for any extension the issuer of the signature cares to make. [...]
Notations are rarely used in practice (actually I've never seen real usage, although there are few notation subpackets to be found in key server dumps). Example usage might be to add the location of an identity check during key signing, or the document types presented.
Each notation consists of a notation name and a value, while the value is an arbitrary UTF-8 encoded string.
Regarding the @, this is part of the notation namespaces. Namespaces help to distinguish notations if they use the same name, but are defined by different people. Again from the same section of the RFC:
Notation names are arbitrary strings encoded in UTF-8. They reside in two namespaces: The IETF namespace and the user namespace.
The IETF namespace is registered with IANA. These names MUST NOT contain the "@" character (0x40). This is a tag for the user namespace.
Names in the user namespace consist of a UTF-8 string tag followed by "@" followed by a DNS domain name. Note that the tag MUST NOT contain an "@" character. For example, the "sample" tag used by Example Corporation could be "[email protected]".
Names in a user space are owned and controlled by the owners of that domain. Obviously, it's bad form to create a new name in a DNS space that you don't own.
Since the user namespace is in the form of an email address, implementers MAY wish to arrange for that address to reach a person who can be consulted about the use of the named tag. Note that due to UTF-8 encoding, not all valid user space name tags are valid email addresses.
With other words, there can be official notations in the form of some-notation-name defined by a standard and registered with the IANA. On the other hand, everybody can declare his own notations, which should have the form [email protected]. For example, if I would use [email protected], it would not collide with the (assumed) official notation some-notation-name in the IANA namespace.
A (relatively) new project, Keyoxide, uses signature notations as the basis for making claims that a particular GPG keypair/identity/certificate (not sure on the precise nomenclature/jargon here) is the owner of other particular identities, usually ones across the web. The name data of the signature notation, in Keyoxide's case, is "[email protected]" (since this is in the form of an email address, it is in the "user namespace" that Jens Erat is mentioning, rather than the IANA namespace); and the value data of the signature notation is typically a URL to the claimed web identity/persona (a profile page on Mastodon, a specific Tweet for a twitter user, etc). The URL should ultimately contain a proof of some sort that links back to the GPG keypair.
Basically, the signature notations in a GPG keypair claim identities, and the identities have proofs linking back to the GPG keypair. Keyoxide refers to this as bidirectional linking. Keyoxide instances or clients (I believe instances and clients are interchangeable terms here) can then be used to automate checking this bidirectional link to validate claims and proofs, with specific details of validation performed by the instances/clients (check the HTML of a webpage for a proof, check a TXT DNS record of a domain for a proof, etc).
As an example, my Keyoxide profile shows several claims, one of which is that I am @[email protected]. That's a Mastodon instance which uses the ActivityPub protocol, so the Keyoxide profile webpage shows the claim as an activitypub entry with [email protected] identifying the particular user and domain.
If you want to look at the claim inside the GPG keypair itself, you can do that too (I'm paring down the results here, so if you run this in the future you might want to take off the grep and just dig through the STDOUT of --list-packets (and keys.openpgp.org might not exist in the future either)):
$ curl -s "https://keys.openpgp.org/pks/lookup?op=get&options=mr&search=0x79895B2E0F87503F1DDE80B649765D7F0DDD9BD5" \ | gpg --list-packets \ | grep '# off=571' -A 24 # off=571 ctb=c2 tag=2 hlen=3 plen=1462 new-ctb :signature packet: algo 1, keyid 49765D7F0DDD9BD5 version 4, created 1665101949, md5len 0, sigclass 0x13 digest algo 10, begin of digest 34 16 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3) hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11) hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) hashed subpkt 9 len 4 (key expires after 8y23d12h45m) hashed subpkt 33 len 21 (issuer fpr v4 79895B2E0F87503F1DDE80B649765D7F0DDD9BD5) hashed subpkt 2 len 4 (sig created 2022-10-07) hashed subpkt 20 len 78 (notation: [email protected]=https://stackoverflow.com/users/2329707/preston-maness) hashed subpkt 20 len 61 (notation: [email protected]=https://octodon.social/@aspensmonster) hashed subpkt 20 len 54 (notation: [email protected]=dns:aspensmonster.com?type=TXT) hashed subpkt 20 len 109 (notation: [email protected]=https://www.reddit.com/user/aspensmonster/comments/ug8t4n/keyoxide_verification_post/) hashed subpkt 20 len 57 (notation: [email protected]=https://lobste.rs/u/aspensmonster) hashed subpkt 20 len 92 (notation: [email protected]=https://gist.github.com/aggroskater/7c1feac1cf55445b54acacf03493a642) hashed subpkt 20 len 74 (notation: [email protected]=https://news.ycombinator.com/user?id=aspensmonster) hashed subpkt 20 len 164 (notation: [email protected]=matrix:u/@aspensmonster:matrix.org?org.keyoxide.r=!dBfQZxCoGVmSTujfiv:matrix.org&org.keyoxide.e=$QFhkNvaoXVli1amBgcfbxkleDynMW4ModXdBy2DpHCg) hashed subpkt 20 len 84 (notation: [email protected]=https://twitter.com/aspensmonster/status/1520864883306385408) hashed subpkt 20 len 73 (notation: [email protected]=https://superuser.com/users/220550/preston-maness) subpkt 16 len 8 (issuer key ID 49765D7F0DDD9BD5) data: [4094 bits] The relevant bit here is
(notation: [email protected]=https://octodon.social/@aspensmonster) So, my GPG keypair 0x79895B2E0F87503F1DDE80B649765D7F0DDD9BD5 has a claim, signed by the private key associated with that keypair, that I am @[email protected].
A keyoxide client will then validate that claim by visiting the page and noticing that, in my bio, there exists a link back to https://keyoxide.org/79895B2E0F87503F1DDE80B649765D7F0DDD9BD5. Only someone with access to the profile can add that link referencing the keypair, and only someone with the private key of the keypair can make the initial claim. The claim now has a validated proof and we can be reasonably sure that the owner of the keypair is also the owner of that mastodon user and that they are the same person.
When you have multiple such bidirectional claims with proofs, you effectively establish a decentralized online identity that is independent of particular usernames, accounts, and environments. A link to one is a link to all.
