0xdeadbeef comes of age: making keysteak with GnuPG

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/10/2014 06:01 PM, David Leon Gil wrote:
> On Fri, Oct 10, 2014 at 11:47 AM, Daniel Kahn Gillmor 
> <dkg at fifthhorseman.net> wrote:
>> If we're going to advocate for accessing keyservers via https
>> (which i think is a lovely idea, even if it doesn't mitigate all
>> possible attacks), it's worth advocating for the well-curated 
>> hkps.pool.sks-keyservers.net [0], rather than encouraging
>> everyone to flood either https://keybase.io or
>> https://pgp.mit.edu with traffic.
> 
> My problem with the HKPS pool is that I don't know Kristian.[1] And
> I don't have any reason to believe that he'd suffer serious
> financial damage if the private key for the "sks-keyservers.net CA"
> got used maliciously.[2]

You are quite correct that I probably wouldn't, and my primary income
is from another industry, but at the same time that does bring a
protection as I wouldn't be discouraged to fight any oppression. Of
course, you can't know my motives and integrity, which is a very fair
argument.

> 
> (While I know that if a root CA were caught intentionally issuing
> an MitM cert for keybase.io or pgp.mit.edu would face likely 
> delisting/bankruptcy.)

The cases we've seen where this happens (turktrust, diginotar) doesn't
really speak to a large financial hit either. Although for the root
CAs the major problem is simply the amount of CAs accepted by standard
implementations, several of which are run by various governments. In
the end it comes down to what the threat model is and whom you're
protecting yourself from.

Currently the only criteria for whether someone gets a certificate for
a server in the pool is based on technical merits and that they are in
control of the server in question. If no such agency were to run a
perfectly valid keyserver under a pseudonym it would not be part of
the current model to exclude this keyserver. However the goal is
primarily to avoid information leakage on transport, in particular
during a refresh of the keyring.

I certainly wouldn't mind coming to the point to have verified each
keyserver operator's identity before issuing a certificate, but we're
not there yet. This might change over time as things mature, but that
is the status today.

> 
> I'd be really happy if Kristian published a GPG-signed log of
> every valid certificate for servers in the HKPS pool; then it would
> be possible for the distrustful -- or targeted -- to, say, query
> multiple HKPS keyservers. This is even better than trusting Root
> CAs + Kristian.[3])

This is certainly something I can consider if there is a wish for it
in the community. But mainly you will see the servers included with a
HKPS flag in the status page of the pool[0] as I wouldn't sign a
server not included here. You'll run into a catch-22 here as well, as
you'd (i) need to have a valid OpenPGP trust path (ii) trust that the
information I provide in that log is accurate. As I use sequential
serial-numbers, the latter should be possible, but in theory I could
generate an out-of-scope certificate and choose not to include it in
that log. So the question boils down to trust in the first place. For
better or for worse.

> 
> [1] Most hkps.pool.sks-keyservers.net don't have an alternative
> trust path to a standard root CA.

Is this really something we wish to have, given the lack of
credibility of the global PKIX model? It is also one of the purposes
of the more user-controlled web of trust possibilities (both due to
everyone being their own CA, or through explicitly granting others
this trust) of OpenPGP that we're tryign to operate in. So personally
I'm more focused on the possibility to verify operators and indeed the
CA through this protocol. That said I'm making an effort to create
better trust paths to my own OpenPGP key that signs the X.509 CA key
in the first place.

> 
> [2] This is different from saying that I think he *would 
> intentionally* sign a malicious cert, which I don't. I just have
> no idea how secure the private key for that CA is. And I know that
> a fully isolated, physically secure facility, and a good HSM are
> really expensive. (But maybe he is doing this?)

Sorry, but no, I don't keep it in a physical facility, it is on an
older laptop used for such operations.

Hardware modules I don't necessarily believe to be any better for
security as verifying the firmware brings its own set of problems, but
that is a discussion out of scope for this thread.

> 
> [3] If this is already available somewhere, apologies; I haven't 
> managed to find anything like it.
> 


References:
[0] https://sks-keyservers.net/status/

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"Expect the best. Prepare for the worst. Capitalize on what comes."
(Zig Ziglar)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUOAjsAAoJEPw7F94F4TagRtMQAK00DJRqXRpXum3Cz1Uv+TVX
W72mZWheeek8nW6B66dMSPi46FetpXn8h80gs2YGvke7OeauDnmpxz74AmeghiZS
H0dhCutVl7m7PH7d0DPrgczBifHgj9+9kJFS+/RJh/BH0ptCkUg7aG/97HSPLDnJ
4pqPHanp8glyciobJn+Oo1FNVD0JmcqGB1TLA74g7EruGcwshZYF8dlW0ZjJGWj4
f4Zo6sG5jTc3Hr0lpYeFcCZd/zCFMfgiJpBdr0QD8Ux6iljvDv5uKAf9NSiXOfbm
JePd/Psbix8x9qe67rTP8+5uBJQHeH3pTbGHSAfGmM+rHglz5Q27Dkk241r2xRU/
VOgsPwHAvPuLyz3JWoP+6oGQbtmmpuze1XI6nplJ+tO/2bBvcWRTDV/S6SlBEUA5
n9TwwNqaGLO/RUfwnpQZGN/WwLfyb5lZ9GdxGtlppdnV1vj3J5OxhDmup3bDXrYg
ThrZza7xz8mvgwex8IoPsl8gGiiHETlahBHexSiyYGcKrEeA8XZrP3+RlRfogr7g
jvAzCqbAv21r5GRMUznjoQ2Fl8eDJ5TIzSO9YVZ+oY2/RomZXl9C/2B5akEYBw/U
6yJkSMfBsphfV3CC/NrvB90BDR62MDbJPjQJ3af6uV4icSoseuwrVKNbYUQsgx5a
FQj/hCmmCeGrTF2/d0T2
=vy6k
-----END PGP SIGNATURE-----