sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Sks-devel Digest, Vol 110, Issue 5


From: cbuckingham
Subject: Re: [Sks-devel] Sks-devel Digest, Vol 110, Issue 5
Date: Mon, 17 Jun 2013 09:47:51 +0200

It may very well be questionable, forcing the take-down of a 
"public key" that you distributed to a "public keyserver". When you 
talk about images published with the key then it is another tin of 
worms.

1) Removal (take-downs) of fraudulent keys should be complied with 
in order to preseve the integrity of the keyservers. The question 
is, how do you really confirm the keys are from that person without 
them having taken part in a key party? You do not really want to 
get into scanned copies of passports or identity cards being sent 
with the removal request, that opens possibilities of abuse from 
rogue elements.

2) What happens to servers that are not affected by a court order? 
Supposing a server owner refuses to comply because the operator 
cannot confirm the identity of the requestor or is out of 
jurisdiction?

3) Does a court order have to be presented to each foreign server 
owner individually, since they are only subscribers to the SKS/PGP 
framework of systems?

4) If you only black-list an entry so that it cannot be seen and do 
not DELETE it, does this comply with a court order and spirit of 
the law in all jurisdictions?

5) How does any order affect keys that have expired or keys from 
another person that may have had the same e-mail address previously 
or have the same name? Without positive identity proof 
corresponding to both the old and newer keys, this would be hard to 
administer.

6) Is this just another attack on privacy and the systems that help 
facilitate it? We have seen these sorts of things in the past and 
know how something that appears innocent can develope into 
something really bad. It's the WTF, how was this allowed to happen, 
scenario.


On Sun, 16 Jun 2013 18:14:22 +0200 address@hidden 
wrote:
>Send Sks-devel mailing list submissions to
>       address@hidden
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.nongnu.org/mailman/listinfo/sks-devel
>or, via email, send a message with subject or body 'help' to
>       address@hidden
>
>You can reach the person managing the list at
>       address@hidden
>
>When replying, please edit your Subject line so it is more 
>specific
>than "Re: Contents of Sks-devel digest..."
>
>
>Today's Topics:
>
>   1. Re: Filtering specific keys (Markus Reichelt)
>
>
>-------------------------------------------------------------------
>---
>
>Message: 1
>Date: Sun, 16 Jun 2013 12:36:46 +0200
>From: Markus Reichelt <address@hidden>
>To: address@hidden
>Subject: Re: [Sks-devel] Filtering specific keys
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>* Johan van Selst <address@hidden> wrote many moons ago:
>
>> I would like to see the option in SKS to filter out (hide) PGP 
>keys
>> with specific keyids and email addresses locally; e.g.  using a
>> blacklist taken from a local configuration file.  Since SKS 
>already
>> has display filters that hide some broken keys, I think it
>> shouldn't be very hard to implement this.
>
>+1
>
>
>> The reason for this is to be able to comply with
>> notice-and-take-down orders.  We talked about this two years ago
>> when Pramberger's server was forced offline by an Austrian user,
>> but similar cases are likely - especially with regard to images
>> included in some PGP keys.  At the moment a user in France is
>> contacting keyserver owners to get keys taken offline that have
>> been uploaded by others, using his name and email address.
>
>just wondering what the status quo is, regarding both the feature
>request and take-down hassles.
>
>Anyone?
>
>-- 
>left blank, right bald
>
>
>
>------------------------------
>
>_______________________________________________
>Sks-devel mailing list
>address@hidden
>https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
>End of Sks-devel Digest, Vol 110, Issue 5
>*****************************************




reply via email to

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