idnits 2.17.1 draft-koch-openpgp-webkey-service-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2022) is 714 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Koch 3 Internet-Draft GnuPG e.V. 4 Intended status: Informational May 13, 2022 5 Expires: November 14, 2022 7 OpenPGP Web Key Directory 8 draft-koch-openpgp-webkey-service-14 10 Abstract 12 This specification describes a service to locate OpenPGP keys by mail 13 address using a Web service and the HTTPS protocol. It also provides 14 a method for secure communication between the key owner and the mail 15 provider to publish and revoke the public key. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 14, 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 53 3. Web Key Directory . . . . . . . . . . . . . . . . . . . . . . 2 54 3.1. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Web Key Directory Update Protocol . . . . . . . . . . . . . . 6 56 4.1. The Submission Address . . . . . . . . . . . . . . . . . 7 57 4.2. The Submission Mail . . . . . . . . . . . . . . . . . . . 7 58 4.3. The Confirmation Request . . . . . . . . . . . . . . . . 8 59 4.4. The Confirmation Response . . . . . . . . . . . . . . . . 9 60 4.5. Policy Flags . . . . . . . . . . . . . . . . . . . . . . 10 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 6.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 66 Appendix A. Sample Protocol Run . . . . . . . . . . . . . . . . 13 67 A.1. Sample Keys . . . . . . . . . . . . . . . . . . . . . . . 13 68 A.2. Sample Messages . . . . . . . . . . . . . . . . . . . . . 14 69 Appendix B. Changes Since -13 . . . . . . . . . . . . . . . . . 19 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 72 1. Introduction 74 This memo describes a method to associate OpenPGP keys with a mail 75 address and how to look them up using a web service with a well-known 76 URI. In addition a mail based protocol is given to allow a client to 77 setup such an association and to maintain it. 79 2. Notational Conventions 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Web Key Directory 87 A major use case for OpenPGP is the encryption of mail. A common 88 difficulty of sending encrypted mails to a new communication partner 89 is to find the appropriate public key of the recipient. Unless an 90 off-channel key exchange has been done, there are no easy ways to 91 discover the required key. The common practice is to search the 92 network of public key servers for a key matching the recipient's mail 93 address. This practise bears the problem that the keyservers are not 94 able to give a positive confirmation that a key actually belongs to 95 the mail addresses given in the key. Further, there are often 96 several keys matching a mail address and thus one needs to pick a key 97 on good luck. This is clearly not a secure way to setup an end-to- 98 end encryption. Even if the need for a trusted key for an initial 99 mail message is relinquished, a non-authenticated key may be a wrong 100 one and the actual recipient would receive a mail which she can't 101 decrypt, due to the use of a wrong key. 103 Methods to overcome this problem are 105 o sending an initial unencrypted message with the public key 106 attached, 108 o using the OpenPGP DANE protocol to lookup the recipients key via 109 the DNS. 111 The first method has the obvious problems of not even trying to 112 encrypt the initial mail, an extra mail round-trip, and problems with 113 unattended key discovery. 115 The latter method works fine but requires that mail providers need to 116 set up a separate DNS resolver to provide the key. The 117 administration of a DNS zone is often not in the hands of small mail 118 installations. Thus an update of the DNS resource records needs to 119 be delegated to the ISP running the DNS service. Further, DNS 120 lookups are not encrypted and missing all confidentially. Even if 121 the participating MUAs are using STARTTLS to encrypt the mail 122 exchange, a DNS lookup for the key unnecessarily identifies the 123 local-part of the recipients mail address to any passive 124 eavesdroppers. 126 This memo specified a new method for key discovery using an encrypted 127 https connection. 129 3.1. Key Discovery 131 Although URIs are able to encode all kind of characters, 132 straightforward implementations of a key directory may want to store 133 the local-part of a mail address directly in the file system. This 134 forbids the use of certain characters in the local-part. To allow 135 for such an implementation method the URI uses an encoded form of the 136 local-part which can be directly mapped to a file name. 138 OpenPGP defines its User IDs, and thus the mail address, as UTF-8 139 strings. To help with the common pattern of using capitalized names 140 (e.g. "Joe.Doe@example.org") for mail addresses, and under the 141 premise that almost all MTAs treat the local-part case-insensitive 142 and that the domain-part is required to be compared case-insensitive 143 anyway, all upper-case ASCII characters in a User ID are mapped to 144 lowercase. Non-ASCII characters are not changed. 146 The so mapped local-part is hashed using the SHA-1 algorithm. The 147 resulting 160 bit digest is encoded using the Z-Base-32 method as 148 described in [RFC6189], section 5.1.6. The resulting string has a 149 fixed length of 32 octets. 151 There are two variants on how to form the request URI: The advanced 152 and the direct method. Implementations MUST first try the advanced 153 method. Only if an address for the required sub-domain does not 154 exist, they SHOULD fall back to the direct method. A non-responding 155 server does not mean that the fall back should be carried out. 157 The advanced method requires that a sub-domain with the fixed name 158 "openpgpkey" is created and queried. The URI is constructed by 159 concatenating these items: 161 o The scheme "https://", 163 o the string "openpgpkey", 165 o the domain-part, 167 o the string "/.well-known/openpgpkey/", 169 o the domain-part in lowercase, 171 o the string "/hu/", 173 o the above constructed 32 octet string, 175 o the unchanged local-part as a parameter with name "l" using proper 176 percent escaping. 178 An example for such an advanced method URI to lookup the key for 179 Joe.Doe@Example.ORG is: 181 https://openpgpkey.example.org/.well-known/openpgpkey/ 182 example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe 184 (line has been wrapped for rendering purposes) 186 The direct method requires no additional DNS entries and constructs 187 the URI by concatenating these items: 189 o The scheme "https://", 191 o the domain-part, 193 o the string "/.well-known/openpgpkey/hu/", 194 o the above constructed 32 octet string, 196 o the unchanged local-part as a parameter with name "l" using proper 197 percent escaping. 199 Example for a direct method URI: 201 https://example.org/.well-known/openpgpkey/ 202 hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe 204 (line has been wrapped for rendering purposes) 206 Sites which do not use the advanced method but employ wildcard DNS 207 for their sub-domains MUST make sure that the "openpgpkey" sub-domain 208 is not subject to the wildcarding. This can be done by inserting an 209 empty TXT RR for this sub-domain. 211 The HTTP GET method MUST return the binary representation of the 212 OpenPGP key for the given mail address. The key needs to carry a 213 User ID packet ([RFC4880]) with that mail address. Note that the key 214 may be revoked or expired - it is up to the client to handle such 215 conditions. To ease distribution of revoked keys, a server may 216 return revoked keys in addition to a new key. The keys are returned 217 by a single request as concatenated key blocks. 219 The server MUST accept the HTTP HEAD method to allow a client to 220 check for the existence of a key. 222 The server SHOULD use "application/octet-stream" as the Content-Type 223 for the data but clients SHOULD also accept any other Content-Type. 224 The server MUST NOT return an ASCII armored version of the key. 226 The server MUST serve a Policy Flags file as specified below. That 227 file is even required if the Web Key Directory Update Protocol is not 228 supported. 230 The benefit of the advanced method is its greater flexibility in 231 setting up the Web Key Directory in environments where more than one 232 mail domain is hosted. DNS SRV resource records, as used in earlier 233 specifications of this protocol, posed a problem for implementations 234 which have only limited access to DNS resolvers. The direct method 235 is kept for backward compatibility and to allow providing a Web Key 236 Directory even with without DNS change requirements. 238 4. Web Key Directory Update Protocol 240 To put keys into the key directory a protocol to automate the task is 241 desirable. The protocol defined here is entirely based on mail and 242 the assumption that a mail provider can securely deliver mail to the 243 INBOX of a user (e.g. an IMAP folder). Note that the same protocol 244 may also be used for submitting keys for use with OpenPGP DANE. 246 In the following sections the term "target key" denotes the to be 247 published key, the term "submission key" the key associated with the 248 submission-address of the mail provider. The string "WELLKNOWN" 249 denotes the first part of an URI specific for a domain. In the 250 examples the domain "example.org" is assumed, thus: 252 WELLKNOWN := https://openpgpkey.example.org/.well-known/ 253 openpgpkey/example.org 255 (line has been wrapped for rendering purposes) 257 or if the sub-domain "openpgpkey" does not exist (direct method): 259 WELLKNOWN := https://example.org/.well-known/openpgpkey 261 We assume that the user already created a key for her mail account 262 alice@example.org. To install the key at her provider's Web Key 263 Directory, she performs the following steps: 265 1. She retrieves a file which contains one line with the mail 266 address used to submit the key to the mail provider. See below 267 for the syntax of that file. For a mail address at the domain 268 "example.org" the URI of the file is 270 WELLKNOWN/submission-address 272 2. She sends her key using SMTP (or any other transport mechanism) 273 to the provider using the submission address and key format as 274 specified by PGP/MIME. 276 3. The provider checks that the received key has a User ID which 277 matches an account name of the provider. 279 4. The provider sends an encrypted message containing a nonce and 280 the fingerprint of the key to the mail account of the user. Note 281 that a similar scheme is used by the well known caff(1) tool to 282 help with key signing parties. 284 5. A legitimate user will be able to decrypt the message because she 285 created the key and is in charge of the private key. This step 286 verifies that the submitted key has actually been created by the 287 owner of the account. 289 6. The user sends the decrypted nonce back to the submission address 290 as a confirmation that the private key is owned by her and that 291 the provider may now publish the key. The confirmation mail to 292 the provider MUST be encrypted using the provider's public key as 293 retrieved using the key lookup protocol described above. 295 7. The provider receives the nonce, matches it with its database of 296 pending confirmations and then publishes the key. Finally the 297 provider sends a mail back to the user to notify her of the 298 publication of her key. 300 The message data structures used for the above protocol are specified 301 in detail below. 303 4.1. The Submission Address 305 The address of the submission file is 307 WELLKNOWN/submission-address 309 The file consists of exactly one line, terminated by a LF, or the 310 sequence of CR and LF, with the full mail address to be used for 311 submission of a key to the mail provider. For example the content of 312 the file may be 314 key-submission-example.org@directory.example.org 316 4.2. The Submission Mail 318 The mail used to submit a key to the mail provider MUST comply to the 319 PGP/MIME specification ([RFC3156], section 7), which states that the 320 Content-Type must be "application/pgp-keys", there are no required or 321 optional parameters, and the body part contains the ASCII-armored 322 transferable Public Key Packets as defined in [RFC4880], section 323 11.1. 325 The mail provider MUST publish a key capable of signing and 326 encryption for the submission-address in the Web Key Directory or via 327 DANE. The key to be published MUST be submitted using a PGP/MIME 328 encrypted message ([RFC3156], section 4). The message MUST NOT be 329 signed (because the authenticity of the signing key has not yet been 330 confirmed). After decryption of the message at the mail provider a 331 single "application/pgp-keys" part, as specified above, is expected. 333 4.3. The Confirmation Request 335 The mail provider sends a confirmation mail in response to a received 336 key publication request. The message MUST be sent from the 337 submission-address of the mail provider to the mail address extracted 338 from the target key. The message needs to be a PGP/MIME signed 339 message using the submission key of the provider for the signature. 340 The signed message MUST have two parts: 342 The first part MUST have "text" as its Content-Type and can be used 343 to explain the purpose of the mail. For example it may point to this 344 specification and explain on how to manually perform the protocol. 346 The second part MUST have a Content-Type of "application/ 347 vnd.gnupg.wkd" and carry an OpenPGP encrypted message in ASCII Armor 348 format. If the protocol version is unknown or less than 5 the 349 Content-Type "application/vnd.gnupg.wks" MUST be used for backward 350 compatibility. The message MUST be encrypted to the target key and 351 MUST NOT be signed. After decryption a text file in the Web Key data 352 format must be yielded. 354 That data format consists of name-value pairs with one name-value 355 pair per LF or CR+LF terminated line. Empty lines are allowed and 356 will be ignored by the receiver. A colon is used to terminate a 357 name. 359 In a confirmation request the following names MUST be send in the 360 specified order: 362 o "type": The value must be "confirmation-request". 364 o "sender": This is the mailbox the user is expected to sent the 365 confirmation response to. The value must match the mailbox part 366 of the "From:" address of this request. Exactly one address MUST 367 be given. 369 o "address": The value is the addr-spec part of the target key's 370 mail address. The value SHOULD match the addr-spec part of the 371 recipient's address. The value MUST be UTF-8 encoded as required 372 for an OpenPGP User ID. 374 o "fingerprint": The value is the fingerprint of the target key. 375 The fingerprint is given in uppercase hex encoding without any 376 interleaving spaces. 378 o "nonce": The value is a string with a minimum length of 16 octets 379 and a maximum length of 64 octets. The string must entirely be 380 made up of random ASCII letters or digits. This nonce will be 381 sent back to the mail provider as proof that the recipient is the 382 legitimate owner of the target-key. 384 The receiver of that message is expected to verify the outer 385 signature and disregard the entire message if it can't be verified or 386 has not been signed by the key associated with the submission 387 address. 389 After the message has been verified the receiver decrypts the second 390 part of the signed message, checks that the "fingerprint" matches the 391 target key, checks that the "address" matches a User ID of the target 392 key, and checks the other constrains of the request format. If any 393 constraint is not asserted, or the fingerprint or User ID do not 394 match the target key, or there is no pending publication requests 395 (i.e. a mail recently sent to the submission address), the user MAY 396 be notified about this fake confirmation attempt. 398 In other cases the confirmation request is legitimate and the MUA 399 shall silently send a response as described in the next section. 401 The rationale for the outer signature used with this request is to 402 allow early detection of spam mails. This can be done prior to the 403 decryption step and avoids asking the user to enter a passphrase to 404 perform the decryption for a non-legitimate message. The use of a 405 simple encrypted attachment, instead of using PGP/MIME encryption, is 406 to convey the Content-Type of that attachment in the clear and also 407 to prevent automatic decryption of that attachment by PGP/MIME aware 408 clients. The MUA may in fact detect this confirmation request and 409 present a customized dialog for confirming that request. 411 4.4. The Confirmation Response 413 A response to a confirmation request MUST only be send in the 414 positive case; there is no negative confirmation response. A mail 415 service provider is expected to cancel a pending key submission after 416 a suitable time without a confirmation. The mail service provider 417 SHOULD NOT retry the sending of a confirmation request after the 418 first request has been send successfully. 420 The user MUST send the confirmation response from her target mail 421 address to the "from" address of the confirmation request. The 422 message MUST be signed and encrypted using the PGP/MIME Combined 423 format ([RFC3156], section 6.2). The signing key is the target key 424 and the encryption key is the key associated with the provider's 425 submission address. 427 The Content-Type used for the plaintext message MUST match the 428 Content-Type of the request. The format is the same as described 429 above for the Confirmation Request. The body must contain four name- 430 value pairs in this order: 432 o "type": The value must be "confirmation-response". 434 o "sender": The value is the value of the "sender" parameter from 435 the confirmation request. 437 o "address": The value is the value of the "address" parameter from 438 the confirmation request. 440 o "nonce": The value is the value of the "nonce" parameter from the 441 confirmation request. 443 4.5. Policy Flags 445 For key generation and submission it is useful to tell the client 446 about certain properties of the mail provider in advance. This can 447 be done with a file at the URL 449 WELLKNOWN/policy 451 A site supporting the Web Key Directory MUST serve this file; it is 452 sufficient if that file has a zero length. Clients may use this file 453 to check for Web Key Directory support. 455 The file contains keywords and optionally values, one per line with 456 each line terminated by a LF or the sequence of CR and LF. Empty 457 lines and lines starting with a "#" character are considered comment 458 lines. A keyword is made up of lowercase letters, digits, hyphens, 459 or dots. An underscore is allowed as a name space delimiters; see 460 below. The first character must be a letter. Keywords which are 461 defined to require a value are directly followed by a colon and then 462 after optional white space the value. Clients MUST use case- 463 insensitive matching for the keyword. 465 Currently defined keywords are: 467 o "mailbox-only": The mail server provider does only accept keys 468 with only a mailbox in the User ID. In particular User IDs with a 469 real name in addition to the mailbox will be rejected as invalid. 471 o "dane-only": The mail server provider does not run a Web Key 472 Directory but only an OpenPGP DANE service. The Web Key Directory 473 Update protocol is used to update the keys for the DANE service. 475 o "auth-submit": The submission of the mail to the server is done 476 using an authenticated connection. Thus the submitted key will be 477 published immediately without any confirmation request. 479 o "protocol-version": This keyword can be used to explicitly claim 480 the support of a specific version of the Web Key Directory update 481 protocol. This is in general not needed but implementations may 482 have workarounds for providers which only support an old protocol 483 version. If these providers update to a newer version they should 484 add this keyword so that the implementation can disable the 485 workaround. The value is an integer corresponding to the 486 respective draft revision number. 488 o "submission-address": An alternative way to specify the submission 489 address. The value is the addr-spec part of the address to send 490 requests to this server. If this keyword is used in addition to 491 the "submission-address" file, both MUST have the same value. 493 More keywords will be defined in updates to this I-D. There is no 494 registry except for this document. For experimental use of new 495 features or for provider specific settings, keywords MUST be prefixed 496 with a domain name and an underscore. 498 5. Security Considerations 500 The use of SHA-1 for the mapping of the local-part to a fixed string 501 is not a security feature but merely used to map the local-part to a 502 fixed-sized string made from a well defined set of characters. It is 503 not intended to conceal information about a mail address. 505 The domain name part of the mail address is not part of the hash to 506 avoid problems with internationalized domain names. Instead a 507 separate URL is required for each domain name. 509 To make it a bit harder to test for published keys, the server 510 responsible to serve the WELLKNOWN directory SHOULD NOT create an 511 index file for that directory or any sub-directory. 513 The mail provider MUST make sure to publish a key in a way that only 514 the mail address belonging to the requested user is part of the User 515 ID packets included in the returned key. Other User ID packets and 516 their associated binding signatures MUST be removed before 517 publication. Confirmation requests MUST only be send for such to be 518 published User ID. It is further recommended that a client filters a 519 received key or a key send for a publication requests so that only 520 the specific User ID with the mail address of the provider is 521 imported or send. 523 A client MUST NOT accept a HTTP authentication challenge (HTTP code 524 401) because the information in the Web Key Directory is public and 525 needs no authentication. Allowing an authentication challenge has 526 the problem to easily confuse a user with a password prompt and 527 tricking him into falsely entering the passphrase used to protect his 528 private key or to login to his mail provider. 530 The use of DNS SRV records as specified in former revisions of this 531 document reduces the certainty that a mail address belongs to a 532 domain. For example an attacker may change the target to a host in a 533 sub-domain under their control and thus gain full control over all 534 keys. 536 6. IANA Considerations 538 6.1. Well-Known URI 540 IANA is requested to assign a well-known URI in the "Well-Known URIs" 541 registry as defined by [RFC8615]: 543 URI suffix: openpgpkey 545 Change controller: IETF 547 Specification document: This 549 7. Acknowledgments 551 The author would like to acknowledge the help of the individuals who 552 kindly voiced their opinions on the GnuPG mailing lists, in 553 particular, the help of Bernhard Reiter and Guilhem Moulin. 555 8. Normative References 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, March 1997. 560 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 561 "MIME Security with OpenPGP", RFC 3156, August 2001. 563 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 564 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 566 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 567 Media Path Key Agreement for Unicast Secure RTP", 568 RFC 6189, DOI 10.17487/RFC6189, April 2011, 569 . 571 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 572 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 573 . 575 Appendix A. Sample Protocol Run 577 The following non-normative example can be used by implementors as 578 guidance. 580 Note that GnuPG version 2.1.12 supports the key discovery described 581 in version -00 of this document (auto-key-locate method "wkd"). 582 Version 2.1.16 can run the protocol described in this document but is 583 also able to run the protocol version specified by -01. For backward 584 compatibility this example uses the Content-Type as required for 585 versions of this protocol prior to -04; if the client knows that the 586 server support -04 "vnd.gnupg.wkd" should be used. 588 A.1. Sample Keys 590 This is the provider's submission key: 592 -----BEGIN PGP PRIVATE KEY BLOCK----- 594 lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT 595 FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt 596 c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI 597 CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a 598 BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW 599 C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s 600 Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL 601 iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D 602 My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG 603 HFAD 604 =Hnwd 605 -----END PGP PRIVATE KEY BLOCK----- 607 This is the target key to be published: 609 -----BEGIN PGP PRIVATE KEY BLOCK----- 611 lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL 612 nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy 613 aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV 614 CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj 615 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK 616 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs 617 qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP 618 PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx 619 Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW 620 TiFZBA== 621 =GHi7 622 -----END PGP PRIVATE KEY BLOCK----- 624 A.2. Sample Messages 626 The first message triggers the publication requests. 628 From: patrice.lumumba@example.net 629 To: key-submission@example.net 630 Subject: Key publishing request 631 MIME-Version: 1.0 632 Content-Type: multipart/encrypted; 633 protocol="application/pgp-encrypted"; 634 boundary="=-=01-e8k41e11ob31eefa36wo=-=" 635 Date: Wed, 05 Oct 2016 10:15:51 +0000 637 --=-=01-e8k41e11ob31eefa36wo=-= 638 Content-Type: application/pgp-encrypted 640 Version: 1 642 --=-=01-e8k41e11ob31eefa36wo=-= 643 Content-Type: application/octet-stream 645 -----BEGIN PGP MESSAGE----- 647 hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw 648 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML 649 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj 650 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N 651 ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb 652 wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk 653 n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF 654 jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf 655 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR 656 ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1 657 Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm 658 J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx 659 R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr 660 iM7PY4fwAHo890Dx+Qlt 661 =WIhx 662 -----END PGP MESSAGE----- 664 --=-=01-e8k41e11ob31eefa36wo=-=-- 666 The server decrypts this message to 667 Content-Type: application/pgp-keys 669 -----BEGIN PGP PUBLIC KEY BLOCK----- 671 mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL 672 nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d 673 AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT 674 OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj 675 AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3 676 CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo 677 KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty 678 OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ= 679 =qRfF 680 -----END PGP PUBLIC KEY BLOCK----- 682 and returns this confirmation request 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 692 --=-=01-wrzqued738dfx4x97u7y=-= 693 Content-Type: application/pgp-encrypted 695 Version: 1 697 --=-=01-wrzqued738dfx4x97u7y=-= 698 Content-Type: application/octet-stream 700 -----BEGIN PGP MESSAGE----- 702 hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw 703 FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw 704 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/ 705 zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx 706 NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo 707 MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z 708 MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6 709 KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA== 710 =Cdjh 711 -----END PGP MESSAGE----- 713 --=-=01-wrzqued738dfx4x97u7y=-=-- 715 The client decrypts this PGP/MIME message as 717 Content-Type: application/vnd.gnupg.wks 718 Content-Transfer-Encoding: 8bit 720 type: confirmation-request 721 sender: key-submission@example.net 722 address: patrice.lumumba@example.net 723 fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A 724 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7 726 creates this response 727 Content-Type: application/vnd.gnupg.wks 728 Content-Transfer-Encoding: 8bit 730 type: confirmation-response 731 sender: key-submission@example.net 732 address: patrice.lumumba@example.net 733 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7 735 and sends it PGP/MIME Combined signed and encrypted to the server 737 From: patrice.lumumba@example.net 738 To: key-submission@example.net 739 Subject: Key publication confirmation 740 MIME-Version: 1.0 741 Content-Type: multipart/encrypted; 742 protocol="application/pgp-encrypted"; 743 boundary="=-=01-iacqg4og4pqz11a5cg1o=-=" 744 Date: Wed, 05 Oct 2016 10:18:52 +0000 746 --=-=01-iacqg4og4pqz11a5cg1o=-= 747 Content-Type: application/pgp-encrypted 749 Version: 1 751 --=-=01-iacqg4og4pqz11a5cg1o=-= 752 Content-Type: application/octet-stream 754 -----BEGIN PGP MESSAGE----- 756 hF4DUgLY5tvmW2sSAQdAlq98ugycHadQGRe0+055eGUzdQtORR+u5LuJU+oYXHkw 757 4V1z0S1QPO9BWixHA62PtjAOShT2xN+1v8T2gq3mdgCEMCHX/Nj6INuu+HXF8o0D 758 0sC5AfEwq24oKF/6Q8vb1L/KUzFeitnWBnxS1i9XONlG9FTpSGfBir9szqz3QtMu 759 8Sma+X4g/i/rbO5ZtY9v0r+NCh0fY+fMj8Iaqw8IJUcUWcL2oz+GaHU+CIaJWUyk 760 suqjw5Zw9WVPQ2nXHZTVOKPk4b8Y8f34GvoqP9ZyVFhZ+/9xcvE3fHOoZKeIK9Yi 761 4Bxza2HvWRkkKc48Orf5AjK45Wm/G72m72d/KiYfzBm0W4T5QkVqRnX+vpoQc+bo 762 thEE715ma9SnZMcY3fRcPnhjlDxDneB5DD7WNdiz+wZL0OiHW/kT8Eo4/OZnb72M 763 t44hd8xB8wbfhz5/zmgmlG4IGGA4MomZyg7G/fo24xaIqkjgnJ1GryWaztNQM6Xx 764 34kDLTF1fkjqmMZOtTEFKwC5dzrp1qb7B4ZWsFXC+bSLC5teaRajmOr4T5tXCFV7 765 TL0gNBsg/bRBU6wmFDaOaJjleoTsh/7YNJaMsoiMx7NrHe+uVqaEbE4HsWU= 766 =tlCO 767 -----END PGP MESSAGE----- 769 --=-=01-iacqg4og4pqz11a5cg1o=-=-- 771 Appendix B. Changes Since -13 773 o Fixed description of the confiration response 775 o Fixed an example to be signed+encrypted 777 o Clarified some inconsistencies 779 Author's Address 781 Werner Koch 782 GnuPG e.V. 783 Rochusstr. 44 784 40479 Duesseldorf 785 Germany 787 Email: wk@gnupg.org 788 URI: https://gnupg.org/verein