On Jun 4, 2012, at 4:19 PM, Robert J. Hansen wrote:
> On 6/4/12 4:15 PM, Jeffrey Johnson wrote:
>> Insisting that SKS key servers *never* undertake some reasonable
>> policies for sound engineering purposes isn't subject to the number
>> of adamant objectors, but rather to sensible discussion.
>
> There's a difference between saying "these signatures should never be
> dropped from the servers" (which is my position) and "these signatures
> should always be presented to clients" (which is not my position).
>
Sure: filtering on download (and perhaps upload) under end-user
client "opt-in" policy control is an easy consensus.
> If a client explicitly requests for a sanitized certificate, I see no
> reason that SKS should not respect that request: but SKS itself needs to
> keep track of this data.
>
But there are also reasons to add better policies like "Do Not Modify"
or "I live in the EU and privacy laws permit me to insist that my pubkey be
removed."
to manage server-to-server distribution.
Whether a mechanism is possible, can be implemented, should be enabled/useful,
or is sufficiently sensitive to user/operator needs, are all very different
questions.
But arguing that the problem should not be considered because
"… several people have come out quite adamantly …"
isn't exactly a healthy discussion.
73 de Jeff
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
