sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Re: New search options question


From: Christoph Anton Mitterer
Subject: Re: [Sks-devel] Re: New search options question
Date: Thu, 30 Dec 2010 02:52:56 +0100

Hey...


On Wed, 2010-12-29 at 19:39 -0500, Phil Pennock wrote:
> It's a draft and somewhat dated.
Of course...
(btw: IMHO it regrettably that we have no real standard document for
HKP)


>   The author's own software no longer
> conforms to it in some areas (eg, the SRV service name to use; GnuPG now
> uses two of the DNS-SD variants instead).
I haven't tracked gnupg in that manner recently,.. but would consider it
sad if it no longer supports the SRV way,... which is IMHO much more
"plain" DNS than any zeroconf stuff.


> Most of the issues are of the x-<name> vs <name> variety, which in my
> opinion is nit-picking of the highest order when the reference is a -00
> version personal submission expired draft.  It's *normal* for people to
> ignore such x-restrictions on naming at such an early stage, while
> people get experience with the protocol and refine the draft.
Well it might sound nit-picking,.. but things like these are what cause
many standardisation problems in other fields, as people think "well
it's ok not to follow the standard here for now",... but later it turns
out that things got so widespread and one has to keep legacy stuff
forever (just take the http content encoding headers as example).


> It only makes sense for options=nm to raise an error if the server does
> perform any modifications.  I don't believe that SKS does, so it's by
> definition always complying with such a request.  Thus an error would be
> incorrect.
If it really doesn't, then it's ok to silently ignore it, I guess. But
one should not forget this, in case code is ever added that _does_
modify keys.


> MIME-types -- the built-in web-server is supposed to be a very minimal
> implementation.  I strongly suggest that if you want anything
> non-trivial served, you do so with a proper threaded/forking server, to
> be able to sustain load?  Options are for SKS on port 11371 and a
> default document that just does a redirect to port 80 serving, or for
> SKS behind a proxying server on port 80 with the proxy providing SSL,
> etc, and *only* passing on ^/pks/.* to SKS.
That's what I plan to do,... put it behind an Apache, an forcibly set
the headers there.

I mean the request for this was rather a would-be-nice-to-have.


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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