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