Dirmngr now supports hkps

[Kristian Fiskerstrand]

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

On 05/07/2014 05:04 PM, Werner Koch wrote:
> On Tue,  6 May 2014 19:45,
> kristian.fiskerstrand at sumptuouscapital.com said:
> 
>> 8412a5825c225c8ff14de3ffaad2e55e040b2eca `make -j4` fails on my 
>> computer with ERROR described below. As of
> 
> Fixed.
> 
>> Also, if using --program-prefix='gpg2.1-' gpg fails to locate
>> the dirmngr,
> 
> Better use --prefix or --exec-prefix to put that version into a 
> different directory.  To allow for an arbitrary prefix we need to
> tell this common/homedir.c:gnupg_module_name.  There is an option
> to install gpg2 as gpg but for the other tools you would need to
> tell configure the full file name of the tools

Thanks for the pointer

> (e.g. --with-agent-pgm=/usr/local/bin/gpg2.1-gpg-agent) which is
> not that nice.  You may want to file a bug so that we do not forget
> about this missing feature.

I'll play around with my live ebuild a bit and see if I get around to
filing a bug once I get more familiar with the aforementioned options.

> 
>> Out of curiosity (as I haven't had time to look deeply enough
>> into the source code yet), how does dirmngr handle SNI in the
>> case of the hkps pool being resolved to multiple client? Does it
>> still present itself as SNI=hkps.pool.sks-keyservers.net when
>> contacting individual
> 
> We uses the name of the actual server.  Basically we do this:
> 
> if (!getaddrinfo (name, NULL, &hints, &aibuf)) for (ai = aibuf; ai;
> ai = ai->ai_next) getnameinfo (ai, tmphost, sizeof tmphost)
> 
> and then use TMPHOST to connect the host TMPHOST is the also given
> as SNI.  If the server can't be resolved this is likely a problem
> because the code will use the IP address as server name.  The HTTP
> code does not know about the pools, it takes an URL and applies
> proxy settings and resolves SRV records.

Ok, this seems to be a problem, I'll try to explain why I think so.

Certificates issued by the pool have (i) a CN with the server name,
which corresponds to the hostname provided in the server's sksconf or
similar and presented using /pks/lookup?op=stats and (ii) a
subjectAltName of the pool addresses including hkps. Only IP addresses
are provided for DNS request to the pools, as SRV records are
currently disabled due to existing bugs 1446[0] and 1447[1].

Based on your description of the current dirmngr behaviour I foresee
(at least) a few problems.
(i) as tmphost is derived from getnameinfo, the PTR record will be
used. A concrete example would be sks.karotte.org that resolve to
176.9.51.79 which has a PTR of alita.karotte.org. However no keyserver
is configured on [2] as the expected host is [3]. So trying to grab a
key will fail.

(ii) iff we require the PTR to match the hostname of the keyservers in
order to try to allow this behavior (keeping in mind that will limit
some server administrator's possibility to participate in the pool as
they might not be in control of the PTR records, or the sks service is
on a similar IP with other services that are prioritized), we'd still
have an issue in the situation where using the CN directly the server
might be presenting a self-signed / corporate signed certificate for
SNI == CN. In this case we will have a server authentication error

(iii) If the server upon SNI == CN || <no SNI> is presenting a
certificate signed by the CA Roots, we might nor might not get a valid
authentication of the server, depending on whether the global root CA
store on a calling client is consulted.

I strongly suggest using the original hostname provided as SNI when
performing keyserver lookups, this is also consistent with current
behavior (some of these points are also valid for any virtual-hosting
setup for the reverse proxy servers. It will most likely be more of an
issue on the port 80 subpool than the main pool as we strongly
encourage administrators to allow all traffic on 11371 through to the
keyserver).

References:
[0] http://bugs.g10code.com/gnupg/issue1446
[1] http://bugs.g10code.com/gnupg/issue1447
[2] https://alita.karotte.org/pks/lookup?op=stats
[3] https://sks.karotte.org/pks/lookup?op=stats

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTalyUAAoJEPw7F94F4TagJYcP/3KHZb4ybmOM4DDWus6y8qtZ
380SXFeiAyx6IkVecRggpU7kNwToV9ctzV1XaOlwR5aSlxjiVtRPa1wwYIuYGjm4
drqmMyGui6PPaI/bFXqqINfxQF9QQdAIEIqHb7f2Dey1I7z0KgepR5cfdcWQNMJF
xMg7nOvr4xReFsqMnv9ta6hguS+MsJwWFcbWT5sSEGyRVv1wHCcOfkX4puOMSiM2
nmebD4CQG2wH/1i7dnb3govhHHZ1ViptZIYgHObBZgYRYWsvbTz8LNP2oEq1UOW9
VrO9BAiz8nfkjFDIHwpvviDpmSJflfKoAYVxi2Eixjl/lsc6Lo1niJKdERcOJa+c
mejGGPq0p8mb3MNwejtOiGRMfRXs0XDbIjQsamB3ixkinS8+XZWpeqI8G9s3PR2V
BoW58bymIeCC/tgx3LSVBuvUuLn73+BXQjCTGCpV1H/Xlwa/95L87H39SzAwDLur
3Dhv2MFi0hh1J44O9PWjfuFs8KLBPA6gNrejskRI9X6AKS2XTPTSmdPRP64T/W+s
S/9TcV1mU7tHGpAGqngEIlsApIfmQMjeRO176EDcTKSUTWUWB3blE643pszuDPOa
KaBJKmL3vLIltT6qg2YetmMoWhqgYyXl1R7t2S01OtPhO0a0Ho5n5N2hTZZe+KTJ
UlIm7Ac/g9x89BCB67ZW
=ox3V
-----END PGP SIGNATURE-----