web: gpgme 1.10 announcement
[gnupg-doc.git] / misc / id / openpgp-webkey-service / draft.org
1 # openpgp-webkey-service
2 #+startup: showall
3 #+options: toc:nil
4 #+macro: RFC  [](#RFC$1)
5 #+macro: https_scheme ~https://~
6
7 #+begin_src rfc
8 <?xml version="1.0" ?>
9 <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
10   <!ENTITY pandocAbstract PUBLIC '' 'tmp-abstract.xml'>
11   <!ENTITY pandocMiddle   PUBLIC '' 'tmp-middle.xml'>
12   <!ENTITY pandocBack     PUBLIC '' 'tmp-back.xml'>
13   <!ENTITY rfc.2119       PUBLIC '' '../common/reference.RFC.2119.xml'>
14   <!ENTITY rfc.2782       PUBLIC '' '../common/reference.RFC.2782.xml'>
15   <!ENTITY rfc.3156       PUBLIC '' '../common/reference.RFC.3156.xml'>
16   <!ENTITY rfc.4880       PUBLIC '' '../common/reference.RFC.4880.xml'>
17   <!ENTITY rfc.5226       PUBLIC '' '../common/reference.RFC.5226.xml'>
18   <!ENTITY rfc.5785       PUBLIC '' '../common/reference.RFC.5785.xml'>
19   <!ENTITY rfc.6189       PUBLIC '' '../common/reference.RFC.6189.xml'>
20 ]>
21
22 <rfc ipr="trust200902" category="info"
23      docName="draft-koch-openpgp-webkey-service-05">
24
25 <?rfc toc="yes"?>
26 <?rfc symrefs="yes"?>
27 <?rfc sortrefs="yes"?>
28 <?rfc subcompact="no"?>
29 <?rfc compact="yes"?>
30 <?rfc comments="yes"?>
31
32   <front>
33     <title>OpenPGP Web Key Directory</title>
34     <author initials="W." surname="Koch"
35             fullname="Werner Koch">
36       <organization>GnuPG e.V.</organization>
37       <address>
38         <email>wk@gnupg.org</email>
39         <uri>https://gnupg.org/verein</uri>
40       </address>
41     </author>
42
43     <date month="November" year="2017" />
44     <area>Security</area>
45
46     <abstract>
47       &pandocAbstract;
48     </abstract>
49   </front>
50
51   <middle>
52     &pandocMiddle;
53   </middle>
54
55   <back>
56     <references title="Normative References">
57       &rfc.2119;
58       &rfc.2782;
59       &rfc.3156;
60       &rfc.4880;
61       &rfc.5785;
62       &rfc.6189;
63     </references>
64     &pandocBack;
65   </back>
66 </rfc>
67 #+end_src
68
69 * Abstract
70
71 This specification describes a service to locate OpenPGP keys by mail
72 address using a Web service and the HTTPS protocol.  It also provides a
73 method for secure communication between the key owner and the mail
74 provider to publish and revoke the public key.
75
76 * Middle
77
78 * Introduction
79
80 This memo describes a method to associate OpenPGP keys with a mail
81 address and how to look them up using a web service with a well-known
82 URI.  In addition a mail based protocol is given to allow a client to
83 setup such an association and to maintain it.
84
85 * Notational Conventions
86
87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
89 document are to be interpreted as described in {{{RFC(2119)}}}.
90
91
92 * Web Key Directory
93
94 A major use case for OpenPGP is the encryption of mail.  A common
95 difficulty of sending encrypted mails to a new communication partner is
96 to find the appropriate public key of the recipient.  Unless an
97 off-channel key exchange has been done, there are no easy ways to
98 discover the required key.  The common practice is to search the network
99 of public key servers for a key matching the recipient's mail address.
100 This practise bears the problem that the keyservers are not able to give
101 a positive confirmation that a key actually belongs to the mail
102 addresses given in the key.  Further, there are often several keys
103 matching a mail address and thus one needs to pick a key on good luck.
104 This is clearly not a secure way to setup an end-to-end encryption.  Even
105 if the need for a trusted key for an initial mail message is
106 relinquished, a non-authenticated key may be a wrong one and the actual
107 recipient would receive a mail which she can't decrypt, due to the use
108 of a wrong key.
109
110 Methods to overcome this problem are
111
112 -  sending an initial unencrypted message with the public key attached,
113 -  using the OpenPGP DANE protocol to lookup the recipients key via the
114    DNS.
115
116 The first method has the obvious problems of not even trying to encrypt
117 the initial mail, an extra mail round-trip, and problems with unattended
118 key discovery.
119
120 The latter method works fine but requires that mail providers need to
121 set up a separate DNS resolver to provide the key.  The administration of
122 a DNS zone is often not in the hands of small mail installations.  Thus
123 an update of the DNS resource records needs to be delegated to the ISP
124 running the DNS service.  Further, DNS lookups are not encrypted and
125 missing all confidentially.  Even if the participating MUAs are using
126 STARTTLS to encrypt the mail exchange, a DNS lookup for the key
127 unnecessarily identifies the local-part of the recipients mail address
128 to any passive eavesdroppers.
129
130 This memo specified a new method for key discovery using an encrypted
131 https connection.
132
133 ** Key Discovery
134
135 Although URIs are able to encode all kind of characters, straightforward
136 implementations of a key directory may want to store the local-part of
137 a mail address directly in the file system.  This forbids the use of
138 certain characters in the local-part.  To allow for such an
139 implementation method the URI uses an encoded form of the local-part
140 which can be directly mapped to a file name.
141
142 OpenPGP defines its User IDs, and thus the mail address, as UTF-8
143 strings.  To help with the common pattern of using capitalized names
144 (e.g. "Joe.Doe@example.org") for mail addresses, and under the premise
145 that almost all MTAs treat the local-part case-insensitive and that
146 the domain-part is required to be compared case-insensitive anyway,
147 all upper-case ASCII characters in a User ID are mapped to lowercase.
148 Non-ASCII characters are not changed.
149
150 The so mapped local-part is hashed using the SHA-1 algorithm.  The
151 resulting 160 bit digest is encoded using the Z-Base-32 method as
152 described in {{{RFC(6189)}}}, section 5.1.6.  The resulting string has
153 a fixed length of 32 octets.  To form the URI, the following parts are
154 concatenated:
155
156 - The scheme {{{https_scheme}}},
157 - the domain-part,
158 - the string ~/.well-known/openpgpkey/hu/~,
159 - and the above constructed 32 octet string.
160
161 For example the URI to lookup the key for Joe.Doe@Example.ORG is:
162
163 #+BEGIN_EXAMPLE
164          https://example.org/.well-known/openpgpkey/
165          hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q
166 #+END_EXAMPLE
167
168 (line has been wrapped for rendering purposes)
169
170 DNS SRV resource records ({{{RFC(2782)}}}) may be used to query a
171 different host or a port other than 443.  For example:
172
173 #+BEGIN_EXAMPLE
174 _openpgpkey._tcp.example.org.  IN  SRV 0 0 8443 wkd.example.org.
175 #+END_EXAMPLE
176
177 changes the above to query the host "wkd.example.org" at port
178 8443 instead of the host "example.org" at port 443.  The target (in the
179 example "wkd.example.org") MUST be a sub-domain of the domain-part
180 (here "example.org").  If the target is not a sub-domain, the SRV RR
181 MUST be be ignored.  The recommended name for the sub-domain is "wkd".
182
183 The HTTP GET method MUST return the binary representation of the
184 OpenPGP key for the given mail address.  The key needs to carry a User
185 ID packet ({{{RFC(4880)}}}) with that mail address.  Note that the key
186 may be revoked or expired - it is up to the client to handle such
187 conditions.  To ease distribution of revoked keys, a server may return
188 revoked keys in addition to a new key.  The keys are returned by a
189 single request as concatenated key blocks.
190
191 The server MUST accept the HTTP HEAD method to allow a client to
192 check for the existence of a key.
193
194 The server SHOULD use "application/octet-string" as the
195 Content-Type for the data but clients SHOULD also accept any other
196 Content-Type.  The server MUST NOT return an ASCII armored version of
197 the key.
198
199 The server MUST serve a Policy Flags file as specified below.  That
200 file is even required if the Web Key Directory Update Protocol is not
201 supported.
202
203
204 * Web Key Directory Update Protocol
205
206 To put keys into the key directory a protocol to automate the task is
207 desirable.  The protocol defined here is entirely based on mail and
208 the assumption that a mail provider can securely deliver mail to the
209 INBOX of a user (e.g. an IMAP folder).  Note that the same protocol
210 may also be used for submitting keys for use with OpenPGP DANE.
211
212 We assume that the user already created a key for her mail account
213 alice@example.org.  To install the key at her provider's Web Key
214 Directory, she performs the following steps:
215
216 1. She retrieves a file which contains one line with the mail address
217    used to submit the key to the mail provider. The DNS SRV rules
218    described for the Web Key Directory apply here as well.  See below
219    for the syntax of that file.  For a mail address at the domain
220    "example.org" the URI of the file is
221 #+begin_example
222      https://example.org/.well-known/openpgpkey/submission-address
223 #+end_example
224
225 2. She sends her key using SMTP (or any other transport mechanism) to
226    the provider using the submission address and key format as specified
227    by PGP/MIME.
228
229 3. The provider checks that the received key has a User ID which matches
230    an account name of the provider.
231
232 4. The provider sends an encrypted message containing a nonce and the
233    fingerprint of the key to the mail account of the user.  Note that a
234    similar scheme is used by the well known caff(1) tool to help with
235    key signing parties.
236
237 5. A legitimate user will be able to decrypt the message because she
238    created the key and is in charge of the private key.  This step
239    verifies that the submitted key has actually been created by the
240    owner of the account.
241
242 6. The user sends the decrypted nonce back to the submission address
243    as a confirmation that the private key is owned by her and that the
244    provider may now publish the key.  Although technically not
245    required, it is suggested that the mail to the provider is
246    encrypted.  The public key for this is retrieved using the key
247    lookup protocol described above.
248
249 7. The provider receives the nonce, matches it with its database of
250    pending confirmations and then publishes the key.  Finally the
251    provider sends a mail back to the user to notify her of the
252    publication of her key.
253
254 The message data structures used for the above protocol are specified in
255 detail below.  In the following sections the string "WELLKNOWN" denotes
256 the first part of an URI specific for a domain.  In the examples the
257 domain "example.org" is assumed, thus
258
259 #+BEGIN_EXAMPLE
260       WELLKNOWN := https://example.org/.well-known/openpgpkey
261 #+END_EXAMPLE
262
263 The term "target key" denotes the to be published key, the term
264 "submission key" the key associated with the submission-address of the
265 mail provider.
266
267 ** The Submission Address
268
269 The address of the submission file is
270
271 #+BEGIN_EXAMPLE
272       WELLKNOWN/submission-address
273 #+END_EXAMPLE
274
275 The file consists of exactly one line, terminated by a LF, or the
276 sequence of CR and LF, with the full mail address to be used for
277 submission of a key to the mail provider.  For example the content of the
278 file may be
279
280 #+BEGIN_EXAMPLE
281       key-submission-example.org@directory.example.org
282 #+END_EXAMPLE
283
284 ** The Submission Mail
285
286 The mail used to submit a key to the mail provider MUST comply to the
287 PGP/MIME specification ({{{RFC(3156)}}}, section 7), which states that
288 the Content-Type must be "application/pgp-keys", there are no required
289 or optional parameters, and the body part contains the ASCII-armored
290 transferable Public Key Packets as defined in {{{RFC(4880)}}}, section
291 11.1.
292
293 The mail provider MUST publish a key capable of signing and encryption
294 for the submission-address in the Web Key Directory or via DANE.  The
295 key to be published MUST be submitted using a PGP/MIME encrypted
296 message ({{{RFC(3156)}}}, section 4).  The message MUST NOT be signed
297 (because the authenticity of the signing key has not yet been
298 confirmed).  After decryption of the message at the mail provider a
299 single "application/pgp-keys" part, as specified above, is expected.
300
301 ** The Confirmation Request
302
303 The mail provider sends a confirmation mail in response to a received
304 key publication request.  The message MUST be sent from the
305 submission-address of the mail provider to the mail address extracted
306 from the target key.  The message needs to be a PGP/MIME signed
307 message using the submission key of the provider for the
308 signature.  The signed message MUST have two parts:
309
310 The first part MUST have "text" as its Content-Type and can be used to
311 explain the purpose of the mail.  For example it may point to this RFC
312 and explain on how to manually perform the protocol.
313
314 The second part MUST have "application/vnd.gnupg.wkd" if the protocol
315 version of the server is 5 or later; without a known protocol version
316 or a version less than 5, "application/vnd.gnupg.wks" MUST be used as its
317 Content-Type and carry an OpenPGP encrypted message in ASCII Armor
318 format.  The message MUST be encrypted to the target key and MUST NOT
319 be signed.  After decryption a text file in the Web Key data format
320 must be yielded.
321
322 That data format consists of name-value pairs with one name-value pair
323 per LF or CR+LF terminated line.  Empty lines are allowed and will be
324 ignored by the receiver.  A colon is used to terminate a name.
325
326 In a confirmation request the following names MUST be send in the
327 specified order:
328
329 - type :: The value must be "confirmation-request".
330
331 - sender :: This is the mailbox the user is expected to sent the
332             confirmation response to.  The value must match the
333             mailbox part of the "From:" address of this
334             request.  Exactly one address MUST be given.
335
336 - address :: The value is the addr-spec part of the target key's
337              mail address.  The value SHOULD match the addr-spec part
338              of the recipient's address.  The value MUST be UTF-8
339              encoded as required for an OpenPGP User ID.
340
341 - fingerprint :: The value is the fingerprint of the target key.  The
342                  fingerprint is given in uppercase hex encoding
343                  without any interleaving spaces.
344
345 - nonce :: The value is a string with a minimum length of 16 octets
346            and a maximum length of 64 octets.  The string must
347            entirely be made up of random ASCII letters or
348            digits.  This nonce will be sent back to the mail provider
349            as proof that the recipient is the legitimate owner of
350            the target-key.
351
352 The receiver of that message is expected to verify the outer signature
353 and disregard the entire message if it can't be verified or has not
354 been signed by the key associated with the submission address.
355
356 After the message as been verified the receiver decrypts the second part
357 of the message, checks that the "fingerprint" matches the target key,
358 checks that the "address" matches a User ID of the target key, and
359 checks the other constrains of the request format.  If any constraint
360 is not asserted, or the fingerprint or User ID do not match the target
361 key, or there is no pending publication requests (i.e. a mail recently
362 sent o the submission address), the user MAY be notified about this
363 fake confirmation attempt.
364
365 In other cases the confirmation request is legitimate and the MUA
366 shall silently send a response as described in the next section.
367
368 The rationale for the outer signature used with this request is to
369 allow early detection of spam mails.  This can be done prior to the
370 decryption step and avoids asking the user to enter a passphrase to
371 perform the decryption for a non-legitimate message.  The use of a
372 simple encrypted attachment, instead of using PGP/MIME encryption, is
373 to convey the Content-Type of that attachment in the clear and also to
374 prevent automatic decryption of that attachment by PGP/MIME aware
375 clients.  The MUA may in fact detect this confirmation request and
376 present a customized dialog for confirming that request.
377
378
379 ** The Confirmation Response
380
381 A response to a confirmation request MUST only be send in the positive
382 case; there is no negative confirmation response.  A mail service
383 provider is expected to cancel a pending key submission after a suitable
384 time without a confirmation.  The mail service provider SHOULD NOT retry
385 the sending of a confirmation request after the first request has been
386 send successfully.
387
388 The user MUST send the confirmation response from her target mail
389 address to the "from" address of the confirmation request.  The
390 message MUST be signed and encrypted using the PGP/MIME Combined
391 format ({{{RFC(3156)}}}, section 6.2).  The signing key is the target
392 key and the encryption key is the key associated with the provider's
393 submission address.
394
395 The Content-Type used for the plaintext message MUST match the
396 Content-Type of the request.  The format is the same as described
397 above for the Confirmation Request.  The body must contain three
398 name-value pairs in this order:
399
400 - type :: The value must be "confirmation-response".
401
402 - sender :: The value must match the mailbox part of the "From:"
403             address of this response.  Exactly one address MUST be
404             given.
405
406 - nonce :: The value is the value of the "nonce" parameter from the
407            confirmation request.
408
409 ** Policy Flags
410
411 For key generation and submission it is useful to tell the
412 client about certain properties of the mail provider in advance.  This
413 can be done with a file at the URL
414
415 #+BEGIN_EXAMPLE
416       WELLKNOWN/policy
417 #+END_EXAMPLE
418
419 A site supporting the Web Key Directory MUST serve this file; it is
420 sufficient if that file has a zero length.  Clients may use this file
421 to check for Web Key Directory support.
422
423 The file contains keywords and optioanlly values, one per line with
424 each line terminated by a LF or the sequence of CR and LF.  Empty lines
425 and lines starting with a '#' character are considered comment
426 lines.  A keyword is made up of lowercase letters, digits, hyphens, or
427 dots.  An underscore is allowed as a name space delimiters; see
428 below.  The first character must be a letter.  Keywords which are
429 defined to require a value are directly followed by a colon and then
430 after optional white space the value.  Clients MUST use
431 case-insensitive matching for the keyword.
432
433 Currently defined keywords are:
434
435 - mailbox-only :: The mail server provider does only accept keys
436                     with only a mailbox in the User ID.  In particular
437                     User IDs with a real name in addition to the
438                     mailbox will be rejected as invalid.
439
440 - dane-only :: The mail server provider does not run a Web Key
441                  Directory but only an OpenPGP DANE service.  The Web
442                  Key Directory Update protocol is used to update the
443                  keys for the DANE service.
444
445 - auth-submit :: The submission of the mail to the server is done
446                    using an authenticated connection.  Thus the
447                    submitted key will be published immediately without
448                    any confirmation request.
449
450 - protocol-version :: This keyword can be used to explicitly claim the
451      support of a specific version of the Web Key Directory update protocol.
452      This is in general not needed but implementations may have
453      workarounds for providers which only support an old protocol
454      version.  If these providers update to a newer version they
455      should add this keyword so that the implementation can disable
456      the workaround.  The value is an integer corresponding to the
457      respective draft revision number.
458
459 # Fixme: Add a protocol-version value for the final RFC.
460
461
462 More keywords will be defined in updates to this I-D.  There is no
463 registry except for this document.  For experimental use of new
464 features or for provider specific settings, keywords MUST be prefixed
465 with a domain name and an underscore.
466
467 * Security Considerations
468
469 The use of SHA-1 for the mapping of the local-part to a fixed string
470 is not a security feature but merely used to map the local-part to a
471 fixed-sized string made from a well defined set of characters.  It is not
472 intended to conceal information about a mail address.
473
474 The domain name part of the mail address is not part of the hash to
475 avoid problems with internationalized domain names.  Instead a
476 separate URL is required for each domain name.
477
478 The use of DNS SRV records reduces the certainty that a mail address
479 belongs to a domain.  For example an attacker may change the target to
480 a host in a sub-domain under their control and thus gain full control
481 over all keys.  An implementation may want to weight the certainty of
482 a mapping different if it has been retrieved via a sub-domain and in
483 particular if a non-recommended name is used for the sub-domain.
484
485
486 * IANA Considerations
487
488 ** Well-Known URI
489
490 IANA is requested to assign a well-known URI in the "Well-Known URIs"
491 registry as defined by {{{RFC(5785)}}}:
492
493 URI suffix: openpgpkey
494
495 Change controller: IETF
496
497 Specification document: This
498
499 * Acknowledgments
500
501 The author would like to acknowledge the help of the individuals who
502 kindly voiced their opinions on the GnuPG mailing lists, in particular,
503 the help of Bernhard Reiter and Guilhem Moulin.
504
505 * Back
506
507 * Sample Protocol Run
508
509 The following non-normative example can be used by implementors as
510 guidance.
511
512 Note that GnuPG version 2.1.12 supports the key discovery described in
513 version -00 of this document (auto-key-locate method "wkd").  Version
514 2.1.16 can run the protocol described in this document but is also able
515 to run the protocol version specified by -01.  For backward
516 compatibility this example uses the Content-Type as required for
517 versions of this protocol prior to -04; if the client knows that the
518 server support -04 "vnd.gnupg.wkd" should be used.
519
520 ** Sample Keys
521
522 This is the provider's submission key:
523 #+begin_example
524 -----BEGIN PGP PRIVATE KEY BLOCK-----
525
526 lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
527 FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
528 c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
529 CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
530 BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
531 C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
532 Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
533 iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
534 My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
535 HFAD
536 =Hnwd
537 -----END PGP PRIVATE KEY BLOCK-----
538 #+end_example
539
540 This is the target key to be published:
541 #+begin_example
542 -----BEGIN PGP PRIVATE KEY BLOCK-----
543
544 lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
545 nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
546 aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
547 CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
548 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
549 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
550 qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
551 PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
552 Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
553 TiFZBA==
554 =GHi7
555 -----END PGP PRIVATE KEY BLOCK-----
556 #+end_example
557
558 ** Sample Messages
559
560 The first message triggeres the publication requests.
561 #+begin_example
562 From: patrice.lumumba@example.net
563 To: key-submission@example.net
564 Subject: Key publishing request
565 MIME-Version: 1.0
566 Content-Type: multipart/encrypted;
567         protocol="application/pgp-encrypted";
568         boundary="=-=01-e8k41e11ob31eefa36wo=-="
569 Date: Wed, 05 Oct 2016 10:15:51 +0000
570
571
572 --=-=01-e8k41e11ob31eefa36wo=-=
573 Content-Type: application/pgp-encrypted
574
575 Version: 1
576
577 --=-=01-e8k41e11ob31eefa36wo=-=
578 Content-Type: application/octet-stream
579
580 -----BEGIN PGP MESSAGE-----
581
582 hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
583 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
584 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
585 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
586 ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
587 wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
588 n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
589 jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
590 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
591 ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
592 Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
593 J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
594 R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
595 iM7PY4fwAHo890Dx+Qlt
596 =WIhx
597 -----END PGP MESSAGE-----
598
599 --=-=01-e8k41e11ob31eefa36wo=-=--
600 #+end_example
601
602 The server decrypts this message to
603 #+begin_example
604 Content-Type: application/pgp-keys
605
606 -----BEGIN PGP PUBLIC KEY BLOCK-----
607
608 mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
609 nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
610 AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
611 OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
612 AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
613 CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
614 KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
615 OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
616 =qRfF
617 -----END PGP PUBLIC KEY BLOCK-----
618 #+end_example
619
620 and returns this confirmation request
621 #+begin_example
622 From: key-submission@example.net
623 To: patrice.lumumba@example.net
624 Subject: Confirm your key publication
625 MIME-Version: 1.0
626 Content-Type: multipart/encrypted;
627         protocol="application/pgp-encrypted";
628         boundary="=-=01-wrzqued738dfx4x97u7y=-="
629 Date: Wed, 05 Oct 2016 10:16:57 +0000
630
631
632 --=-=01-wrzqued738dfx4x97u7y=-=
633 Content-Type: application/pgp-encrypted
634
635 Version: 1
636
637 --=-=01-wrzqued738dfx4x97u7y=-=
638 Content-Type: application/octet-stream
639
640 -----BEGIN PGP MESSAGE-----
641
642 hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
643 FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
644 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
645 zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
646 NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
647 MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
648 MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
649 KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
650 =Cdjh
651 -----END PGP MESSAGE-----
652
653 --=-=01-wrzqued738dfx4x97u7y=-=--
654 #+end_example
655
656 The client decrypts the attachment as
657 #+begin_example
658 Content-Type: application/vnd.gnupg.wks
659 Content-Transfer-Encoding: 8bit
660
661 type: confirmation-request
662 sender: key-submission@example.net
663 address: patrice.lumumba@example.net
664 fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
665 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
666 #+end_example
667
668 creates this response
669 #+begin_example
670 Content-Type: application/vnd.gnupg.wks
671 Content-Transfer-Encoding: 8bit
672
673 type: confirmation-response
674 sender: key-submission@example.net
675 address: patrice.lumumba@example.net
676 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
677 #+end_example
678
679 and sends it encrypted to the server
680 #+begin_example
681 From: patrice.lumumba@example.net
682 To: key-submission@example.net
683 Subject: Key publication confirmation
684 MIME-Version: 1.0
685 Content-Type: multipart/encrypted;
686         protocol="application/pgp-encrypted";
687         boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
688 Date: Wed, 05 Oct 2016 10:18:52 +0000
689
690
691 --=-=01-iacqg4og4pqz11a5cg1o=-=
692 Content-Type: application/pgp-encrypted
693
694 Version: 1
695
696 --=-=01-iacqg4og4pqz11a5cg1o=-=
697 Content-Type: application/octet-stream
698
699 -----BEGIN PGP MESSAGE-----
700
701 hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
702 ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
703 0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
704 5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
705 OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
706 dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
707 ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
708 =7uve
709 -----END PGP MESSAGE-----
710
711 --=-=01-iacqg4og4pqz11a5cg1o=-=--
712 #+end_example
713
714
715 * Changes Since -04
716
717 - Change to Content-Type "vnd.gnupg.wkd" for servers announcing its
718   support.
719 - Require the existance of the Policy Flags file.
720 - Re-title this I-D to Web Key Directory.