[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
Re: [Sks-devel] Verification of keys on upload and removal options, Julien Sansonnens, 2016/03/25