sks.disunitedstates.com

For convenience, I have moved all the forms on this page to the top of the page. Explanation is available below.

Most users will be interested in the Query and Add forms. Server operators may be interested in the Server Statistics form.

Query

(Please see disclaimer)

Index choice
Index options
Search

Look up a server's statistics

Server:
Port:

Add

Paste your key here to upload.
Carl Wilhelm Hübner - Stalltür in Dausenau

Introduction

First, this is a keyserver site. If you have no idea what a GnuPG/PGP key is, or what a keyserver is, some helpful links are further down. Information on peering is here.

This site is not about guns. If you were not expecting to find something on guns, then you might not be an afficionado of the SKS rifle. I'm not either.

While different keyserver operators have different motivations for hosting keyservers, I am motivated by a desire to protect privacy against incursions from multiple sources, especially including the U.S. government. Please support the American Civil Liberties Union (ACLU) and Electronic Frontier Foundation. You may also throw some bitcoin (address: bitcoin:1tJGjYTw7HAWoTttgDgCUYmDMPgSCw5E2?label=first) my way.

This is sks.disunitedstates.com, a mostly private keyserver providing HKP access to keys on ports 11371, 443, and 80 (you may copy these links into your client configuration). Your access to this site is protected with a class 2 SSL certificate issued by a generally recognized authority and which uses a 4096-bit key (the usual length is 2048). This server supports perfect forward secrecy.

The choice to use a recognizable key enables the public to access this interface using SSL with confidence but also means that this server does not participate in the HKPS pool. (See here on this page.) This site does participate in other pools, both keeping itself up to date and contributing to the robustness of those pools. The security rating of this site or of any site may be checked using the Qualys SSL Labs SSL Server Test.

This service may be withdrawn at any time and without notice to end-users. (Peers will be notified.) You should use a pool definition, such as pool.sks-keyservers.net, which will alias into an operational pool, and spread the load. If you have specialized requirements, there are a number of available pools listed here.

Disclaimer

Note: this service is provided free, to the public, in the hopes that it might prove useful. No warranty is provided, nor any offer of continuing service or access. By using this service, you MUST understand that presence of data in the keyserver (pools) in no way connotes trust. Anyone can generate a key, with any name or email address, and upload it. All security and trust comes from evaluating security at the “object level”, via PGP Web-Of-Trust signatures. This keyserver makes it possible to retrieve keys, looking them up via various indices, but the collection of keys in this public pool is KNOWN to contain malicious and fraudulent keys. It is the common expectation of server operators that users understand this and use software which, like all known common OpenPGP implementations, evaluates trust accordingly. This expectation is so common that it is not normally explicitly stated.

(Return to forms)

Contact

For administrative questions, contact David Benfell.

Peering

This keyserver peers as sks.disunitedstates.com and participates in the pool at sks-keyservers.net. Related links: local site statistics, corresponding information at at sks-keyservers.net, and overall pool status.

I often accept SKS-protocol peering requests and I'm willing to set up email-based exchange for non-SKS speakers.

The normal way to obtain peers is to send a message to the SKS-devel mailing list. Be sure that you have properly prepared your server. The SKS software version should be at least 1.1.5 and you should have loaded a recent keydump prior to making your request. Many keyserver operators will want to check your server statistics before agreeing to peer with you. The statistics for this site are available at https://sks.disunitedstates.com/pks/lookup?op=stats.

There is a list of keydump sources here but my own experience is that only some sources listed there work. Dumps are generated here beginning at 4:15 am daily, and should be available by 5:00 am Pacific (U.S.) time. This schedule is subject to change.

The line you would add to your membership file for SKS looks like this:

sks.disunitedstates.com 11370 # David Benfell <benfell@disunitedstates.com> 0x1236602B

Please include a similarly formatted line in your request for peers.

More Information

TLS (HTTPS)

All keyserver clients must use TLS 1.0 or greater, and must send ServerNameIndication in the TLS handshake. While there is no standard stating this, operation of the public keyservers in practice requires it.

Each keyserver implementing TLS is currently doing so with a “reverse proxy” in front of SKS (or equivalent), and the proxy handles TLS termination. In practice, a keyserver can be known by many names and each keyserver operator chooses for themselves what certificate policy they choose for names which identify just their keyserver. Separately, a keyserver DNS pool operator can choose entry criteria for their pool and work with the individual operators to make that work.

At present, there is one public pool collecting HTTPS/TLS servers, hkps.pool.sks-keyservers.net, which this server does not participate in. Membership in that pool uses certificates signed by a root CA certificate (and detached PGP signature) issued by Kristian Fiskerstrand. See the GnuPG configuration instructions on www.sks-keyservers.net/overview-of-pools.php.

Operators generate a key for the relevant vhosts, send a CSR (PGP signed) to Kristian, who issues a TLS X509v3 cert for use for the relevant vhosts. Thus the need for ServerNameIndication. (The sks-keyservers.net root CA cert is also available on this site (signature) and on Phil's security site (signature), where it is available over https with an X.509 TLS certificate issued by a root CA in most common browsers.)

The ServerNameIndication (SNI) sent should be the trusted name supplied by the user (or config) and not derived from DNS (via SRV records), perhaps unless DNSSEC is used. It's simplest (and likely correct) to just mandate “never chase names from SRV, even with DNSSEC present”. This name is used for selecting the certificate, and should then be used for validating the cert during the handshake. (In GnuPG terms, leave “--keyserver-options check-cert” turned on).

The choice of name for SNI is not correctly handled in current GnuPG releases [issue 1447] (awaiting word from GnuPG folks to confirm that they agree this is a bug).

URL formats

The “hkp:” (& “hkps:”) URL scheme is effectively HTTP, with a different default port and a template for constructing a query given a search term. There is no published standard; there was a draft, and today the de-facto rules are “whatever the SKS developers and GnuPG developers agree to between them”.

Thus the default port for HKP is 11371; the default port for HKPS is 443. The SRV records used are for _pgpkey-http._tcp & _pgpkey-https._tcp respectively. Bugs in some releases of GnuPG might cause the port number from the SRV records to be ignored. [issue 1446]

About this page

This page has been adapted, rearranged, and substantially modified from the one on http://sks.spodhuis.org/, as of April 13, 2014, courtesy of Phil Pennock. Phil runs an experimental pool, which this server does not participate in. For information on that pool, see http://sks.spodhuis.org/.

This site is maintained by David Benfell.