hkps port

David Shaw dshaw at
Thu Apr 2 13:35:27 CEST 2009

On Apr 2, 2009, at 12:24 AM, Phil Pennock wrote:

> On 2009-04-01 at 22:51 -0400, David Shaw wrote:
>> After some pondering about the proper port for hkps, I think that 443
>> makes the most sense (in other words, use the same port number as
>> https).  The reality is that there was never a particular reason why
>> regular hkp needed to be on port 11371.  The protocol is really http,
>> and may as well have lived on the proper http port.  I don't see a
>> reason to repeat this for hkps, so in the interest of simplicity, 443
>> seems to be the best choice.
> I have a web-server running providing http/https.  I have a keyserver
> running on 11371 and would like to have TLS keyserver support.
> The nearest I could do in this case is to disable SSL support in
> whichever keyserver I run, configure Apache to proxy for that vhost  
> and
> find some way to turn off the normal logging, since I don't query-log
> HKP retrievals.  This means that the set-up which respects user- 
> privacy
> is more work to support (given default configurations).
> Since HKP isn't directly for human consumption, does the need to  
> tunnel
> everything over the same two ports really stand?
> If you're set on 443, how about using SRV records for hkps, always,  
> and
> only have 443 be the fallback port in the absence of SRV records?
>  IN SRV 10 10 11372

I'm certainly not set on anything, yet.  I'm just proposing.  This is  
one of those unfortunate problems where there is no one solution that  
makes everyone happy.  We may have to be satisfied with least- 
unhappy. ;)

In terms of SRV, I'm all for it.  The catch is that libcurl doesn't  
support them (which actually makes sense, however unfortunate it is  
for this immediate problem - SRV was often proposed, but never  
formally standardized for HTTP).  No reason we can't support it in hkp/ 
hkps, of course.  I already have some code to support SRV for the non- 
curl HTTP handler in GPG, and it would be reasonably simple to port  
this over to dereference (for example) hkps:// into 

We could thus guarantee that hkps supports SRV from day one.


More information about the Gnupg-devel mailing list