sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Verification of keys on upload and removal options


From: Malte
Subject: Re: [Sks-devel] Verification of keys on upload and removal options
Date: Tue, 29 Mar 2016 13:46:23 +0200
User-agent: hostname

On Tuesday, March 29, 2016 5:41:53 AM CEST Robert J. Hansen wrote:
> >> 1. What criteria should be met before a key is removed?
> > 
> > Owner of private key or owner of UID/email address requests it.
> 
> So far, so good.
> 
> >> 2. Who decides that the criteria have been met?
> > 
> > The keyserver operator the request is sent to.
> 
> Going off the rails.
> 
> >> 3. How are malicious removals prevented?
> > 
> > If owner of private key and owner of UID/email address disagree, the key
> > stays off the servers. If they agree there should be no malicious
> > removal.
> Gone completely.
> 
> If a keyserver operator can decide that "the owner of this certificate
> has requested its removal", how can the certificate owner's wish that it
> NOT be removed be honored?  You're giving keyserver operators carte
> blanche to remove certificates at will -- and that's a level of
> authority they *mustn't* possess.

But they kind of do already, so I don't see the point here.

If there is doubt in the trustworthiness of a keyserver (operator), other 
keyservers can execute the same verification process, and if discrepancy is 
found, block deletion/all requests from the rogue keyserver until the issue is 
resolved.

For verification I have two in mind:

- a "deletion certificate" equivalent to the revocation certificate.
- emailing a verification link as we know it from mailing lists.


The worst case I can see is that a person's computer gets completely owned, 
the adversary steals the private key (as in copies and then deletes the 
original) as well as the credentials to the email inbox. Even if the person 
recovers control over the inbox, they probably don't want to continue using 
the key. So the worst that can happen is that the key is deleted instead of 
revoked. Not ideal, but considering that the person's digital life is in 
fcking ruins and that there will be a lot of manual communication with its 
trusted friends and colleagues anyway, I don't consider it that grave.


Sincerely,

Malte


-- 
1BEA 8159 A070 2E53 0152  A59F 0CC5 76E9 703E 1DDC



reply via email to

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