153 lines
6.0 KiB
Handlebars
153 lines
6.0 KiB
Handlebars
{{#> layout }}
|
|
<div class="about">
|
|
|
|
<center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | FAQ | <a href="/about/privacy">Privacy Policy</a></h2></center>
|
|
|
|
<h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
|
|
after verification?</a></h3>
|
|
|
|
The <span class="brand">keys.openpgp.org</span> service is meant for key
|
|
distribution and discovery, not as a de-facto CA. Client implementations
|
|
that want to offer verified communication should rely on their own trust
|
|
model.
|
|
|
|
<h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
|
|
for identities that aren't e-mail addresses?</a></h3>
|
|
|
|
<p>
|
|
We require explicit consent to distribute identity information.
|
|
Identities that aren't e-mail addresses, such as pictures or addresses,
|
|
offer no simple way for us to acquire this consent.
|
|
</p>
|
|
|
|
<p>
|
|
Note: Some OpenPGP software creates keys with incorrectly formatted
|
|
e-mail addresses. These addresses might not be recognized correctly on
|
|
<span class="brand">keys.openpgp.org</span>.
|
|
</p>
|
|
|
|
<h3 id="third-party-signatures"><a href="#third-party-signatures">
|
|
Do you distribute "third party signatures"?</a></h3>
|
|
|
|
<p>
|
|
Short answer: No.
|
|
</p>
|
|
|
|
<p>
|
|
A "third party signature" is a signature on a key
|
|
that was made by some other key.
|
|
Most commonly,
|
|
those are the signatures produced when "signing someone's key",
|
|
which are the basis for
|
|
the "<a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">Web of Trust</a>".
|
|
For a number of reasons,
|
|
those signatures are not currently distributed
|
|
via <span class="brand">keys.openpgp.org</span>.
|
|
</p>
|
|
|
|
<p>
|
|
The killer reason is <strong>spam</strong>.
|
|
Third party signatures allow attaching arbitrary data to anyone's key,
|
|
and nothing stops a malicious user from
|
|
attaching so many megabytes of bloat to a key
|
|
that it becomes practically unusable.
|
|
Even worse,
|
|
they could attach offensive or illegal content.
|
|
</p>
|
|
|
|
<p>
|
|
There are ideas to resolve this issue.
|
|
For example, signatures could be distributed with the signer,
|
|
rather than the signee.
|
|
Alternatively, we could require
|
|
cross-signing by the signee before distribution
|
|
to support a
|
|
<a href="https://wiki.debian.org/caff" target="_blank">caff-style</a>
|
|
workflow.
|
|
If there is enough interest,
|
|
we are open to working with other OpenPGP projects
|
|
on a solution.
|
|
</p>
|
|
|
|
<h3 id="revoked-uids"><a href="#revoked-uids">Why are revoked identities not
|
|
distributed as such?</a></h3>
|
|
|
|
<p>
|
|
When an OpenPGP key marks one of its identities as revoked, this
|
|
identity should no longer be considered valid for the key. And this
|
|
information should ideally be distributed to all OpenPGP clients that
|
|
already know about the newly revoked identity.
|
|
</p>
|
|
<p>
|
|
Unfortunately, there is currently no good way to distribute revocations,
|
|
that doesn't also reveal the revoked identity itself. We don't want to
|
|
distribute revoked identities, so we can't distribute the identity at
|
|
all.
|
|
</p>
|
|
<p>
|
|
There are proposed solutions to this issue, that allow the distribution
|
|
of revocations without also revealing the identity itself. But so far
|
|
there is no final specification, or support in any OpenPGP software. We
|
|
hope that a solution will be established in the near future, and will
|
|
add support on <span class="brand">keys.openpgp.org</span> as soon as
|
|
we can.
|
|
</p>
|
|
|
|
<h3 id="tor"><a href="#tor">Do you support Tor?</a></h3>
|
|
|
|
<p>
|
|
Of course!
|
|
If you have Tor installed,
|
|
you can reach <span class="brand">keys.openpgp.org</span> anonymously
|
|
as an
|
|
<a href="https://en.wikipedia.org/wiki/Tor_(anonymity_network)#Onion_services" target="_blank">onion service</a>:
|
|
<br />
|
|
<a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a>
|
|
</p>
|
|
|
|
<h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">
|
|
Why not encrypt verification e-mails?</a></h3>
|
|
|
|
Various reasons:
|
|
<ol>
|
|
<li>It is more complicated, both for our users and for us.</li>
|
|
<li>It doesn't prevent attacks - an attacker gains nothing from
|
|
uploading a key they don't have access to.</li>
|
|
<li>Deletion would still have to be possible even when a key is
|
|
lost.</li>
|
|
<li>It would require a different (and more complicated) mechanism to
|
|
upload keys that can only sign.</li>
|
|
</ol>
|
|
|
|
<h3 id="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a>
|
|
</h3>
|
|
|
|
<p>No. The "append-only" federation model of the SKS pool leads to various
|
|
problems, that make both operation and use of those servers very
|
|
difficult. There is also no simple way to store information about
|
|
e-mail verification in a federated way.
|
|
</p>
|
|
<p>We do plan to explore options for a distributed service in the future, so
|
|
users can choose between different service operators again.
|
|
</p>
|
|
|
|
<h3 id="older-gnupg"><a href="#older-gnupg">
|
|
I have trouble updating some keys with GnuPG. Is there a bug?
|
|
</a></h3>
|
|
|
|
<p>
|
|
This is a problem with current versions of GnuPG. If you attempt to
|
|
update a key from <span class="brand">keys.openpgp.org</span> that
|
|
contains no <a href="/about">identity information</a>, GnuPG will refuse
|
|
to process the key:
|
|
</p>
|
|
<blockquote>
|
|
$ gpg --receive-keys A2604867523C7ED8<br />
|
|
gpg: key A2604867523C7ED8: no user ID
|
|
</blockquote>
|
|
<p>
|
|
We are working with the GnuPG team to resolve this problem.
|
|
</p>
|
|
</div>
|
|
{{/layout}}
|