philpennock · July 13, 2018 18:26
diff --git a/SKS Privacy b/SKS Privacy
 Privacy

 There are three categories of data relevant to privacy here: the public keys stored; the HTTP/HKP requests made to access/upload/retrieve those keys; what I as a keyserver operator might do with those requests (logs).

 For the public keys: the SKS keyserver pool, run globally by disparate individuals with no formal affiliation, is currently an append-only store, designed to protect against attempts to remove data. Once a key has been uploaded, that data is part of the public record, designed to allow anyone to attempt to verify the name binding within the key, using the public attestations by others about the identity of the key (key signatures). Keys not intended for public disclosure should not be uploaded, nor shared to people who might upload the keys of others. Note that there's no protection against fraudulent keys, with bindings of any name to any email address, and there is no basis to believe any such pairing without first proceeding through evaluation of the public attestations.

 The requests to retrieve/publish public keys are made over HTTP/HTTPS, following a specific schema which in combination is called HKP. If you make a request over HTTP, you have no privacy against on-path snoopers. If you use HTTPS without verification, you have no privacy against on-path tampering systems (‟active attacks”).

 If you use HTTPS to access this keyserver under the name sks.spodhuis.org then you should be presented with a verifiable certificate (currently: issued by Let's Encrypt) and be able to have some confidence in the privacy of links between your software and the server instance(s) which I run. This can be configured in some OpenPGP clients (such as GnuPG) with the URL hkps://sks.spodhuis.org/.

 If you access this keyserver via a name which is a ‟pool name” then you do not know if you are accessing this keyserver or any other keyserver in the pool. Using HTTPS (HKPS) provides protection against on-path tampering, but does not provide any protection against malicious keyserver operators. There is no known sane way to have meaningful verification of affiliation or character before admitting a keyserver operator into the HKPS pools. Use of such a pool is a trade-off between ‟some privacy, at least” and ‟privacy you can count on”. If this is a concern for you, then find a keyserver operator whom you trust and configure your client to use a keyserver operated by them.

 As to logs: I can only assert the behavior of the keyserver(s) I control, not any others in the pool or otherwise. The spodhuis.org keyserver(s) has two categories of logging, both applied for operational reasons. There are no tracking cookies, no affiliate systems and no loading of resources from other entities. The server itself may be run as a virtual machine in a ‟cloud provider” which means that the policies and practices of such a provider come into play too. At this time, I am using Amazon Web Services (AWS).

 The operational logs are divided into "HKP" and "non-HKP". The non-HKP traffic is typically that of a web-browser and affects you as you're reading this text. These are normal webserver logs, retained for an operationally relevant period of time, including origin IP address and other information sent by your browser, together with diagnostics about the access. The HKP traffic, for retrieving/sending keys, is all under the /pks/ path on this server, and that logging completely avoids anything which might reasonably be considered sensitive. In particular, your IP address and browser User-Agent are not logged for HKP. In an emergency, I reserve the right to temporarily increase logging or otherwise capture traffic: (1) to protect my systems from attack or being used as a source/reflector/amplifier of an attack; (2) to comply with an appropriately issued legal order.

 This server is a VM in the USA, operated by a US citizen and subject to the laws of two states of the USA; specifically, of Pennsylvania (the operator) and perhaps Ohio (the VM).
	Privacy

	There are three categories of data relevant to privacy here: the public keys stored; the HTTP/HKP requests made to access/upload/retrieve those keys; what I as a keyserver operator might do with those requests (logs).

	For the public keys: the SKS keyserver pool, run globally by disparate individuals with no formal affiliation, is currently an append-only store, designed to protect against attempts to remove data. Once a key has been uploaded, that data is part of the public record, designed to allow anyone to attempt to verify the name binding within the key, using the public attestations by others about the identity of the key (key signatures). Keys not intended for public disclosure should not be uploaded, nor shared to people who might upload the keys of others. Note that there's no protection against fraudulent keys, with bindings of any name to any email address, and there is no basis to believe any such pairing without first proceeding through evaluation of the public attestations.

	The requests to retrieve/publish public keys are made over HTTP/HTTPS, following a specific schema which in combination is called HKP. If you make a request over HTTP, you have no privacy against on-path snoopers. If you use HTTPS without verification, you have no privacy against on-path tampering systems (‟active attacks”).

	If you use HTTPS to access this keyserver under the name sks.spodhuis.org then you should be presented with a verifiable certificate (currently: issued by Let's Encrypt) and be able to have some confidence in the privacy of links between your software and the server instance(s) which I run. This can be configured in some OpenPGP clients (such as GnuPG) with the URL hkps://sks.spodhuis.org/.

	If you access this keyserver via a name which is a ‟pool name” then you do not know if you are accessing this keyserver or any other keyserver in the pool. Using HTTPS (HKPS) provides protection against on-path tampering, but does not provide any protection against malicious keyserver operators. There is no known sane way to have meaningful verification of affiliation or character before admitting a keyserver operator into the HKPS pools. Use of such a pool is a trade-off between ‟some privacy, at least” and ‟privacy you can count on”. If this is a concern for you, then find a keyserver operator whom you trust and configure your client to use a keyserver operated by them.

	As to logs: I can only assert the behavior of the keyserver(s) I control, not any others in the pool or otherwise. The spodhuis.org keyserver(s) has two categories of logging, both applied for operational reasons. There are no tracking cookies, no affiliate systems and no loading of resources from other entities. The server itself may be run as a virtual machine in a ‟cloud provider” which means that the policies and practices of such a provider come into play too. At this time, I am using Amazon Web Services (AWS).

	The operational logs are divided into "HKP" and "non-HKP". The non-HKP traffic is typically that of a web-browser and affects you as you're reading this text. These are normal webserver logs, retained for an operationally relevant period of time, including origin IP address and other information sent by your browser, together with diagnostics about the access. The HKP traffic, for retrieving/sending keys, is all under the /pks/ path on this server, and that logging completely avoids anything which might reasonably be considered sensitive. In particular, your IP address and browser User-Agent are not logged for HKP. In an emergency, I reserve the right to temporarily increase logging or otherwise capture traffic: (1) to protect my systems from attack or being used as a source/reflector/amplifier of an attack; (2) to comply with an appropriately issued legal order.

	This server is a VM in the USA, operated by a US citizen and subject to the laws of two states of the USA; specifically, of Pennsylvania (the operator) and perhaps Ohio (the VM).