Re: [Sks-devel] status page

[Simon Lange]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Am 18.04.2014 23:24, schrieb Daniel Kahn Gillmor:
> On 04/18/2014 04:42 PM, Simon Lange wrote:
>> "bad ppl" could pretend offering a public service using my machines they
>> dont own nor they administre nor they run. my machines would support
>> that passivly. think this is easy to understand. and also has some legal
>> implications. just imagine feds want to seize all machines of some "bad
>> ppl"and pinpoint using the IPs the get from running services under
>> badppl's domains... not worth the risk while easy to avoid.
>> we dont gossip with everyone without "handshaking" first. i keep it that
>> way same with the pool. :)
>
> I'm sorry, but this concern is not related to SKS; this is the way the
> internet works.

ehm, nope. the decision what content my machines do deliver under which
hostname ist not "how the internet works". its a decision of the admin
of the machine. sure, you can use "your hostname" resolving "my ip" but
that does not mean that you get the same content as if someone tries to
use a hostname which has a directive to show that content.

> Here's another example, not related to SKS: If you reverse the string
> "illuminati" and then append ".org", and put it in your web browser, you
> will find yourself instead at the homepage of an organization that
> probably does not want themselves to be publicly affiliated with the
> illuminati.

?! are you sure you did understand my point? that "example" does not
make any sense.

> The nature of the SKS pool is that different people address it in
> different ways.  for example, there are sub-pools that your keyserver
> might be part of, and they each have different names.  There are also
> other well-known names (like keys.gnupg.net) that themselves are aliased
> to the pool.

yeah but that is not the point.

> If you want your SKS instance to work with the various labels and pools
> that are available, you will let your SKS instance be addressed by
> arbitrary names.

not really. i decide what pool i may want to be in. gnupg and
sks-keyservers are okay. but that is not an invitation to allow the rest
of the world to pinpoint their FQDN to my service-ip using it under
their name. i did even reason why this is not a good idea. by now noone
told me a good reason to take the risk instead of gently asking.

> If you don't want your SKS instance to participate in the pool, you
> don't need to answer to different names.  that's fine too; but please
> don't accuse the pool coordinator (kristian) of setting up these rules
> to make trouble for you or any other keyserver operator; rather, he's

acusing? m) i did suggest not to require a "no matter what hostname
comes" policy. i did suggest he writes what his "check-script" is
checking so admins may configure their servers in a way to fullfill his
needs. THATS "less stress".
getting information drop by drop is ineffective and "more stress". sure,
he can ignore it. on the other hand i wouldnt ignore it if would be him.
because some good documentation (techdoc) would avoid many questions
many threads and many time answering them. ;)


> trying to make it so that people who rely on any of the pools (directly
> or indirectly) will always reach a functioning keyserver.  If you don't
> want to be in the pool because you don't want to take the same risk that
> every other web site takes, that's OK; you can still sync keys with
> members of the pool, but your keyserver won't be queried by people using
> the pool.

again. its not a matter of the "pool". its a matter y allowing OTHER
fqdn than the sks-keyservers pool to access under "their" fqdn?!
is it really so hard to understand?


> hope this helps explain the reason behind this requirement.

i see the luxury point but not why not changing it and why not
documentating the requiremnts of his check-script.

>
>     --dkg

Simon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
iQEcBAEBAgAGBQJTUcW6AAoJELCfvQa91QO+43cH/0uKtzsPrLobdinyhS6Q8qzk
M0+hGp7zaN9XPgzrv2QPoh5ptIwErou9kx33XTR39XZgTPbBfZmv5QttcRp3EbDq
75/MT3lomkgZHVnHu7FeGTuRhdx5ntTHMkXQKARWLWK1FlKt15DfarVpGAJJBaG8
N/YMmSbjUeIuVRHJoM2Mer6DLSFrLEaQAlBz3KKpYCJjVZ5CNdvcqFtFnbJ5ib+7
mGShy6NvdLoucu1OVHS35gW0MqDqve540rfNyORWQdLZuyyMLZTb3mYPKJLM2J9g
n/CM9QyzBkD6eoFZNvU8ioVz6GXs5QcRd9mmZx4yH5p4+7HtOtu+scnTGY+zXp4=
=ynWh
-----END PGP SIGNATURE-----