idnits 2.17.1 draft-koch-openpgp-webkey-service-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2017) is 2321 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Project 4 Intended status: Informational November 20, 2017 5 Expires: May 24, 2018 7 OpenPGP Web Key Directory 8 draft-koch-openpgp-webkey-service-05 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 http://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 May 24, 2018. 34 Copyright Notice 36 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . 5 56 4.1. The Submission Address . . . . . . . . . . . . . . . . . 6 57 4.2. The Submission Mail . . . . . . . . . . . . . . . . . . . 6 58 4.3. The Confirmation Request . . . . . . . . . . . . . . . . 7 59 4.4. The Confirmation Response . . . . . . . . . . . . . . . . 8 60 4.5. Policy Flags . . . . . . . . . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 6.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 66 Appendix A. Sample Protocol Run . . . . . . . . . . . . . . . . 11 67 A.1. Sample Keys . . . . . . . . . . . . . . . . . . . . . . . 12 68 A.2. Sample Messages . . . . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Changes Since -04 . . . . . . . . . . . . . . . . . 16 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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. To form the URI, the following parts are 150 concatenated: 152 o The scheme "https://", 154 o the domain-part, 156 o the string "/.well-known/openpgpkey/hu/", 158 o and the above constructed 32 octet string. 160 For example the URI to lookup the key for Joe.Doe@Example.ORG is: 162 https://example.org/.well-known/openpgpkey/ 163 hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q 165 (line has been wrapped for rendering purposes) 167 DNS SRV resource records ([RFC2782]) may be used to query a different 168 host or a port other than 443. For example: 170 _openpgpkey._tcp.example.org. IN SRV 0 0 8443 wkd.example.org. 172 changes the above to query the host "wkd.example.org" at port 8443 173 instead of the host "example.org" at port 443. The target (in the 174 example "wkd.example.org") MUST be a sub-domain of the domain-part 175 (here "example.org"). If the target is not a sub-domain, the SRV RR 176 MUST be be ignored. The recommended name for the sub-domain is 177 "wkd". 179 The HTTP GET method MUST return the binary representation of the 180 OpenPGP key for the given mail address. The key needs to carry a 181 User ID packet ([RFC4880]) with that mail address. Note that the key 182 may be revoked or expired - it is up to the client to handle such 183 conditions. To ease distribution of revoked keys, a server may 184 return revoked keys in addition to a new key. The keys are returned 185 by a single request as concatenated key blocks. 187 The server MUST accept the HTTP HEAD method to allow a client to 188 check for the existence of a key. 190 The server SHOULD use "application/octet-string" as the Content-Type 191 for the data but clients SHOULD also accept any other Content-Type. 192 The server MUST NOT return an ASCII armored version of the key. 194 The server MUST serve a Policy Flags file as specified below. That 195 file is even required if the Web Key Directory Update Protocol is not 196 supported. 198 4. Web Key Directory Update Protocol 200 To put keys into the key directory a protocol to automate the task is 201 desirable. The protocol defined here is entirely based on mail and 202 the assumption that a mail provider can securely deliver mail to the 203 INBOX of a user (e.g. an IMAP folder). Note that the same protocol 204 may also be used for submitting keys for use with OpenPGP DANE. 206 We assume that the user already created a key for her mail account 207 alice@example.org. To install the key at her provider's Web Key 208 Directory, she performs the following steps: 210 1. She retrieves a file which contains one line with the mail 211 address used to submit the key to the mail provider. The DNS SRV 212 rules described for the Web Key Directory apply here as well. 213 See below for the syntax of that file. For a mail address at the 214 domain "example.org" the URI of the file is 216 https://example.org/.well-known/openpgpkey/submission-address 218 2. She sends her key using SMTP (or any other transport mechanism) 219 to the provider using the submission address and key format as 220 specified by PGP/MIME. 222 3. The provider checks that the received key has a User ID which 223 matches an account name of the provider. 225 4. The provider sends an encrypted message containing a nonce and 226 the fingerprint of the key to the mail account of the user. Note 227 that a similar scheme is used by the well known caff(1) tool to 228 help with key signing parties. 230 5. A legitimate user will be able to decrypt the message because she 231 created the key and is in charge of the private key. This step 232 verifies that the submitted key has actually been created by the 233 owner of the account. 235 6. The user sends the decrypted nonce back to the submission address 236 as a confirmation that the private key is owned by her and that 237 the provider may now publish the key. Although technically not 238 required, it is suggested that the mail to the provider is 239 encrypted. The public key for this is retrieved using the key 240 lookup protocol described above. 242 7. The provider receives the nonce, matches it with its database of 243 pending confirmations and then publishes the key. Finally the 244 provider sends a mail back to the user to notify her of the 245 publication of her key. 247 The message data structures used for the above protocol are specified 248 in detail below. In the following sections 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://example.org/.well-known/openpgpkey 254 The term "target key" denotes the to be published key, the term 255 "submission key" the key associated with the submission-address of 256 the mail provider. 258 4.1. The Submission Address 260 The address of the submission file is 262 WELLKNOWN/submission-address 264 The file consists of exactly one line, terminated by a LF, or the 265 sequence of CR and LF, with the full mail address to be used for 266 submission of a key to the mail provider. For example the content of 267 the file may be 269 key-submission-example.org@directory.example.org 271 4.2. The Submission Mail 273 The mail used to submit a key to the mail provider MUST comply to the 274 PGP/MIME specification ([RFC3156], section 7), which states that the 275 Content-Type must be "application/pgp-keys", there are no required or 276 optional parameters, and the body part contains the ASCII-armored 277 transferable Public Key Packets as defined in [RFC4880], section 278 11.1. 280 The mail provider MUST publish a key capable of signing and 281 encryption for the submission-address in the Web Key Directory or via 282 DANE. The key to be published MUST be submitted using a PGP/MIME 283 encrypted message ([RFC3156], section 4). The message MUST NOT be 284 signed (because the authenticity of the signing key has not yet been 285 confirmed). After decryption of the message at the mail provider a 286 single "application/pgp-keys" part, as specified above, is expected. 288 4.3. The Confirmation Request 290 The mail provider sends a confirmation mail in response to a received 291 key publication request. The message MUST be sent from the 292 submission-address of the mail provider to the mail address extracted 293 from the target key. The message needs to be a PGP/MIME signed 294 message using the submission key of the provider for the signature. 295 The signed message MUST have two parts: 297 The first part MUST have "text" as its Content-Type and can be used 298 to explain the purpose of the mail. For example it may point to this 299 RFC and explain on how to manually perform the protocol. 301 The second part MUST have "application/vnd.gnupg.wkd" if the protocol 302 version of the server is 5 or later; without a known protocol version 303 or a version less than 5, "application/vnd.gnupg.wks" MUST be used as 304 its Content-Type and carry an OpenPGP encrypted message in ASCII 305 Armor format. The message MUST be encrypted to the target key and 306 MUST NOT be signed. After decryption a text file in the Web Key data 307 format must be yielded. 309 That data format consists of name-value pairs with one name-value 310 pair per LF or CR+LF terminated line. Empty lines are allowed and 311 will be ignored by the receiver. A colon is used to terminate a 312 name. 314 In a confirmation request the following names MUST be send in the 315 specified order: 317 o "type": The value must be "confirmation-request". 319 o "sender": This is the mailbox the user is expected to sent the 320 confirmation response to. The value must match the mailbox part 321 of the "From:" address of this request. Exactly one address MUST 322 be given. 324 o "address": The value is the addr-spec part of the target key's 325 mail address. The value SHOULD match the addr-spec part of the 326 recipient's address. The value MUST be UTF-8 encoded as required 327 for an OpenPGP User ID. 329 o "fingerprint": The value is the fingerprint of the target key. 330 The fingerprint is given in uppercase hex encoding without any 331 interleaving spaces. 333 o "nonce": The value is a string with a minimum length of 16 octets 334 and a maximum length of 64 octets. The string must entirely be 335 made up of random ASCII letters or digits. This nonce will be 336 sent back to the mail provider as proof that the recipient is the 337 legitimate owner of the target-key. 339 The receiver of that message is expected to verify the outer 340 signature and disregard the entire message if it can't be verified or 341 has not been signed by the key associated with the submission 342 address. 344 After the message as been verified the receiver decrypts the second 345 part of the message, checks that the "fingerprint" matches the target 346 key, checks that the "address" matches a User ID of the target key, 347 and checks the other constrains of the request format. If any 348 constraint is not asserted, or the fingerprint or User ID do not 349 match the target key, or there is no pending publication requests 350 (i.e. a mail recently sent o the submission address), the user MAY be 351 notified about this fake confirmation attempt. 353 In other cases the confirmation request is legitimate and the MUA 354 shall silently send a response as described in the next section. 356 The rationale for the outer signature used with this request is to 357 allow early detection of spam mails. This can be done prior to the 358 decryption step and avoids asking the user to enter a passphrase to 359 perform the decryption for a non-legitimate message. The use of a 360 simple encrypted attachment, instead of using PGP/MIME encryption, is 361 to convey the Content-Type of that attachment in the clear and also 362 to prevent automatic decryption of that attachment by PGP/MIME aware 363 clients. The MUA may in fact detect this confirmation request and 364 present a customized dialog for confirming that request. 366 4.4. The Confirmation Response 368 A response to a confirmation request MUST only be send in the 369 positive case; there is no negative confirmation response. A mail 370 service provider is expected to cancel a pending key submission after 371 a suitable time without a confirmation. The mail service provider 372 SHOULD NOT retry the sending of a confirmation request after the 373 first request has been send successfully. 375 The user MUST send the confirmation response from her target mail 376 address to the "from" address of the confirmation request. The 377 message MUST be signed and encrypted using the PGP/MIME Combined 378 format ([RFC3156], section 6.2). The signing key is the target key 379 and the encryption key is the key associated with the provider's 380 submission address. 382 The Content-Type used for the plaintext message MUST match the 383 Content-Type of the request. The format is the same as described 384 above for the Confirmation Request. The body must contain three 385 name-value pairs in this order: 387 o "type": The value must be "confirmation-response". 389 o "sender": The value must match the mailbox part of the "From:" 390 address of this response. Exactly one address MUST be given. 392 o "nonce": The value is the value of the "nonce" parameter from the 393 confirmation request. 395 4.5. Policy Flags 397 For key generation and submission it is useful to tell the client 398 about certain properties of the mail provider in advance. This can 399 be done with a file at the URL 401 WELLKNOWN/policy 403 A site supporting the Web Key Directory MUST serve this file; it is 404 sufficient if that file has a zero length. Clients may use this file 405 to check for Web Key Directory support. 407 The file contains keywords and optioanlly values, one per line with 408 each line terminated by a LF or the sequence of CR and LF. Empty 409 lines and lines starting with a '#' character are considered comment 410 lines. A keyword is made up of lowercase letters, digits, hyphens, 411 or dots. An underscore is allowed as a name space delimiters; see 412 below. The first character must be a letter. Keywords which are 413 defined to require a value are directly followed by a colon and then 414 after optional white space the value. Clients MUST use case- 415 insensitive matching for the keyword. 417 Currently defined keywords are: 419 o "mailbox-only": The mail server provider does only accept keys 420 with only a mailbox in the User ID. In particular User IDs with a 421 real name in addition to the mailbox will be rejected as invalid. 423 o "dane-only": The mail server provider does not run a Web Key 424 Directory but only an OpenPGP DANE service. The Web Key Directory 425 Update protocol is used to update the keys for the DANE service. 427 o "auth-submit": The submission of the mail to the server is done 428 using an authenticated connection. Thus the submitted key will be 429 published immediately without any confirmation request. 431 o "protocol-version": This keyword can be used to explicitly claim 432 the support of a specific version of the Web Key Directory update 433 protocol. This is in general not needed but implementations may 434 have workarounds for providers which only support an old protocol 435 version. If these providers update to a newer version they should 436 add this keyword so that the implementation can disable the 437 workaround. The value is an integer corresponding to the 438 respective draft revision number. 440 More keywords will be defined in updates to this I-D. There is no 441 registry except for this document. For experimental use of new 442 features or for provider specific settings, keywords MUST be prefixed 443 with a domain name and an underscore. 445 5. Security Considerations 447 The use of SHA-1 for the mapping of the local-part to a fixed string 448 is not a security feature but merely used to map the local-part to a 449 fixed-sized string made from a well defined set of characters. It is 450 not intended to conceal information about a mail address. 452 The domain name part of the mail address is not part of the hash to 453 avoid problems with internationalized domain names. Instead a 454 separate URL is required for each domain name. 456 The use of DNS SRV records reduces the certainty that a mail address 457 belongs to a domain. For example an attacker may change the target 458 to a host in a sub-domain under their control and thus gain full 459 control over all keys. An implementation may want to weight the 460 certainty of a mapping different if it has been retrieved via a sub- 461 domain and in particular if a non-recommended name is used for the 462 sub-domain. 464 6. IANA Considerations 466 6.1. Well-Known URI 468 IANA is requested to assign a well-known URI in the "Well-Known URIs" 469 registry as defined by [RFC5785]: 471 URI suffix: openpgpkey 473 Change controller: IETF 475 Specification document: This 477 7. Acknowledgments 479 The author would like to acknowledge the help of the individuals who 480 kindly voiced their opinions on the GnuPG mailing lists, in 481 particular, the help of Bernhard Reiter and Guilhem Moulin. 483 8. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 489 specifying the location of services (DNS SRV)", RFC 2782, 490 DOI 10.17487/RFC2782, February 2000, . 493 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 494 "MIME Security with OpenPGP", RFC 3156, August 2001. 496 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 497 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 499 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 500 Uniform Resource Identifiers (URIs)", RFC 5785, DOI 501 10.17487/RFC5785, April 2010, 502 . 504 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 505 Media Path Key Agreement for Unicast Secure RTP", RFC 506 6189, DOI 10.17487/RFC6189, April 2011, 507 . 509 Appendix A. Sample Protocol Run 511 The following non-normative example can be used by implementors as 512 guidance. 514 Note that GnuPG version 2.1.12 supports the key discovery described 515 in version -00 of this document (auto-key-locate method "wkd"). 516 Version 2.1.16 can run the protocol described in this document but is 517 also able to run the protocol version specified by -01. For backward 518 compatibility this example uses the Content-Type as required for 519 versions of this protocol prior to -04; if the client knows that the 520 server support -04 "vnd.gnupg.wkd" should be used. 522 A.1. Sample Keys 524 This is the provider's submission key: 526 -----BEGIN PGP PRIVATE KEY BLOCK----- 528 lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT 529 FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt 530 c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI 531 CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a 532 BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW 533 C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s 534 Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL 535 iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D 536 My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG 537 HFAD 538 =Hnwd 539 -----END PGP PRIVATE KEY BLOCK----- 541 This is the target key to be published: 543 -----BEGIN PGP PRIVATE KEY BLOCK----- 545 lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL 546 nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy 547 aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV 548 CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj 549 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK 550 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs 551 qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP 552 PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx 553 Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW 554 TiFZBA== 555 =GHi7 556 -----END PGP PRIVATE KEY BLOCK----- 558 A.2. Sample Messages 560 The first message triggeres the publication requests. 562 From: patrice.lumumba@example.net 563 To: key-submission@example.net 564 Subject: Key publishing request 565 MIME-Version: 1.0 566 Content-Type: multipart/encrypted; 567 protocol="application/pgp-encrypted"; 568 boundary="=-=01-e8k41e11ob31eefa36wo=-=" 569 Date: Wed, 05 Oct 2016 10:15:51 +0000 571 --=-=01-e8k41e11ob31eefa36wo=-= 572 Content-Type: application/pgp-encrypted 574 Version: 1 576 --=-=01-e8k41e11ob31eefa36wo=-= 577 Content-Type: application/octet-stream 579 -----BEGIN PGP MESSAGE----- 581 hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw 582 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML 583 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj 584 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N 585 ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb 586 wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk 587 n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF 588 jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf 589 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR 590 ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1 591 Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm 592 J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx 593 R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr 594 iM7PY4fwAHo890Dx+Qlt 595 =WIhx 596 -----END PGP MESSAGE----- 598 --=-=01-e8k41e11ob31eefa36wo=-=-- 600 The server decrypts this message to 601 Content-Type: application/pgp-keys 603 -----BEGIN PGP PUBLIC KEY BLOCK----- 605 mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL 606 nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d 607 AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT 608 OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj 609 AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3 610 CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo 611 KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty 612 OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ= 613 =qRfF 614 -----END PGP PUBLIC KEY BLOCK----- 616 and returns this confirmation request 617 From: key-submission@example.net 618 To: patrice.lumumba@example.net 619 Subject: Confirm your key publication 620 MIME-Version: 1.0 621 Content-Type: multipart/encrypted; 622 protocol="application/pgp-encrypted"; 623 boundary="=-=01-wrzqued738dfx4x97u7y=-=" 624 Date: Wed, 05 Oct 2016 10:16:57 +0000 626 --=-=01-wrzqued738dfx4x97u7y=-= 627 Content-Type: application/pgp-encrypted 629 Version: 1 631 --=-=01-wrzqued738dfx4x97u7y=-= 632 Content-Type: application/octet-stream 634 -----BEGIN PGP MESSAGE----- 636 hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw 637 FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw 638 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/ 639 zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx 640 NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo 641 MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z 642 MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6 643 KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA== 644 =Cdjh 645 -----END PGP MESSAGE----- 647 --=-=01-wrzqued738dfx4x97u7y=-=-- 649 The client decrypts the attachment as 651 Content-Type: application/vnd.gnupg.wks 652 Content-Transfer-Encoding: 8bit 654 type: confirmation-request 655 sender: key-submission@example.net 656 address: patrice.lumumba@example.net 657 fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A 658 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7 660 creates this response 661 Content-Type: application/vnd.gnupg.wks 662 Content-Transfer-Encoding: 8bit 664 type: confirmation-response 665 sender: key-submission@example.net 666 address: patrice.lumumba@example.net 667 nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7 669 and sends it encrypted to the server 671 From: patrice.lumumba@example.net 672 To: key-submission@example.net 673 Subject: Key publication confirmation 674 MIME-Version: 1.0 675 Content-Type: multipart/encrypted; 676 protocol="application/pgp-encrypted"; 677 boundary="=-=01-iacqg4og4pqz11a5cg1o=-=" 678 Date: Wed, 05 Oct 2016 10:18:52 +0000 680 --=-=01-iacqg4og4pqz11a5cg1o=-= 681 Content-Type: application/pgp-encrypted 683 Version: 1 685 --=-=01-iacqg4og4pqz11a5cg1o=-= 686 Content-Type: application/octet-stream 688 -----BEGIN PGP MESSAGE----- 690 hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw 691 ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1 692 0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl 693 5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k 694 OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg 695 dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO 696 ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo= 697 =7uve 698 -----END PGP MESSAGE----- 700 --=-=01-iacqg4og4pqz11a5cg1o=-=-- 702 Appendix B. Changes Since -04 704 o Change to Content-Type "vnd.gnupg.wkd" for servers announcing its 705 support. 707 o Require the existance of the Policy Flags file. 709 o Re-title this I-D to Web Key Directory. 711 Author's Address 713 Werner Koch 714 GnuPG Project 716 Email: wk@gnupg.org 717 URI: https://gnupg.org