Re: [Sks-devel] Data protection concern[Ref. RFA0751305]

Hi,

In order to get a fruitful dialogue on these matters, some
clarifications regarding the role of the sks-keyservers.net pool of
keyservers seems necessary.

sks-keyservers.net is not an organization, but is an automated service,
operated by me as a private individual, that detects public keyservers
through crawling the open internet. The service has been offered free of
charge to the public [since 2006], at which point it replaced a previous
service of a similar nature, and with [the source code open source]. The
service functions by generating the necessary DNS records for a [DNS
Round-Robin] consisting of underlying keyservers that matches the
necessary criteria to be considered up to date with the overall ecosystem.

Since this discussion affects the overall OpenPGP ecosystem, and these
matters relates to security enhancing software, of which transparency
between the various operators within the system is imperative; I've CCed
a relevant mailing list with matters related to keyservers. Please keep
this mailing list CCed in all further communications on this matter.

With regards to the specific claims a request for deletion was received
on 5/29/18, 2:24 PM CET. A response was sent 5/31/18, 11:21 PM that (i)
explained that sks-keyservers.net is not the appropriate recipient for a
request to delete as it only links to underlying keyservers that store
the data, and these are operated by more than 100 different operators
world-wide, and linking to [the blog post regarding deletion requests]
that is written and used for similar such requests describing this
situation. A keyserver operates in a blockchain like model of always
adding data, never deleting it.

Some discussions are currently ongoing in the community with regards to
alternative models for the keyservers to operate, however they will all
imply changing the security model that has been used by the PGP Web of
Trust for several decades, but no consensus has currently been reached.
These discussions can be found in the archives of the sks-devel mailing
list well as other relevant mailing lists.

In any case, sks-keyservers.net service only generates DNS records such as
$ dig a pool.sks-keyservers.net
;; ANSWER SECTION:
pool.sks-keyservers.net. 3588   IN      A       74.50.54.68
pool.sks-keyservers.net. 3588   IN      A       130.133.110.62
pool.sks-keyservers.net. 3588   IN      A       85.93.216.115
pool.sks-keyservers.net. 3588   IN      A       130.206.1.111
pool.sks-keyservers.net. 3588   IN      A       37.44.0.28
pool.sks-keyservers.net. 3588   IN      A       178.32.66.144
pool.sks-keyservers.net. 3588   IN      A       193.70.2.173
pool.sks-keyservers.net. 3588   IN      A       178.175.148.28
pool.sks-keyservers.net. 3588   IN      A       85.227.82.204
pool.sks-keyservers.net. 3588   IN      A       192.146.137.98

and is not the correct recipient for any such request.

References:
[the source code open source]
https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=summary

[DNS Round-Robin]
https://en.wikipedia.org/wiki/Round-robin_DNS

[since 2006]
(i) https://lists.nongnu.org/archive/html/sks-devel/2006-12/msg00002.html
(ii)
https://blog.sumptuouscapital.com/2016/12/10-year-anniversary-for-sks-keyservers-net/

[the blog post regarding deletion requests]
https://blog.sumptuouscapital.com/2016/03/openpgp-certificates-can-not-be-deleted-from-keyservers/

On 2/19/19 11:32 AM, address@hidden wrote:
> 19 February 2019
> 
>  
> 
> *Case Reference Number RFA0751305*
> 
>  
> 
> Dear Mr Fiskerstrand
> 
> 
> We are writing to you because we have received a complaint from Mr Dean
> Hughes regarding the way SKS Keyservers handles its data protection
> obligations.
>  
> *The ICO’s role *
>  
> Part of our role is to consider complaints from individuals who believe
> their data protection rights have been infringed.
> 
> *Complaint raised with us*
> 
> Mr Hughes has complained that SKS Keyservers has not complied with his
> request for erasure. Mr Hughes has complained that the keyservers share
> and make personal details publically available, such as his name and
> email addresses.
>  
> Mr Hughes has stated that he willingly submitted his personal data to
> your organisation years ago but would now like for it be deleted from
> both your organisation’s keyservers and the keyservers with which also
> shared his data.
>  
> Furthermore, it has been suggest that the records Mr Hughes has asked to
> be deleted contain personal data from more than 20 years ago, which
> include his name and email addresses.
>  
> *What you need to do now*
>  
> We want you to revisit the way you have handled this matter and consider
> any further action that you can take that may resolve this complaint.
>  
> If you feel that you have complied with the Data Protection law in this
> case, please explain to us why.
>  
> We would also like you to provide the following information: 
> 
>   * Details of how you have handled this request for erasure.
>      
>   * Details of why Mr Hughes did not receive a response from SKS
>     Keyservers when exercising his rights.
>      
>   * Details of the organisation’s retention notice (as it would seem
>     that this is not on the website).
>      
>   * Details of SKS Keyservers’ lawful basis for processing this data and
>     why it is disclosing individuals’ –including Mr Hughes’– data
>     publically.
>      
>   * Details of any safeguards in place to help ensure you handle
>     personal data properly, particularly in relation to this specific
>     matter.
>      
>   * Details of any steps you have taken to add to or strengthen these
>     safeguards.
> 
>  
> For your reference I have attached evidence that supports Mr Hughes’
> data protection concerns pertaining to his personal data.
>  
> On a separate note, we would like to see a copy of SKS Keyservers’
> privacy policy to ensure that the organisation is compliant with its
> information rights and practices. This is because, it would appear that
> there is not a privacy policy on the website and this is an obligation
> under the new legislation, to inform its users, transparently, that the
> organisation is processing information that acts accordingly with GDPR
> and the Data Protection Act 2018 (‘DPA’).
>  
> You must provide this response as soon as possible and in any event
> within *14 days*.
>  
> If you do not provide the information we have requested, we will either
> base our decision on the information available or consider issuing an
> Information Notice.
>  
> *Advice and assistance*
>  
> Our website contains advice and guidance about the processing of
> personal data and an organisation’s obligations under the Data
> Protection law.  I recommend that you review the information on our
> website before finalising your reply.
>  
> Should you wish to discuss this case any further, or require any
> clarification, please do not hesitate to contact me.
>  
> Yours sincerely
>  
> Ryan Garner
> Case Officer
> Information Commissioner’s Office
> 0330 414 6876
>  
> *ICO Statement*
> You should be aware that the Information Commissioner often receives
> request for copies of the letters we send and receive when dealing with
> casework. Not only are we obliged to deal with these in accordance with
> the access provisions of the data protection framework and the Freedom
> of Information Act 2000, it is in the public interest that we are open
> and transparent and accountable for the work that we do.
>  
> For information about what we do with personal data see our privacy
> notice at www.ico.org.uk/privacy-notice
> <http://www.ico.org.uk/privacy-notice>
> 


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws

Supporting evidence-1.txt
Description: Text document

signature.asc
Description: OpenPGP digital signature

• Re: [Sks-devel] Data protection concern[Ref. RFA0751305], Kristian Fiskerstrand <=

• Prev by Date: Re: [Sks-devel] Apache setup for refusing to serve bad keys
• Previous by thread: [Sks-devel] Apache setup for refusing to serve bad keys
• Index(es):
  • Date
  • Thread