On 06/04/2012 03:28 AM, Gabor Kiss wrote:
Actually it is not true that SKS does not modify certs.
AFAIK, no one in this discussion ever claimed it does. It was claimed
that SKS never deletes information, which rather moots the rest of your
email. :)
Actually it is not true that SKS does not modify certs.
AFAIK, no one in this discussion ever claimed it does. It was claimed
I did not say that someone stated this. :-)
However I say: if one kind of modification is allowed
then the other is also possible.
that SKS never deletes
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.
On 6/4/12 4:27 PM, Jeffrey Johnson wrote:
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.
The problem here is that the keyserver network would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert,
This isn't seeming consistent to me. How do you reconcile...
On 06/04/12 13:39, Robert J. Hansen wrote:
I've only ever said that the keyservers have always been guided by
a no loss of information, ever policy.
with
And I've also
On 05/31/2012 01:41 AM, Gabor Kiss wrote:
You have trust a long and thin chain of signatures between you
and your abroad comrade. What if a government agent edged in the chain?
1. Then you're goatscrewed, because you're trusting the wrong people,
and there is *no* technology that can help
You have trust a long and thin chain of signatures between you
and your abroad comrade. What if a government agent edged in the chain?
1. Then you're goatscrewed, because you're trusting the wrong people,
and there is *no* technology that can help you
What if you have no choice?
A
The problem with the second plan is that the potential number of differences
between hosts could grow quite large, degrading performance.
The easiest solution would be to auto-expire keys after a fixed time
(a good strategy anyway from a security perspective).
Best,
-Ari
On May 30,
Jeffrey Johnson wrote:
Its the expired robo-signatures on existing pubkeys, not
the pubkeys, that need filtering. There is also a need to
delete pubkeys
Is there a solution that can filter out specific expired
signatures on pub keys that can be gossip'd efficiently?
AFAIK additional
On May 30, 2012, at 10:58 PM, John Clizbe jpcli...@gingerbear.net wrote:
Jeffrey Johnson wrote:
Its the expired robo-signatures on existing pubkeys, not
the pubkeys, that need filtering. There is also a need to
delete pubkeys
Is there a solution that can filter out specific expired
The easiest solution would be to auto-expire keys after a fixed time
(a good strategy anyway from a security perspective).
What about deleting expired signatures from keys?
Gabor
___
Sks-devel mailing list
Sks-devel@nongnu.org
I'm with Rob. The keyservers should always host full certificates. Once we
start expiring keys or modifying them by removing bits, we become the
Untrusted Keyserver Cabal. Many would abandon us, probably forking to create a
There is no guarantee that one can trust all of current key servers.
If I was related to certain Asian governments I'd set up a fake key
server that is the only reachable from the country then I'd
serve manipulated keys to certain clients.
How do you propose to manipulate those keys? Do you have some way of
breaking RSA that we don't know about?
You
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA256
Jeffrey Johnson wrote:
On May 30, 2012, at 10:58 PM, John Clizbe jpcli...@gingerbear.net wrote:
Jeffrey Johnson wrote:
Its the expired robo-signatures on existing pubkeys, not
the pubkeys, that need filtering. There is also a need to
Plus, the instant there's a committee the committee members will likely
become legally responsible for the content of the network. If someone
Mostly you are right.
However this legal issue can be solved if the individual SKS server
operators may decide if they accept the comittee's suggestion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-26 07:58, Gabor Kiss wrote:
Is there really a need to carry around every expired signature
forever from a robo-signer?
Should/could some of the expired signatures be actively filtered
(and archived) instead of being carried in SKS
Ciao.
Il 27/05/2012 11:23, Kristian Fiskerstrand ha scritto:
I too, agree, that this is something that should be considered.
GnuPG is already doing its own cleaning up of the code for similar
reasons, something which was discussed back in April 2011 as well[0]
(and reminded me about [1], I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-27 11:50, Giovanni Mascellani wrote:
Ciao.
Il 27/05/2012 11:23, Kristian Fiskerstrand ha scritto:
I too, agree, that this is something that should be considered.
GnuPG is already doing its own cleaning up of the code for
similar
On 5/27/12 5:50 AM, Giovanni Mascellani wrote:
I'm just a newbie here, but actually I'd like to see the same concept
applied in a more general way: I think there is much garbage in the
keyservers, even behind the PGP robo-signer.
The problem here is this violates one of the principle design
Kristian Fiskerstrand wrote:
That has been discussed previously, and I am, at least personally very
much against it. There are good reasons to keep historical data on the
keyservers in order to increase security.
I am against a filtering infrastructure, too. This just causes more
trouble like
The keyservers never, never, never lose certificates. That's a design
goal and one that the SKS maintainers believe is a good one. I agree
with them, and want to see this design goal maintained in all future
development.
Some of us worries about DOS and installs HTTP proxy quickly.
However
On 5/27/12 6:53 AM, Gabor Kiss wrote:
My idea: there shoud be five wise and trusted peoples -- i.e.
a committee.
Theoretically possible, although it'd be very difficult to find five
people the entire PGP community could/would trust. As soon as you
introduce a committee of people with some kind
On May 27, 2012, at 6:35 AM, Jens Leinenbach wrote:
Kristian Fiskerstrand wrote:
That has been discussed previously, and I am, at least personally very
much against it. There are good reasons to keep historical data on the
keyservers in order to increase security.
I am against a filtering
On 27/05/2012 22:39, Jeffrey Johnson wrote:
On May 27, 2012, at 6:15 AM, Robert J. Hansen wrote:
We never, never, never lose certificates.
And what is being discussed is filtering an expired signature, not
a public key, for one specific robo-signer.
Even if the filtering was solely
On May 27, 2012, at 8:17 PM, John Marshall wrote:
On 27/05/2012 22:39, Jeffrey Johnson wrote:
On May 27, 2012, at 6:15 AM, Robert J. Hansen wrote:
We never, never, never lose certificates.
And what is being discussed is filtering an expired signature, not
a public key, for one
When I was first implementing SKS retrieval, I verified about
4M recently updated keys,
While checking expired signature behavior, it was very easy
to spot 0xca57ad7c showing up repeatedly, often enough
to imprint the fingerprint sufficiently that I actually looked
(and decided to never again
Is there really a need to carry around every expired signature forever
from a robo-signer?
Should/could some of the expired signatures be actively filtered (and
archived)
instead of being carried in SKS key servers forever? Yes a policy change
like this would be controversial and difficult
27 matches
Mail list logo
