drafts,openpgp-webkey-service: Define keyword protocol-version
[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-04">
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 Service</title>
34     <author initials="W." surname="Koch"
35             fullname="Werner Koch">
36       <organization>GnuPG Project</organization>
37       <address>
38         <email>wk@gnupg.org</email>
39         <uri>https://gnupg.org</uri>
40       </address>
41     </author>
42
43     <date month="July" 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
200 * Web Key Directory Update Protocol
201
202 To put keys into the key directory a protocol to automate the task is
203 desirable.  The protocol defined here is entirely based on mail and
204 the assumption that a mail provider can securely deliver mail to the
205 INBOX of a user (e.g. an IMAP folder).  Note that the same protocol
206 may also be used for submitting keys for use with OpenPGP DANE.
207
208 We assume that the user already created a key for her mail account
209 alice@example.org.  To install the key at her provider's Web Key
210 Directory, she performs the following steps:
211
212 1. She retrieves a file which contains one line with the mail address
213    used to submit the key to the mail provider. The DNS SRV rules
214    described for the Web Key Directory apply here as well.  See below
215    for the syntax of that file.  For a mail address at the domain
216    "example.org" the URI of the file is
217 #+begin_example
218      https://example.org/.well-known/openpgpkey/submission-address
219 #+end_example
220
221 2. She sends her key using SMTP (or any other transport mechanism) to
222    the provider using the submission address and key format as specified
223    by PGP/MIME.
224
225 3. The provider checks that the received key has a User ID which matches
226    an account name of the provider.
227
228 4. The provider sends an encrypted message containing a nonce and the
229    fingerprint of the key to the mail account of the user.  Note that a
230    similar scheme is used by the well known caff(1) tool to help with
231    key signing parties.
232
233 5. A legitimate user will be able to decrypt the message because she
234    created the key and is in charge of the private key.  This step
235    verifies that the submitted key has actually been created by the
236    owner of the account.
237
238 6. The user sends the decrypted nonce back to the submission address
239    as a confirmation that the private key is owned by her and that the
240    provider may now publish the key.  Although technically not
241    required, it is suggested that the mail to the provider is
242    encrypted.  The public key for this is retrieved using the key
243    lookup protocol described above.
244
245 7. The provider receives the nonce, matches it with its database of
246    pending confirmations and then publishes the key.  Finally the
247    provider sends a mail back to the user to notify her of the
248    publication of her key.
249
250 The message data structures used for the above protocol are specified in
251 detail below.  In the following sections the string "WELLKNOWN" denotes
252 the first part of an URI specific for a domain.  In the examples the
253 domain "example.org" is assumed, thus
254
255 #+BEGIN_EXAMPLE
256       WELLKNOWN := https://example.org/.well-known/openpgpkey
257 #+END_EXAMPLE
258
259 The term "target key" denotes the to be published key, the term
260 "submission key" the key associated with the submission-address of the
261 mail provider.
262
263 ** The Submission Address
264
265 The address of the submission file is
266
267 #+BEGIN_EXAMPLE
268       WELLKNOWN/submission-address
269 #+END_EXAMPLE
270
271 The file consists of exactly one line, terminated by a LF, or the
272 sequence of CR and LF, with the full mail address to be used for
273 submission of a key to the mail provider.  For example the content of the
274 file may be
275
276 #+BEGIN_EXAMPLE
277       key-submission-example.org@directory.example.org
278 #+END_EXAMPLE
279
280 ** The Submission Mail
281
282 The mail used to submit a key to the mail provider MUST comply to the
283 PGP/MIME specification ({{{RFC(3156)}}}, section 7), which states that
284 the Content-Type must be "application/pgp-keys", there are no required
285 or optional parameters, and the body part contains the ASCII-armored
286 transferable Public Key Packets as defined in {{{RFC(4880)}}}, section
287 11.1.
288
289 The mail provider MUST publish a key capable of signing and encryption
290 for the submission-address in the Web Key Directory or via DANE.  The
291 key to be published MUST be submitted using a PGP/MIME encrypted
292 message ({{{RFC(3156)}}}, section 4).  The message MUST NOT be signed
293 (because the authenticity of the signing key has not yet been
294 confirmed).  After decryption of the message at the mail provider a
295 single "application/pgp-keys" part, as specified above, is expected.
296
297 ** The Confirmation Request
298
299 The mail provider sends a confirmation mail in response to a received
300 key publication request.  The message MUST be sent from the
301 submission-address of the mail provider to the mail address extracted
302 from the target key.  The message needs to be a PGP/MIME signed
303 message using the submission key of the provider for the
304 signature.  The signed message MUST have two parts:
305
306 The first part MUST have "text" as its Content-Type and can be used to
307 explain the purpose of the mail.  For example it may point to this RFC
308 and explain on how to manually perform the protocol.
309
310 The second part MUST have "application/vnd.gnupg.wks" as its
311 Content-Type and carry an OpenPGP encrypted message in ASCII Armor
312 format.  The message MUST be encrypted to the target key and MUST NOT
313 be signed.  After decryption a text file in the Web Key data format
314 must be yielded.
315
316 That data format consists of name-value pairs with one name-value pair
317 per LF or CR+LF terminated line.  Empty lines are allowed and will be
318 ignored by the receiver.  A colon is used to terminate a name.
319
320 In a confirmation request the following names MUST be send in the
321 specified order:
322
323 - type :: The value must be "confirmation-request".
324
325 - sender :: This is the mailbox the user is expected to sent the
326             confirmation response to.  The value must match the
327             mailbox part of the "From:" address of this
328             request.  Exactly one address MUST be given.
329
330 - address :: The value is the addr-spec part of the target key's
331              mail address.  The value SHOULD match the addr-spec part
332              of the recipient's address.  The value MUST be UTF-8
333              encoded as required for an OpenPGP User ID.
334
335 - fingerprint :: The value is the fingerprint of the target key.  The
336                  fingerprint is given in uppercase hex encoding
337                  without any interleaving spaces.
338
339 - nonce :: The value is a string with a minimum length of 16 octets
340            and a maximum length of 64 octets.  The string must
341            entirely be made up of random ASCII letters or
342            digits.  This nonce will be sent back to the mail provider
343            as proof that the recipient is the legitimate owner of
344            the target-key.
345
346 The receiver of that message is expected to verify the outer signature
347 and disregard the entire message if it can't be verified or has not
348 been signed by the key associated with the submission address.
349
350 After the message as been verified the receiver decrypts the second part
351 of the message, checks that the "fingerprint" matches the target key,
352 checks that the "address" matches a User ID of the target key, and
353 checks the other constrains of the request format.  If any constraint
354 is not asserted, or the fingerprint or User ID do not match the target
355 key, or there is no pending publication requests (i.e. a mail recently
356 sent o the submission address), the user MAY be notified about this
357 fake confirmation attempt.
358
359 In other cases the confirmation request is legitimate and the MUA
360 shall silently send a response as described in the next section.
361
362 The rationale for the outer signature used with this request is to
363 allow early detection of spam mails.  This can be done prior to the
364 decryption step and avoids asking the user to enter a passphrase to
365 perform the decryption for a non-legitimate message.  The use of a
366 simple encrypted attachment, instead of using PGP/MIME encryption, is
367 to convey the Content-Type of that attachment in the clear and also to
368 prevent automatic decryption of that attachment by PGP/MIME aware
369 clients.  The MUA may in fact detect this confirmation request and
370 present a customized dialog for confirming that request.
371
372
373 ** The Confirmation Response
374
375 A response to a confirmation request MUST only be send in the positive
376 case; there is no negative confirmation response.  A mail service
377 provider is expected to cancel a pending key submission after a suitable
378 time without a confirmation.  The mail service provider SHOULD NOT retry
379 the sending of a confirmation request after the first request has been
380 send successfully.
381
382 The user MUST send the confirmation response from her target mail
383 address to the "from" address of the confirmation request.  The
384 message MUST be signed and encrypted using the PGP/MIME Combined
385 format ({{{RFC(3156)}}}, section 6.2).  The signing key is the target
386 key and the encryption key is the key associated with the provider's
387 submission address.
388
389 The Content-Type used for the plaintext message MUST also be
390 "application/vnd.gnupg.wks".  The format is the same as described above
391 for the Confirmation Request.  The body must contain three name-value
392 pairs in this order:
393
394 - type :: The value must be "confirmation-response".
395
396 - sender :: The value must match the mailbox part of the "From:"
397             address of this response.  Exactly one address MUST be
398             given.
399
400 - nonce :: The value is the value of the "nonce" parameter from the
401            confirmation request.
402
403 ** Policy Flags
404
405 For key generation and submission it is sometimes useful to tell the
406 client about certain properties of the mail provider in advance.  This
407 can be done with a file at the URL
408
409 #+BEGIN_EXAMPLE
410       WELLKNOWN/policy
411 #+END_EXAMPLE
412
413 The file contains keywords and optioanlly values, one per line with
414 each line terminated by a LF or the sequence of CR and LF.  Empty lines
415 and lines starting with a '#' character are considered comment
416 lines.  A keyword is made up of lowercase letters, digits, hyphens, or
417 dots.  An underscore is allowed as a name space delimiters; see
418 below.  The first character must be a letter.  Keywords which are
419 defined to require a value are directly followed by a colon and then
420 after optional white space the value.  Clients MUST use
421 case-insensitive matching for the keyword.
422
423 Currently defined keywords are:
424
425 - mailbox-only :: The mail server provider does only accept keys
426                     with only a mailbox in the User ID.  In particular
427                     User IDs with a real name in addition to the
428                     mailbox will be rejected as invalid.
429
430 - dane-only :: The mail server provider does not run a Web Key
431                  Directory but only an OpenPGP DANE service.  The Web
432                  Key Directory Update protocol is used to update the
433                  keys for the DANE service.
434
435 - auth-submit :: The submission of the mail to the server is done
436                    using an authenticated connection.  Thus the
437                    submitted key will be published immediately without
438                    any confirmation request.
439
440 - protocol-version :: This keyword can be used to explicitly claim the
441      support of a specific version of the Web Key Service protocol.
442      This is in general not needed but implementations may have
443      workarounds for providers which only support an old protocol
444      version.  If these providers update to a newer version they
445      should add this keyword so that the implementation can disable
446      the workaround.  The value is an integer corresponding to the
447      respective draft revision number.
448
449 # Fixme: Add a protocol-version value for the final RFC.
450
451
452 More keywords will be defined in updates to this I-D.  There is no
453 registry except for this document.  For experimental use of new
454 features or for provider specific settings, keywords MUST be prefixed
455 with a domain name and an underscore.
456
457 * Security Considerations
458
459 The use of SHA-1 for the mapping of the local-part to a fixed string
460 is not a security feature but merely used to map the local-part to a
461 fixed-sized string made from a well defined set of characters.  It is not
462 intended to conceal information about a mail address.
463
464 The domain name part of the mail address is not part of the hash to
465 avoid problems with internationalized domain names.  Instead a
466 separate URL is required for each domain name.
467
468 The use of DNS SRV records reduces the certainty that a mail address
469 belongs to a domain.  For example an attacker may change the target to
470 a host in a sub-domain under their control and thus gain full control
471 over all keys.  An implementation may want to weight the certainty of
472 a mapping different if it has been retrieved via a sub-domain and in
473 particular if a non-recommended name is used for the sub-domain.
474
475
476 * IANA Considerations
477
478 ** Well-Known URI
479
480 IANA is requested to assign a well-known URI in the "Well-Known URIs"
481 registry as defined by {{{RFC(5785)}}}:
482
483 URI suffix: openpgpkey
484
485 Change controller: IETF
486
487 Specification document: This
488
489 * Acknowledgments
490
491 The author would like to acknowledge the help of the individuals who
492 kindly voiced their opinions on the GnuPG mailing lists, in particular,
493 the help of Bernhard Reiter and Guilhem Moulin.
494
495 * Back
496
497 * Sample Protocol Run
498
499 The following non-normative example can be used by implementors as
500 guidance.
501
502 Note that GnuPG version 2.1.12 supports the key discovery described in
503 version -00 of this document (auto-key-locate method "wkd").  Version
504 2.1.16 can run the protocol decribed in this document but is also able
505 to run the protocol version specified by -01.
506
507 ** Sample Keys
508
509 This is the provider's submission key:
510 #+begin_example
511 -----BEGIN PGP PRIVATE KEY BLOCK-----
512
513 lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
514 FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
515 c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
516 CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
517 BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
518 C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
519 Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
520 iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
521 My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
522 HFAD
523 =Hnwd
524 -----END PGP PRIVATE KEY BLOCK-----
525 #+end_example
526
527 This is the target key to be published:
528 #+begin_example
529 -----BEGIN PGP PRIVATE KEY BLOCK-----
530
531 lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
532 nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
533 aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
534 CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
535 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
536 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
537 qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
538 PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
539 Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
540 TiFZBA==
541 =GHi7
542 -----END PGP PRIVATE KEY BLOCK-----
543 #+end_example
544
545 ** Sample Messages
546
547 The first message triggeres the publication requests.
548 #+begin_example
549 From: patrice.lumumba@example.net
550 To: key-submission@example.net
551 Subject: Key publishing request
552 MIME-Version: 1.0
553 Content-Type: multipart/encrypted;
554         protocol="application/pgp-encrypted";
555         boundary="=-=01-e8k41e11ob31eefa36wo=-="
556 Date: Wed, 05 Oct 2016 10:15:51 +0000
557
558
559 --=-=01-e8k41e11ob31eefa36wo=-=
560 Content-Type: application/pgp-encrypted
561
562 Version: 1
563
564 --=-=01-e8k41e11ob31eefa36wo=-=
565 Content-Type: application/octet-stream
566
567 -----BEGIN PGP MESSAGE-----
568
569 hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
570 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
571 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
572 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
573 ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
574 wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
575 n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
576 jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
577 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
578 ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
579 Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
580 J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
581 R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
582 iM7PY4fwAHo890Dx+Qlt
583 =WIhx
584 -----END PGP MESSAGE-----
585
586 --=-=01-e8k41e11ob31eefa36wo=-=--
587 #+end_example
588
589 The server decrypts this message to
590 #+begin_example
591 Content-Type: application/pgp-keys
592
593 -----BEGIN PGP PUBLIC KEY BLOCK-----
594
595 mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
596 nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
597 AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
598 OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
599 AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
600 CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
601 KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
602 OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
603 =qRfF
604 -----END PGP PUBLIC KEY BLOCK-----
605 #+end_example
606
607 and returns this confirmation request
608 #+begin_example
609 From: key-submission@example.net
610 To: patrice.lumumba@example.net
611 Subject: Confirm your key publication
612 MIME-Version: 1.0
613 Content-Type: multipart/encrypted;
614         protocol="application/pgp-encrypted";
615         boundary="=-=01-wrzqued738dfx4x97u7y=-="
616 Date: Wed, 05 Oct 2016 10:16:57 +0000
617
618
619 --=-=01-wrzqued738dfx4x97u7y=-=
620 Content-Type: application/pgp-encrypted
621
622 Version: 1
623
624 --=-=01-wrzqued738dfx4x97u7y=-=
625 Content-Type: application/octet-stream
626
627 -----BEGIN PGP MESSAGE-----
628
629 hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
630 FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
631 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
632 zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
633 NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
634 MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
635 MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
636 KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
637 =Cdjh
638 -----END PGP MESSAGE-----
639
640 --=-=01-wrzqued738dfx4x97u7y=-=--
641 #+end_example
642
643 The client decrypts the attachment as
644 #+begin_example
645 Content-Type: application/vnd.gnupg.wks
646 Content-Transfer-Encoding: 8bit
647
648 type: confirmation-request
649 sender: key-submission@example.net
650 address: patrice.lumumba@example.net
651 fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
652 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
653 #+end_example
654
655 creates this response
656 #+begin_example
657 Content-Type: application/vnd.gnupg.wks
658 Content-Transfer-Encoding: 8bit
659
660 type: confirmation-response
661 sender: key-submission@example.net
662 address: patrice.lumumba@example.net
663 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
664 #+end_example
665
666 and sends it encrypted to the server
667 #+begin_example
668 From: patrice.lumumba@example.net
669 To: key-submission@example.net
670 Subject: Key publication confirmation
671 MIME-Version: 1.0
672 Content-Type: multipart/encrypted;
673         protocol="application/pgp-encrypted";
674         boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
675 Date: Wed, 05 Oct 2016 10:18:52 +0000
676
677
678 --=-=01-iacqg4og4pqz11a5cg1o=-=
679 Content-Type: application/pgp-encrypted
680
681 Version: 1
682
683 --=-=01-iacqg4og4pqz11a5cg1o=-=
684 Content-Type: application/octet-stream
685
686 -----BEGIN PGP MESSAGE-----
687
688 hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
689 ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
690 0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
691 5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
692 OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
693 dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
694 ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
695 =7uve
696 -----END PGP MESSAGE-----
697
698 --=-=01-iacqg4og4pqz11a5cg1o=-=--
699 #+end_example
700
701
702 * Changes Since -03
703
704 - Fixed Content-Type in the description.  The one used in the example
705   was correct.