Difference between revisions of "PGP"

From Organic Design
(See also: IndieWeb)
m (Decentralised proofs)
Line 64: Line 64:
  
 
== Decentralised proofs ==
 
== Decentralised proofs ==
todo... [https://metacode.biz/openpgp/proofs decentralised proofs]
+
todo... [https://metacode.biz/openpgp/proofs decentralised proofs] and [https://github.com/wiktor-k/openpgp-proofs openpgp-proofs]
  
 
<pre>
 
<pre>

Revision as of 11:56, 22 February 2020

PGP (Pretty Good Privacy) is actually the name of the original encryption program that provides cryptographic privacy and authentication for data communication and was developed by Phil Zimmermann in 1991. But these days PGP more commonly refers to the open internet standards which encapsulate this original functionality, OpenPGP and GNU Privacy Guard (GPG). In this article we refer exclusively to using PGP functionality via GPG.

Keys and fingerprints

todo... openpgp4fpr URI scheme

Key servers

todo... HKP

Web Key Directories

Web Key Directories (WKD) provide an easy way to discover public keys through HTTPS. They provide an important piece to the infrastructure to improve the user experience for exchanging secure emails and files. In contrast to the public keyservers a Web Key Directory does not publish mail addresses. And it is an authoritative pubkey source for its domain. Following are some basic instructions on how to get WKD up and running based on this metacode.biz guide.

GPG allows a unique hash to be generated for an email address, for example the address foo@example.com is associated with the hash 4hg7tescntgcqaqebqanpuyfu975. This hash is then used as the filename of a file containing encrypted data of your PGP keys that is generated using your private key and served from a specific location within your email domain (example.org in the example).

There are two location formats under the domain that the file can be located, the first is:

https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/4hg7tescntgcqaqebqanpuyfu975

and

https://example.org/.well-known/openpgpkey/hu/4hg7tescntgcqaqebqanpuyfu975

The first format is tried first and if there is no such domain, then the second format is tried as a fall-back. But note that if the domain for the first method resolves (which will be the case if you have a wildcard domain), then the key must be available at the first URL format otherwise some WKD clients (such as gpg itself) will fail to look the key up. My preferred method is to server the key from both locations.


To obtain the hash for your email address, do the following gpg command from any host that has your private key on it, for example:

gpg --list-keys --with-wkd foo@example.org
pub   rsa2048/0x6BA55ED83ABAE1BB 2018-05-08 [SC] [expires: 2020-05-07]
      Key fingerprint = 74EC 8D3D A82A 79DA A25D  F10C 6BA5 5ED8 3ABA E1BB
uid                   [ultimate] Example Key <foo@example.org>
                      4hg7tescntgcqaqebqanpuyfu975@example.org
sub   rsa2048/0x3B5E7761615E2207 2018-05-08 [E] [expires: 2020-05-07]


Next you need to export your key to a file that uses that hash as its name:

gpg --export foo@example.org > 4hg7tescntgcqaqebqanpuyfu975


You then upload the generated file to your web-server ensuring that it is available under both URLs without any errors. Note that you must make sure that a CORS header is served along with the key:

add_header Access-Control-Allow-Origin * always;


To test that your key is available go to another machine that has gpg installed and has never seen your key and try locating it:

gpg --locate-key foo@example.org
gpg: key 6BA55ED83ABAE1BB: public key "Example Key <foo@example.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
uid [ unknown] foo@example.org
sub   rsa2048 2020-01-23 [E]

Decentralised proofs

todo... decentralised proofs and openpgp-proofs

--sig-notation {name=value}
--cert-notation {name=value}
-N, --set-notation {name=value}

    Put the name value pair into the signature as notation data. name must consist only of printable characters or spaces, and must contain a ’@’ character in the form keyname@domain.example.com (substituting the appropriate keyname and domain name, of course). This is to help prevent pollution of the IETF reserved notation namespace. The --expert flag overrides the ’@’ check. value may be any printable string; it will be encoded in UTF-8, so you should check that your --display-charset is set correctly. If you prefix name with an exclamation mark (!), the notation data will be flagged as critical (rfc4880:5.2.3.16). --sig-notation sets a notation for data signatures. --cert-notation sets a notation for key signatures (certifications). --set-notation sets both.

    There are special codes that may be used in notation names. "%k" will be expanded into the key ID of the key being signed, "%K" into the long key ID of the key being signed, "%f" into the fingerprint of the key being signed, "%s" into the key ID of the key making the signature, "%S" into the long key ID of the key making the signature, "%g" into the fingerprint of the key making the signature (which might be a subkey), "%p" into the fingerprint of the primary key of the key making the signature, "%c" into the signature count from the OpenPGP smartcard, and "%%" results in a single "%". %k, %K, and %f are only meaningful when making a key signature (certification), and %c is only meaningful when using the OpenPGP smartcard.

See also