diff --git a/misc/id/openpgp-webkey-service/draft.org b/misc/id/openpgp-webkey-service/draft.org
index b5a4f08..fb0eb60 100644
--- a/misc/id/openpgp-webkey-service/draft.org
+++ b/misc/id/openpgp-webkey-service/draft.org
@@ -1,720 +1,720 @@
# openpgp-webkey-service
#+startup: showall
#+options: toc:nil
#+macro: RFC [](#RFC$1)
#+macro: https_scheme ~https://~
#+begin_src rfc
]>
OpenPGP Web Key Directory
- GnuPG Project
+ GnuPG e.V.
wk@gnupg.org
- https://gnupg.org
+ https://gnupg.org/verein
Security
&pandocAbstract;
&pandocMiddle;
&rfc.2119;
&rfc.2782;
&rfc.3156;
&rfc.4880;
&rfc.5785;
&rfc.6189;
&pandocBack;
#+end_src
* Abstract
This specification describes a service to locate OpenPGP keys by mail
address using a Web service and the HTTPS protocol. It also provides a
method for secure communication between the key owner and the mail
provider to publish and revoke the public key.
* Middle
* Introduction
This memo describes a method to associate OpenPGP keys with a mail
address and how to look them up using a web service with a well-known
URI. In addition a mail based protocol is given to allow a client to
setup such an association and to maintain it.
* Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in {{{RFC(2119)}}}.
* Web Key Directory
A major use case for OpenPGP is the encryption of mail. A common
difficulty of sending encrypted mails to a new communication partner is
to find the appropriate public key of the recipient. Unless an
off-channel key exchange has been done, there are no easy ways to
discover the required key. The common practice is to search the network
of public key servers for a key matching the recipient's mail address.
This practise bears the problem that the keyservers are not able to give
a positive confirmation that a key actually belongs to the mail
addresses given in the key. Further, there are often several keys
matching a mail address and thus one needs to pick a key on good luck.
This is clearly not a secure way to setup an end-to-end encryption. Even
if the need for a trusted key for an initial mail message is
relinquished, a non-authenticated key may be a wrong one and the actual
recipient would receive a mail which she can't decrypt, due to the use
of a wrong key.
Methods to overcome this problem are
- sending an initial unencrypted message with the public key attached,
- using the OpenPGP DANE protocol to lookup the recipients key via the
DNS.
The first method has the obvious problems of not even trying to encrypt
the initial mail, an extra mail round-trip, and problems with unattended
key discovery.
The latter method works fine but requires that mail providers need to
set up a separate DNS resolver to provide the key. The administration of
a DNS zone is often not in the hands of small mail installations. Thus
an update of the DNS resource records needs to be delegated to the ISP
running the DNS service. Further, DNS lookups are not encrypted and
missing all confidentially. Even if the participating MUAs are using
STARTTLS to encrypt the mail exchange, a DNS lookup for the key
unnecessarily identifies the local-part of the recipients mail address
to any passive eavesdroppers.
This memo specified a new method for key discovery using an encrypted
https connection.
** Key Discovery
Although URIs are able to encode all kind of characters, straightforward
implementations of a key directory may want to store the local-part of
a mail address directly in the file system. This forbids the use of
certain characters in the local-part. To allow for such an
implementation method the URI uses an encoded form of the local-part
which can be directly mapped to a file name.
OpenPGP defines its User IDs, and thus the mail address, as UTF-8
strings. To help with the common pattern of using capitalized names
(e.g. "Joe.Doe@example.org") for mail addresses, and under the premise
that almost all MTAs treat the local-part case-insensitive and that
the domain-part is required to be compared case-insensitive anyway,
all upper-case ASCII characters in a User ID are mapped to lowercase.
Non-ASCII characters are not changed.
The so mapped local-part is hashed using the SHA-1 algorithm. The
resulting 160 bit digest is encoded using the Z-Base-32 method as
described in {{{RFC(6189)}}}, section 5.1.6. The resulting string has
a fixed length of 32 octets. To form the URI, the following parts are
concatenated:
- The scheme {{{https_scheme}}},
- the domain-part,
- the string ~/.well-known/openpgpkey/hu/~,
- and the above constructed 32 octet string.
For example the URI to lookup the key for Joe.Doe@Example.ORG is:
#+BEGIN_EXAMPLE
https://example.org/.well-known/openpgpkey/
hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q
#+END_EXAMPLE
(line has been wrapped for rendering purposes)
DNS SRV resource records ({{{RFC(2782)}}}) may be used to query a
different host or a port other than 443. For example:
#+BEGIN_EXAMPLE
_openpgpkey._tcp.example.org. IN SRV 0 0 8443 wkd.example.org.
#+END_EXAMPLE
changes the above to query the host "wkd.example.org" at port
8443 instead of the host "example.org" at port 443. The target (in the
example "wkd.example.org") MUST be a sub-domain of the domain-part
(here "example.org"). If the target is not a sub-domain, the SRV RR
MUST be be ignored. The recommended name for the sub-domain is "wkd".
The HTTP GET method MUST return the binary representation of the
OpenPGP key for the given mail address. The key needs to carry a User
ID packet ({{{RFC(4880)}}}) with that mail address. Note that the key
may be revoked or expired - it is up to the client to handle such
conditions. To ease distribution of revoked keys, a server may return
revoked keys in addition to a new key. The keys are returned by a
single request as concatenated key blocks.
The server MUST accept the HTTP HEAD method to allow a client to
check for the existence of a key.
The server SHOULD use "application/octet-string" as the
Content-Type for the data but clients SHOULD also accept any other
Content-Type. The server MUST NOT return an ASCII armored version of
the key.
The server MUST serve a Policy Flags file as specified below. That
file is even required if the Web Key Directory Update Protocol is not
supported.
* Web Key Directory Update Protocol
To put keys into the key directory a protocol to automate the task is
desirable. The protocol defined here is entirely based on mail and
the assumption that a mail provider can securely deliver mail to the
INBOX of a user (e.g. an IMAP folder). Note that the same protocol
may also be used for submitting keys for use with OpenPGP DANE.
We assume that the user already created a key for her mail account
alice@example.org. To install the key at her provider's Web Key
Directory, she performs the following steps:
1. She retrieves a file which contains one line with the mail address
used to submit the key to the mail provider. The DNS SRV rules
described for the Web Key Directory apply here as well. See below
for the syntax of that file. For a mail address at the domain
"example.org" the URI of the file is
#+begin_example
https://example.org/.well-known/openpgpkey/submission-address
#+end_example
2. She sends her key using SMTP (or any other transport mechanism) to
the provider using the submission address and key format as specified
by PGP/MIME.
3. The provider checks that the received key has a User ID which matches
an account name of the provider.
4. The provider sends an encrypted message containing a nonce and the
fingerprint of the key to the mail account of the user. Note that a
similar scheme is used by the well known caff(1) tool to help with
key signing parties.
5. A legitimate user will be able to decrypt the message because she
created the key and is in charge of the private key. This step
verifies that the submitted key has actually been created by the
owner of the account.
6. The user sends the decrypted nonce back to the submission address
as a confirmation that the private key is owned by her and that the
provider may now publish the key. Although technically not
required, it is suggested that the mail to the provider is
encrypted. The public key for this is retrieved using the key
lookup protocol described above.
7. The provider receives the nonce, matches it with its database of
pending confirmations and then publishes the key. Finally the
provider sends a mail back to the user to notify her of the
publication of her key.
The message data structures used for the above protocol are specified in
detail below. In the following sections the string "WELLKNOWN" denotes
the first part of an URI specific for a domain. In the examples the
domain "example.org" is assumed, thus
#+BEGIN_EXAMPLE
WELLKNOWN := https://example.org/.well-known/openpgpkey
#+END_EXAMPLE
The term "target key" denotes the to be published key, the term
"submission key" the key associated with the submission-address of the
mail provider.
** The Submission Address
The address of the submission file is
#+BEGIN_EXAMPLE
WELLKNOWN/submission-address
#+END_EXAMPLE
The file consists of exactly one line, terminated by a LF, or the
sequence of CR and LF, with the full mail address to be used for
submission of a key to the mail provider. For example the content of the
file may be
#+BEGIN_EXAMPLE
key-submission-example.org@directory.example.org
#+END_EXAMPLE
** The Submission Mail
The mail used to submit a key to the mail provider MUST comply to the
PGP/MIME specification ({{{RFC(3156)}}}, section 7), which states that
the Content-Type must be "application/pgp-keys", there are no required
or optional parameters, and the body part contains the ASCII-armored
transferable Public Key Packets as defined in {{{RFC(4880)}}}, section
11.1.
The mail provider MUST publish a key capable of signing and encryption
for the submission-address in the Web Key Directory or via DANE. The
key to be published MUST be submitted using a PGP/MIME encrypted
message ({{{RFC(3156)}}}, section 4). The message MUST NOT be signed
(because the authenticity of the signing key has not yet been
confirmed). After decryption of the message at the mail provider a
single "application/pgp-keys" part, as specified above, is expected.
** The Confirmation Request
The mail provider sends a confirmation mail in response to a received
key publication request. The message MUST be sent from the
submission-address of the mail provider to the mail address extracted
from the target key. The message needs to be a PGP/MIME signed
message using the submission key of the provider for the
signature. The signed message MUST have two parts:
The first part MUST have "text" as its Content-Type and can be used to
explain the purpose of the mail. For example it may point to this RFC
and explain on how to manually perform the protocol.
The second part MUST have "application/vnd.gnupg.wkd" if the protocol
version of the server is 5 or later; without a known protocol version
or a version less than 5, "application/vnd.gnupg.wks" MUST be used as its
Content-Type and carry an OpenPGP encrypted message in ASCII Armor
format. The message MUST be encrypted to the target key and MUST NOT
be signed. After decryption a text file in the Web Key data format
must be yielded.
That data format consists of name-value pairs with one name-value pair
per LF or CR+LF terminated line. Empty lines are allowed and will be
ignored by the receiver. A colon is used to terminate a name.
In a confirmation request the following names MUST be send in the
specified order:
- type :: The value must be "confirmation-request".
- sender :: This is the mailbox the user is expected to sent the
confirmation response to. The value must match the
mailbox part of the "From:" address of this
request. Exactly one address MUST be given.
- address :: The value is the addr-spec part of the target key's
mail address. The value SHOULD match the addr-spec part
of the recipient's address. The value MUST be UTF-8
encoded as required for an OpenPGP User ID.
- fingerprint :: The value is the fingerprint of the target key. The
fingerprint is given in uppercase hex encoding
without any interleaving spaces.
- nonce :: The value is a string with a minimum length of 16 octets
and a maximum length of 64 octets. The string must
entirely be made up of random ASCII letters or
digits. This nonce will be sent back to the mail provider
as proof that the recipient is the legitimate owner of
the target-key.
The receiver of that message is expected to verify the outer signature
and disregard the entire message if it can't be verified or has not
been signed by the key associated with the submission address.
After the message as been verified the receiver decrypts the second part
of the message, checks that the "fingerprint" matches the target key,
checks that the "address" matches a User ID of the target key, and
checks the other constrains of the request format. If any constraint
is not asserted, or the fingerprint or User ID do not match the target
key, or there is no pending publication requests (i.e. a mail recently
sent o the submission address), the user MAY be notified about this
fake confirmation attempt.
In other cases the confirmation request is legitimate and the MUA
shall silently send a response as described in the next section.
The rationale for the outer signature used with this request is to
allow early detection of spam mails. This can be done prior to the
decryption step and avoids asking the user to enter a passphrase to
perform the decryption for a non-legitimate message. The use of a
simple encrypted attachment, instead of using PGP/MIME encryption, is
to convey the Content-Type of that attachment in the clear and also to
prevent automatic decryption of that attachment by PGP/MIME aware
clients. The MUA may in fact detect this confirmation request and
present a customized dialog for confirming that request.
** The Confirmation Response
A response to a confirmation request MUST only be send in the positive
case; there is no negative confirmation response. A mail service
provider is expected to cancel a pending key submission after a suitable
time without a confirmation. The mail service provider SHOULD NOT retry
the sending of a confirmation request after the first request has been
send successfully.
The user MUST send the confirmation response from her target mail
address to the "from" address of the confirmation request. The
message MUST be signed and encrypted using the PGP/MIME Combined
format ({{{RFC(3156)}}}, section 6.2). The signing key is the target
key and the encryption key is the key associated with the provider's
submission address.
The Content-Type used for the plaintext message MUST match the
Content-Type of the request. The format is the same as described
above for the Confirmation Request. The body must contain three
name-value pairs in this order:
- type :: The value must be "confirmation-response".
- sender :: The value must match the mailbox part of the "From:"
address of this response. Exactly one address MUST be
given.
- nonce :: The value is the value of the "nonce" parameter from the
confirmation request.
** Policy Flags
For key generation and submission it is useful to tell the
client about certain properties of the mail provider in advance. This
can be done with a file at the URL
#+BEGIN_EXAMPLE
WELLKNOWN/policy
#+END_EXAMPLE
A site supporting the Web Key Directory MUST serve this file; it is
sufficient if that file has a zero length. Clients may use this file
to check for Web Key Directory support.
The file contains keywords and optioanlly values, one per line with
each line terminated by a LF or the sequence of CR and LF. Empty lines
and lines starting with a '#' character are considered comment
lines. A keyword is made up of lowercase letters, digits, hyphens, or
dots. An underscore is allowed as a name space delimiters; see
below. The first character must be a letter. Keywords which are
defined to require a value are directly followed by a colon and then
after optional white space the value. Clients MUST use
case-insensitive matching for the keyword.
Currently defined keywords are:
- mailbox-only :: The mail server provider does only accept keys
with only a mailbox in the User ID. In particular
User IDs with a real name in addition to the
mailbox will be rejected as invalid.
- dane-only :: The mail server provider does not run a Web Key
Directory but only an OpenPGP DANE service. The Web
Key Directory Update protocol is used to update the
keys for the DANE service.
- auth-submit :: The submission of the mail to the server is done
using an authenticated connection. Thus the
submitted key will be published immediately without
any confirmation request.
- protocol-version :: This keyword can be used to explicitly claim the
support of a specific version of the Web Key Directory update protocol.
This is in general not needed but implementations may have
workarounds for providers which only support an old protocol
version. If these providers update to a newer version they
should add this keyword so that the implementation can disable
the workaround. The value is an integer corresponding to the
respective draft revision number.
# Fixme: Add a protocol-version value for the final RFC.
More keywords will be defined in updates to this I-D. There is no
registry except for this document. For experimental use of new
features or for provider specific settings, keywords MUST be prefixed
with a domain name and an underscore.
* Security Considerations
The use of SHA-1 for the mapping of the local-part to a fixed string
is not a security feature but merely used to map the local-part to a
fixed-sized string made from a well defined set of characters. It is not
intended to conceal information about a mail address.
The domain name part of the mail address is not part of the hash to
avoid problems with internationalized domain names. Instead a
separate URL is required for each domain name.
The use of DNS SRV records reduces the certainty that a mail address
belongs to a domain. For example an attacker may change the target to
a host in a sub-domain under their control and thus gain full control
over all keys. An implementation may want to weight the certainty of
a mapping different if it has been retrieved via a sub-domain and in
particular if a non-recommended name is used for the sub-domain.
* IANA Considerations
** Well-Known URI
IANA is requested to assign a well-known URI in the "Well-Known URIs"
registry as defined by {{{RFC(5785)}}}:
URI suffix: openpgpkey
Change controller: IETF
Specification document: This
* Acknowledgments
The author would like to acknowledge the help of the individuals who
kindly voiced their opinions on the GnuPG mailing lists, in particular,
the help of Bernhard Reiter and Guilhem Moulin.
* Back
* Sample Protocol Run
The following non-normative example can be used by implementors as
guidance.
Note that GnuPG version 2.1.12 supports the key discovery described in
version -00 of this document (auto-key-locate method "wkd"). Version
2.1.16 can run the protocol described in this document but is also able
to run the protocol version specified by -01. For backward
compatibility this example uses the Content-Type as required for
versions of this protocol prior to -04; if the client knows that the
server support -04 "vnd.gnupg.wkd" should be used.
** Sample Keys
This is the provider's submission key:
#+begin_example
-----BEGIN PGP PRIVATE KEY BLOCK-----
lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
HFAD
=Hnwd
-----END PGP PRIVATE KEY BLOCK-----
#+end_example
This is the target key to be published:
#+begin_example
-----BEGIN PGP PRIVATE KEY BLOCK-----
lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
TiFZBA==
=GHi7
-----END PGP PRIVATE KEY BLOCK-----
#+end_example
** Sample Messages
The first message triggeres the publication requests.
#+begin_example
From: patrice.lumumba@example.net
To: key-submission@example.net
Subject: Key publishing request
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="=-=01-e8k41e11ob31eefa36wo=-="
Date: Wed, 05 Oct 2016 10:15:51 +0000
--=-=01-e8k41e11ob31eefa36wo=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=01-e8k41e11ob31eefa36wo=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
iM7PY4fwAHo890Dx+Qlt
=WIhx
-----END PGP MESSAGE-----
--=-=01-e8k41e11ob31eefa36wo=-=--
#+end_example
The server decrypts this message to
#+begin_example
Content-Type: application/pgp-keys
-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
=qRfF
-----END PGP PUBLIC KEY BLOCK-----
#+end_example
and returns this confirmation request
#+begin_example
From: key-submission@example.net
To: patrice.lumumba@example.net
Subject: Confirm your key publication
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="=-=01-wrzqued738dfx4x97u7y=-="
Date: Wed, 05 Oct 2016 10:16:57 +0000
--=-=01-wrzqued738dfx4x97u7y=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=01-wrzqued738dfx4x97u7y=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
=Cdjh
-----END PGP MESSAGE-----
--=-=01-wrzqued738dfx4x97u7y=-=--
#+end_example
The client decrypts the attachment as
#+begin_example
Content-Type: application/vnd.gnupg.wks
Content-Transfer-Encoding: 8bit
type: confirmation-request
sender: key-submission@example.net
address: patrice.lumumba@example.net
fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
#+end_example
creates this response
#+begin_example
Content-Type: application/vnd.gnupg.wks
Content-Transfer-Encoding: 8bit
type: confirmation-response
sender: key-submission@example.net
address: patrice.lumumba@example.net
nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
#+end_example
and sends it encrypted to the server
#+begin_example
From: patrice.lumumba@example.net
To: key-submission@example.net
Subject: Key publication confirmation
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
Date: Wed, 05 Oct 2016 10:18:52 +0000
--=-=01-iacqg4og4pqz11a5cg1o=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=01-iacqg4og4pqz11a5cg1o=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
=7uve
-----END PGP MESSAGE-----
--=-=01-iacqg4og4pqz11a5cg1o=-=--
#+end_example
* Changes Since -04
- Change to Content-Type "vnd.gnupg.wkd" for servers announcing its
support.
- Require the existance of the Policy Flags file.
- Re-title this I-D to Web Key Directory.
diff --git a/web/index.org b/web/index.org
index ed21006..67400e2 100644
--- a/web/index.org
+++ b/web/index.org
@@ -1,266 +1,271 @@
#+TITLE: The GNU Privacy Guard
#+STARTUP: showall
#+SETUPFILE: "share/setup.inc"
#+GPGWEB-NEED-SWDB
* The GNU Privacy Guard
#+index: GnuPG
#+index: GPG
#+index: PGP
#+index: Gpg4win
GnuPG is a complete and free implementation of the OpenPGP standard as
defined by [[https://www.ietf.org/rfc/rfc4880.txt][RFC4880]] (also known as /PGP/). GnuPG allows to encrypt and
sign your data and communication, features a versatile key management
system as well as access modules for all kinds of public key
directories. GnuPG, also known as /GPG/, is a command line tool with
features for easy integration with other applications. A wealth of
[[file:software/frontends.html][frontend applications]] and [[file:software/libraries.html][libraries]] are available. GnuPG also
provides support for S/MIME and Secure Shell (ssh).
GnuPG is [[https://www.gnu.org/philosophy/free-sw.html][Free Software]] (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the
[[https://www.gnu.org/copyleft/gpl.html][GNU General Public License]] .
The current version of GnuPG is {{{gnupg22_ver}}}. See the [[file:download/index.org][download]]
page for other maintained versions.
[[https://www.gpg4win.org][Gpg4win]] is a Windows version of GnuPG featuring a context menu tool, a
crypto manager, and an Outlook plugin to send and receive standard
PGP/MIME mails. The current version of Gpg4win is {{{gpg4win_ver}}}.
* Reconquer your privacy
#+begin_quote
Arguing that you don't care about the right to privacy
because you have nothing to hide is no different from
saying you don't care about free speech because you have
nothing to say. \ndash\nbsp{}Edward\nbsp{}Snowden
#+end_quote
Using encryption helps to protect your privacy and the privacy of the
people you communicate with. Encryption makes life difficult for bulk
surveillance systems. GnuPG is one of the tools that Snowden used to
uncover the secrets of the NSA.
Please visit the [[https://emailselfdefense.fsf.org][Email Self-Defense]] site to learn how and why you
should use GnuPG for your electronic communication. If you need
printed leaflets check out [[https://fsfe.org/contribute/spreadtheword.html#gnupg-leaflet][FSFE’s GnuPG leaflet]].
* News
#+index: News
The latest blog entries:
#+begin_html
#+end_html
The latest release news:\\
([[file:news.org][all news]])
# For those of you who like reading world’s news with an RSS reader,
# GnuPG's latest news are available as [[http://feedvalidator.org/check.cgi?url%3Dhttps://www.gnupg.org/news.en.rss][RSS 2.0 compliant]] feed. Just
# point or paste the [[news.en.rss][RSS file]] into your aggregator.
+** GnuPG Made Easy 1.10.0 released (2017-12-12)
+
+[[file:software/gpgme/index.org][GPGME]] is a library that allows to add support for cryptography to a
+program. {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q4/000418.html][more]]}
+
** GnuPG 2.2.3 released (2017-11-21)
We are pleased to announce the availability of GnuPG version 2.2.3.
This is a maintenance release mainly fixing a bug on Windows. The
Windows installer [[https://gpg4win.org][Gpg4win]] 3.0.1 already includes this version of
GnuPG. {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q4/000417.html][more]]}
** GnuPG 2.2.2 released (2017-11-07)
We are pleased to announce the availability of GnuPG version 2.2.2.
This is a maintenance release fixing a few bugs. {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q4/000416.html][more]]}
** GnuPG 2.2.1 released (2017-09-19)
We are pleased to announce the availability of GnuPG version 2.2.1.
This is a maintenance release fixing a few minor bugs. {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000415.html][more]]}
** Libgcrypt 1.8.1 released (2017-08-31) :important:
We are pleased to announce the availability of [[file:software/libgcrypt/index.org][Libgcrypt]] version 1.8.1
and 1.7.9. These releases fix a local side-channel attack on
Curve25519 encryption dubbed "May the Fourth be With You"
[CVE-2017-0379]. Read {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000414.html][more]]}...
** GnuPG 2.2.0 released (2017-08-28)
The GnuPG team is pleased to announce the availability of a new
GnuPG release: version 2.2.0. Read {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000413.html][more]]} for details.
This release marks the start of a new long term support series to
replace the 2.0.x series which will reach end-of-life on 2017-12-31.
** GnuPG 2.1.23 released (2017-08-09)
A new version of GnuPG has been released. Please read the full
[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000412.html][announcement mail]] for details. This version is intended as a release
candidate for 2.2.0 which will mark a new long term stable branch.
** GnuPG 2.1.22 released (2017-07-28)
A new version of GnuPG has been released. Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000411.html][announcement
mail]] for details.
Update 2017-07-31: We fixed a problem with keyserver access in the
Windows versions. A fixed installer has been uploaded; the [[../../download/index.org::binary][download]]
section has the links.
** GnuPG 1.4.22 released (2017-07-19)
Although GnuPG 1.4 is of limited use today we did a maintenance
release to address the recently published local side channel attack
CVE-2017-7526. See the [[../../download/index.org][download]] section on how to get this version.
** Libgcrypt 1.8.0 released (2017-07-18)
We are pleased to announce the availability of [[file:software/libgcrypt/index.org][Libgcrypt]] version
1.8.0. This is a new stable version with full API and ABI
compatibility to the 1.7 series. Its main features are support for
the hash algorithm [[https://en.wikipedia.org/wiki/BLAKE_(hash_function)][Blake-2]], the addition of [[https://en.wikipedia.org/wiki/Disk_encryption_theory][XTS]] mode, an improved
random number generator, and performance improvements for the [[https://en.wikipedia.org/wiki/ARM_architecture][ARM]]
architecture. See the [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000410.html][announcement mail]] for details.
** Scute 1.5.0 released (2017-07-14)
Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG
Smart Card Daemon. It allows you to use your OpenPGP smart card for TLS
client authentication and S/MIME mail and document signing.
Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000409.html][announcement mail]] for details.
** Libgcrypt 1.7.8 released (2017-06-29) :important:
We are pleased to announce the availability of [[file:software/libgcrypt/index.org][Libgcrypt]] version
1.7.8. This release fixes a local side-channel attack
(CVE-2017-7526). See the [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000408.html][announcement mail]] for details.
** GnuPG 2.1.21 released (2017-05-15) :important:
A new version of GnuPG has been released. This release fixes a
pubring.gpg corruption bug introduced with 2.1.20. Read the full
[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000405.html][announcement mail]] for details.
** GnuPG 2.1.20 released (2017-04-03)
A new version of GnuPG has been released. Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000404.html][announcement
mail]] for details.
** New installer for GnuPG 2.1.19 (2017-03-28)
An updated Windows [[https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.19_20170328.exe][installer]] for GnuPG 2.1.19 is now available. This
installer fixes problems retrieving keys for [[https://posteo.de][Posteo]] accounts and other
servers with limited set of TLS algorithms.
** GnuPG Made Easy 1.9.0 released (2017-03-28)
[[file:software/gpgme/index.org][GPGME]] is a library that allows to add support for cryptography to a
program. {[[https://lists.gnupg.org/pipermail/gnupg-announce/2017q1/000403.html][more]]}
** GnuPG 2.1.19 released (2017-03-01)
A new version of GnuPG has been released. Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q1/000402.html][announcement
mail]] for details.
** GnuPG 2.1.18 released (2017-01-23)
A new version of GnuPG has been released. Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2017q1/000401.html][announcement
mail]] for details.
** Libgcrypt 1.7.6 released (2017-01-18)
We are pleased to announce the availability of Libgcrypt version
1.7.6. This is a maintenance release for the stable version of
[[file:software/libgcrypt/index.org][Libgcrypt]] with a few bug fixes.
** GnuPG 2.1.17 released (2016-12-20)
A new version of GnuPG has been released. Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2016q4/000400.html][announcement
mail]] for details.
** Libgcrypt 1.7.5 released (2016-12-15)
We are pleased to announce the availability of Libgcrypt version
1.7.5. This is a maintenance release for the stable version of
[[file:software/libgcrypt/index.org][Libgcrypt]] with a few bug fixes. [[https://lists.gnupg.org/pipermail/gnupg-announce/2016q4/000399.html][{more}]]
** Pinentry 1.0.0 released (2016-11-22)
After 14 years is was time to bump up the version of [[file:software/pinentry/index.org][Pinentry]] to 1.0.
This new release fixes a couple of minor bugs and introduces features
to better diagnose problems. See the [[../../download/index.org::pinentry][download]] section on how to get
Pinentry.
** GPA 0.9.10 released (2016-11-19)
A maintenance release of the [[file:software/gpa/index.org][GNU Privacy Assistant]] is now available.
Note that some of the changes are only available when build with the
latest [[file:software/gpgme/index.org][GPGME]] version and used with GnuPG 2.1.16 or later.
** GnuPG 2.1.16 released (2016-11-18)
It has been 3 months since the last GnuPG /modern/ release and thus it
was time for a new one: Version 2.1.16 is now available. Read the
full [[https://lists.gnupg.org/pipermail/gnupg-announce/2016q4/000398.html][announcement mail]] for details.
** GnuPG Made Easy (GPGME) 1.7.0 released (2016-09-21)
[[file:software/gpgme/index.org][GPGME]] is a library that allows to add support for cryptography to a
program. Highlights in this release are Python and C++ language
bindings as well as support for GnuPG 2.1 features. {[[https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000397.html][more]]}
** GnuPG 2.1.15 released (2016-08-18)
A new version of the /modern/ branch of GnuPG has been released.
Read the full [[https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000396.html][announcement mail]] for details.
** Security fixes for Libgcrypt and GnuPG 1.4 (2016-08-17) :important:
A bug in the random number generator of Libgcrypt and in GnuPG 1.4 has
been found. Updating the software is highly suggested. Please read
this [[https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html][mail]] for details. Note that the CVE id in that mail is not
correct, the correct one is CVE-2016-6313.
* A big Thanks to all supporters
Due to this [[http://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke][ProPublica article]] we received more than 120,000 \euro of
individual donations on a single day. There was even more: The [[https://www.linuxfoundation.org/programs/core-infrastructure-initiative][Core
Infrastructure Initiative]] granted 60,000 $ for 2015. Our payment
service [[https://twitter.com/stripe/status/563449352635432960][Stripe]] and [[https://www.facebook.com/notes/protect-the-graph/supporting-gnu-privacy-guard/1564591893780956][Facebook]] will each give 50,000 $ to the project.
And finally the [[https://www.wauland.de/en/donation.html#61][Wau Holland Stiftung]] is collecting tax deductible
funds for GnuPG (19000 \euro plus 57 BTC).
As the main author of GnuPG, I like to thank everyone for supporting
the project, be it small or large individual donations, helping users,
providing corporate sponsorship, working on the software, and for all
the encouraging words.
GnuPG does not stand alone: there are many other projects, often
unknown to most people, which are essential to keep the free Internet
running. Many of them are run by volunteers who spend a lot of unpaid
time on them. They need our support as well.
/--- Werner, 2015-02-06/
(see also this [[https://gnupg.org/blog/20150310-gnupg-in-february.html][blog]] entry)
* COMMENT
This is the publishing info used for the GnuPG pages
#+begin_src emacs-lisp
(progn
(setq gpgweb-root-dir (file-name-directory (buffer-file-name)))
(setq gpgweb-stage-dir (concat gpgweb-root-dir "../stage"))
(require 'gpgweb (concat gpgweb-root-dir "share/gpgweb.el"))
(setq org-publish-use-timestamps-flag nil)
(setq org-export-html-toplevel-hlevel 1)
(setq org-export-html-coding-system 'utf-8)
(gpgweb-setup-project))
#+end_src