sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]


From: Gabor Kiss
Subject: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Date: Sun, 14 Jan 2018 12:40:19 +0100 (CET)
User-agent: Alpine 2.11 (DEB 23 2013-08-11)

> Let's Encrypt has the DNS-01 challange where the admin produces a
> verification code that Kristian has to publish into his DNS zone through
> a txt record. As soon as this is done the admin can create a certificate
> that includes the pool hostname *and* his personal individual
> hostname(s) and is valid for 3 months. Re-certification can be automated
> by the admin through a daily cronjob that will re-cert any certificate
> near it's expiry date. If some admin needs to be thrown out Kristian can
> just remove the challenge code for his server from the dns zone and the
> resigning will fail. Furthermore inclusion of an ip address in the hkps
> pool can be automated by checking if the host answers with a valid
> certificate.

Folks,

I don't want to chip on your hot debate (Honey! Is there any popcorn yet?)
I just wish to clarify some technical details.

Now Kristian manages a single domain (sks-keyservers.net) and
he signes CSRs from a dozen operators.
All of these CSR are fabricated for subject "hkps.pool.sks-keyservers.net".
(So if a HKPS client (e.g. gnupg) connects to any pool servers
behind the hkps.pool.sks-keyservers.net entry it could verify
connection secureness.)
However pool operators have own distinguished key pairs and Kristian
signes them individually.
Using the suggested method above Kristian should put a new,
different TXT record into hkps.pool.sks-keyservers.net name
server every time a new operator need a certificate.
Also at every resigning.
(Corollary: Kristian cannot accept a new operator request
until the previous transaction is done.)

At this point I don't understand exactly this sentence:

> If some admin needs to be thrown out Kristian can just remove the
> challenge code for his server from the dns zone and the resigning will fail.

I assume Let's encrypt asks TXT record for the _same_ FQDN each time. E.g.

_acme-challenge.hkps.pool.sks-keyservers.net. TXT "funny string here"

How Kristian could "remove challenge code for _his_ server" selectively
if the DNS always contains the challenge _only_ of the latest
signing transaction?

Did I miss something?

Regards

Gabor



reply via email to

[Prev in Thread] Current Thread [Next in Thread]