OpenPGP Web Key Directory
draft-koch-openpgp-webkey-service-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Werner Koch | ||
| Last updated | 2018-11-13 (Latest revision 2018-05-18) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-koch-openpgp-webkey-service-07
Network Working Group A. Bashandy, Ed.
Internet Draft C. Filsfils
Intended status: Informational Cisco Systems
Expires: December 2016 P. Mohapatra
Sproute Networks
June 20, 2016
BGP Prefix Independent Convergence
draft-ietf-rtgwg-bgp-pic-01.txt
Abstract
In the network comprising thousands of iBGP peers exchanging millions
of routes, many routes are reachable via more than one next-hop.
Given the large scaling targets, it is desirable to restore traffic
after failure in a time period that does not depend on the number of
BGP prefixes. In this document we proposed an architecture by which
traffic can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding data
structures in a hierarchical manner and sharing forwarding elements
among the maximum possible number of routes. The proposed technique
achieves prefix independent convergence while ensuring incremental
deployment, complete automation, and zero management and provisioning
effort. It is noteworthy to mention that the benefits of BGP-PIC are
hinged on the existence of more than one path whether as ECMP or
primary-backup.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Bashandy Expires December 20, 2016 [Page 1]
Internet-Draft BGP Prefix Independent Convergence June 2016
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 20, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
1.1. Conventions used in this document.........................4
1.2. Terminology...............................................4
2. Overview.......................................................5
3. Constructing the Shared Hierarchical Forwarding Chain..........7
3.1. Example 1: Primary-Backup Path Scenario...................8
3.2. Example 2: Platforms with Limited Levels of Hierarchy.....9
4. Forwarding Behavior...........................................13
5. Forwarding Chain Adjustment at a Failure......................15
5.1. BGP-PIC core.............................................16
5.2. BGP-PIC edge.............................................17
5.2.1. Adjusting forwarding Chain in egress node failure...17
5.2.2. Adjusting Forwarding Chain on PE-CE link Failure....17
5.3. Handling Failures for Flattended Forwarding Chains.......18
6. Properties....................................................19
6.1. Coverage.................................................19
6.1.1. A remote failure on the path to a BGP next-hop......19
Bashandy Expires December 20, 2016 [Page 2]
Internet-Draft BGP Prefix Independent Convergence June 2016
6.1.2. A local failure on the path to a BGP next-hop.......19
6.1.3. A remote iBGP next-hop fails........................20
6.1.4. A local eBGP next-hop fails.........................20
6.2. Performance..............................................20
6.2.1. Perspective.........................................20
6.3. Automated................................................21
6.4. Incremental Deployment...................................22
7. Dependency....................................................22
7.1. Hierarchical Hardware FIB................................22
7.2. Availability of more than one primary or secondary BGP next-
hops..........................................................22
7.3. Pre-Computation of a secondary BGP next-hop..............23
8. Security Considerations.......................................23
9. IANA Considerations...........................................23
10. Conclusions..................................................23
11. Acknowledgments..............................................25
12. References...................................................23
12.1. Normative References....................................23
12.2. Informative References..................................24
1. Introduction
As a path vector protocol, BGP is inherently slow due to the
serial nature of reachability propagation. BGP speakers exchange
reachability information about prefixes[2][3] and, for labeled
address families, namely AFI/SAFI 1/4, 2/4, 1/128, and 2/128, an
edge router assigns local labels to prefixes and associates the
local label with each advertised prefix such as L3VPN [8], 6PE
[9], and Softwire [7] using BGP label unicast technique[4]. A BGP
speaker then applies the path selection steps to choose the best
path. In modern networks, it is not uncommon to have a prefix
reachable via multiple edge routers. In addition to proprietary
techniques, multiple techniques have been proposed to allow for
BGP to advertise more than one path for a given prefix
[6][11][12], whether in the form of equal cost multipath or
primary-backup. Another more common and widely deployed scenario
is L3VPN with multi-homed VPN sites with unique Route
Distinguisher.
This document proposes a hierarchical and shared forwarding chain
organization that allows traffic to be restored to pre-calculated
alternative equal cost primary path or backup path in a time
period that does not depend on the number of BGP prefixes. The
technique relies on internal router behavior that is completely
transparent to the operator and can be incrementally deployed and
enabled with zero operator intervention.
Bashandy Expires December 20, 2016 [Page 3]
Internet-Draft BGP Prefix Independent Convergence June 2016
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC-2119
[1].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to
be interpreted as carrying RFC-2119 significance.
1.2. Terminology
This section defines the terms used in this document. For ease of
use, we will use terms similar to those used by L3VPN [8]
o BGP prefix: It is a prefix P/m (of any AFI/SAFI) that a BGP
speaker has a path for.
o IGP prefix: It is a prefix P/m (of any AFI/SAFI) that is learnt
via an Interior Gateway Protocol, such as OSPF and ISIS, has a
path for. The prefix may be learnt directly through the IGP or
redistributed from other protocol(s)
o CE: It is an external router through which an egress PE can
reach a prefix P/m.
o Ingress PE, "iPE": t is a BGP speaker that learns about a prefix
through a IBGP peer and chooses an egress PE as the next-hop for
the prefix..
o Path: It is the next-hop in a sequence of unique connected
nodes starting from the current node and ending with the
destination node or network identified by the prefix.
o Recursive path: It is a path consisting only of the IP address
of the next-hop without the outgoing interface. Subsequent
lookups are needed to determine the outgoing interface.
o Non-recursive path: It is a path consisting of the IP address
of the next-hop and one outgoing interface
o Primary path: It is a recursive or non-recursive path that can
be used all the time. A prefix can have more than one primary
path
o Backup path: It is a recursive or non-recursive path that can
be used only after some or all primary paths become unreachable
Bashandy Expires December 20, 2016 [Page 4]
Internet-Draft BGP Prefix Independent Convergence June 2016
o Leaf: A leaf is container data structure for a prefix or local
label. Alternatively, it is the data structure that contains
prefix specific information.
o IP leaf: Is the leaf corresponding to an IPv4 or IPv6 prefix
o Label leaf. It is the leaf corresponding to a locally allocated
label such as the VPN label on an egress PE [8].
o Pathlist: It is an array of paths used by one or more prefix to
forward traffic to destination(s) covered by a IP prefix. Each
path in the pathlist carries its "path-index" that identifies
its position in the array of paths. A pathlist may contain a
mix of primary and backup paths
o OutLabel-List: Each labeled prefix is associated with an
OutLabel-List. The OutLabel-List is an array of one or more
outgoing labels and/or label actions where each label or label
action has 1-to-1 correspondence to a path in the pathlist.
Label actions are: push the label, pop the label, or swap the
incoming label with the label in the Outlabel-Array entry. The
prefix may be an IGP or BGP prefix
o Adjacency: It is the layer 2 encapsulation leading to the layer
3 directly connected next-hop
o Dependency: An object X is said to be a dependent or Child of
object Y if Object Y cannot be deleted unless object X is no
longer a dependent/child of object Y
o Route: It is a prefix with one or more paths associated with
it. Hence the minimum set of objects needed to construct a
route is a leaf and a pathlist.
2. Overview
The idea of BGP-PIC is based on two pillars
o A shared hierarchal Forwarding Chain
o A forwarding plane that supports multiple levels of indirection
To illustrate the two pillars above, we will use an example of a
simple multihomed L3VPN [8] prefix in a BGP-free core running LDP
[5] or segment routing over MPLS forwarding plane [14].
Bashandy Expires December 20, 2016 [Page 5]
Internet-Draft BGP Prefix Independent Convergence June 2016
+--------------------------------+
| |
| ePE2
| | \
| | \
| | \
iPE | CE.......VRF "Blue"
| | / (VPN-IP1)
| | / (VPN-IP2)
| LDP/Segment-Routing Core | /
| ePE1
| |
+--------------------------------+
Figure 1 VPN prefix reachable via multiple PEs
Referring to Figure 1, suppose the iPE (the ingress PE) receives
NLRIs for the VPN prefixes VPN-IP1 and VPN-IP2 from two egress PEs,
ePE1 and ePE2 with next-hop BGP-NH1 and BGP-NH2, respectively.
Assume that ePE1 advertise the VPN labels VPN-L11 and VPN-L12 while
ePE2 advertise the VPN labels VPN-L21 and VPN-L22 for VPN-IP1 and
VPN-IP2, respectively. Suppose that BGP-NH1 and BGP-NH2 are resolved
via the IGP prefixes IGP-IP1 and IGP-P2, where each happen to have 2
ECMP paths with IGP-NH1 and IGP-NH2 reachable via the interfaces I1
and I2, respectively. Suppose that local labels (whether LDP[5] or
segment routing [14]) on the downstream LSRs for IGP-IP1 are IGP-L11
and IGP-L12 while for IGP-P2 are IGP-L21 and IGP-L22.
Based on the information about NLRIs and the resolving IGP prefixes,
a hierarchical forwarding chain can be constructed as shown in
Figure 2.
IP Leaf: Pathlist: IP Leaf: Pathlist:
-------- +-------+ -------- +----------+
VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP NH1,I1|--->Adjacency1
| |BGP-NH2|-->.... | |IGP NH2,I2|--->Adjacency2
| +-------+ | +----------+
| |
| |
v v
OutLabel-List: OutLabel-List:
+----------------------+ +----------------------+
|VPN-L11 (VPN-IP1, NH1)| |IGP-L11 (IGP-IP1, NH1)|
|VPN-L12 (VPN-IP1, NH2)| |IGP-L12 (IGP-IP1, NH2)|
+----------------------+ +----------------------+
Figure 2 Shared Hierarchical Forwarding Chain at iPE
The forwarding chain depicted in Figure 2 illustrates the first
pillar, which is sharing and hierarchy. We can see that the BGP
Bashandy Expires December 20, 2016 [Page 6]
Internet-Draft BGP Prefix Independent Convergence June 2016
pathlist consisting of BGP-NH1 and BGP-NH2 is shared by all NLRIs
reachable via ePE1 and ePE2. As such, it is possible to make changes
to the pathlist without having to make changes to the NLRIs. For
example, if BGP-NH2 becomes unreacreachable, there is no need to
modify any of the possibly large number of NLRIs. Instead only the
shared pathlist needs to be modified. Likewise, due to the
hierarchical structure of the forwarding chain, it is possible to
make modifications to the IGP routes without having to make any
changes to the BGP NLRIs. For example, if the interface "I2&
o "nonce": The value is the value of the "nonce" parameter from the
confirmation request.
4.5. Policy Flags
For key generation and submission it is useful to tell the client
about certain properties of the mail provider in advance. This can
be done with a file at the URL
WELLKNOWN/policy
A site supporting the Web Key Directory MUST serve this file; it is
sufficient if that file has a zero length. Clients may use this file
to check for Web Key Directory support.
The file contains keywords and optionally values, one per line with
each line terminated by a LF or the sequence of CR and LF. Empty
lines and lines starting with a '#' character are considered comment
lines. A keyword is made up of lowercase letters, digits, hyphens,
or dots. An underscore is allowed as a name space delimiters; see
below. The first character must be a letter. Keywords which are
defined to require a value are directly followed by a colon and then
after optional white space the value. Clients MUST use case-
insensitive matching for the keyword.
Currently defined keywords are:
o "mailbox-only": The mail server provider does only accept keys
with only a mailbox in the User ID. In particular User IDs with a
real name in addition to the mailbox will be rejected as invalid.
o "dane-only": The mail server provider does not run a Web Key
Directory but only an OpenPGP DANE service. The Web Key Directory
Update protocol is used to update the keys for the DANE service.
o "auth-submit": The submission of the mail to the server is done
using an authenticated connection. Thus the submitted key will be
published immediately without any confirmation request.
o "protocol-version": This keyword can be used to explicitly claim
the support of a specific version of the Web Key Directory update
protocol. This is in general not needed but implementations may
have workarounds for providers which only support an old protocol
version. If these providers update to a newer version they should
add this keyword so that the implementation can disable the
workaround. The value is an integer corresponding to the
respective draft revision number.
Koch Expires May 17, 2019 [Page 10]
Internet-Draft OpenPGP Web Key Directory November 2018
o "submission-address": An alternative way to specify the submission
address. The value is the addr-spec part of the address to send
requests to this server. If this keyword is used in addition to
the "submission-address" file, both MUST have the same value.
More keywords will be defined in updates to this I-D. There is no
registry except for this document. For experimental use of new
features or for provider specific settings, keywords MUST be prefixed
with a domain name and an underscore.
5. Security Considerations
The use of SHA-1 for the mapping of the local-part to a fixed string
is not a security feature but merely used to map the local-part to a
fixed-sized string made from a well defined set of characters. It is
not intended to conceal information about a mail address.
The domain name part of the mail address is not part of the hash to
avoid problems with internationalized domain names. Instead a
separate URL is required for each domain name.
The use of DNS SRV records reduces the certainty that a mail address
belongs to a domain. For example an attacker may change the target
to a host in a sub-domain under their control and thus gain full
control over all keys. An implementation may want to weight the
certainty of a mapping different if it has been retrieved via a sub-
domain and in particular if a non-recommended name is used for the
sub-domain.
To make it a bit harder to test for published keys, the server
responsible to serve the WELLKNOWN directory SHOULD NOT create an
index file for that directory or any sub-directory.
The mail provider MUST make sure to filter a key in a way that only
the User ID belonging to that user is returned and that confirmation
requests are only send for such User IDs. It is further recommended
that a client filters the key for a publication requests so that only
a key with the specific User ID of the provider is send.
6. IANA Considerations
6.1. Well-Known URI
IANA is requested to assign a well-known URI in the "Well-Known URIs"
registry as defined by [RFC5785]:
URI suffix: openpgpkey
Koch Expires May 17, 2019 [Page 11]
Internet-Draft OpenPGP Web Key Directory November 2018
Change controller: IETF
Specification document: This
7. Acknowledgments
The author would like to acknowledge the help of the individuals who
kindly voiced their opinions on the GnuPG mailing lists, in
particular, the help of Bernhard Reiter and Guilhem Moulin.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, <https://www.rfc-
editor.org/info/rfc2782>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, DOI
10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP", RFC
6189, DOI 10.17487/RFC6189, April 2011,
<http://www.rfc-editor.org/info/rfc6189>.
Appendix A. Sample Protocol Run
The following non-normative example can be used by implementors as
guidance.
Note that GnuPG version 2.1.12 supports the key discovery described
in version -00 of this document (auto-key-locate method "wkd").
Version 2.1.16 can run the protocol described in this document but is
also able to run the protocol version specified by -01. For backward
compatibility this example uses the Content-Type as required for
versions of this protocol prior to -04; if the client knows that the
server support -04 "vnd.gnupg.wkd" should be used.
Koch Expires May 17, 2019 [Page 12]
Internet-Draft OpenPGP Web Key Directory November 2018
A.1. Sample Keys
This is the provider's submission key:
-----BEGIN PGP PRIVATE KEY BLOCK-----
lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
HFAD
=Hnwd
-----END PGP PRIVATE KEY BLOCK-----
This is the target key to be published:
-----BEGIN PGP PRIVATE KEY BLOCK-----
lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
TiFZBA==
=GHi7
-----END PGP PRIVATE KEY BLOCK-----
A.2. Sample Messages
The first message triggeres the publication requests.
Koch Expires May 17, 2019 [Page 13]
Internet-Draft OpenPGP Web Key Directory November 2018
From: patrice.lumumba@example.net
To: key-submission@example.net
Subject: Key publishing request
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="=-=01-e8k41e11ob31eefa36wo=-="
Date: Wed, 05 Oct 2016 10:15:51 +0000
--=-=01-e8k41e11ob31eefa36wo=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=01-e8k41e11ob31eefa36wo=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
iM7PY4fwAHo890Dx+Qlt
=WIhx
-----END PGP MESSAGE-----
--=-=01-e8k41e11ob31eefa36wo=-=--
The server decrypts this message to
Koch Expires May 17, 2019 [Page 14]
Internet-Draft OpenPGP Web Key Directory November 2018
Content-Type: application/pgp-keys
-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
=qRfF
-----END PGP PUBLIC KEY BLOCK-----
and returns this confirmation request
Koch Expires May 17, 2019 [Page 15]
Internet-Draft OpenPGP Web Key Directory November 2018
From: key-submission@example.net
To: patrice.lumumba@example.net
Subject: Confirm your key publication
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="=-=01-wrzqued738dfx4x97u7y=-="
Date: Wed, 05 Oct 2016 10:16:57 +0000
--=-=01-wrzqued738dfx4x97u7y=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=01-wrzqued738dfx4x97u7y=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
=Cdjh
-----END PGP MESSAGE-----
--=-=01-wrzqued738dfx4x97u7y=-=--
The client decrypts the attachment as
Content-Type: application/vnd.gnupg.wks
Content-Transfer-Encoding: 8bit
type: confirmation-request
sender: key-submission@example.net
address: patrice.lumumba@example.net
fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
creates this response
Koch Expires May 17, 2019 [Page 16]
Internet-Draft OpenPGP Web Key Directory November 2018
Content-Type: application/vnd.gnupg.wks
Content-Transfer-Encoding: 8bit
type: confirmation-response
sender: key-submission@example.net
address: patrice.lumumba@example.net
nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
and sends it encrypted to the server
From: patrice.lumumba@example.net
To: key-submission@example.net
Subject: Key publication confirmation
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
Date: Wed, 05 Oct 2016 10:18:52 +0000
--=-=01-iacqg4og4pqz11a5cg1o=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=01-iacqg4og4pqz11a5cg1o=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
=7uve
-----END PGP MESSAGE-----
--=-=01-iacqg4og4pqz11a5cg1o=-=--
Appendix B. Changes Since -06
o Specify the advanced method with the openpgpkey sub-domain.
o Specify the l=LOCAL-PART query parameter.
Koch Expires May 17, 2019 [Page 17]
Internet-Draft OpenPGP Web Key Directory November 2018
o Require the provider to filter the key for publication.
o Drop the use of DNS SRV records.
Author's Address
Werner Koch
GnuPG e.V.
Rochusstr. 44
40479 Duesseldorf
Germany
Email: wk@gnupg.org
URI: https://gnupg.org/verein
Koch Expires May 17, 2019 [Page 18]