2019-06-04 22:11:38 +00:00
|
|
|
{{#> layout }}
|
|
|
|
<div class="about">
|
|
|
|
|
|
|
|
<center><h2><a href="/about">About</a> | <a href="/about/usage">Usage</a> | FAQ | <a href="/about/privacy">Privacy Policy</a> | <a href="/about/api">API</a></h2></center>
|
|
|
|
|
2019-06-10 18:28:37 +00:00
|
|
|
<h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
|
|
|
|
after verification?</a></h3>
|
2019-06-04 22:11:38 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2019-06-10 18:28:37 +00:00
|
|
|
<h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
|
2019-06-10 19:51:19 +00:00
|
|
|
for identities that aren't e-mail addresses?</a></h3>
|
2019-06-10 18:28:37 +00:00
|
|
|
|
|
|
|
<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>
|
|
|
|
|
2019-06-10 19:51:19 +00:00
|
|
|
<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>
|
2019-06-10 18:28:37 +00:00
|
|
|
|
|
|
|
<h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">
|
|
|
|
Why not encrypt verification e-mails?</a></h3>
|
2019-06-04 22:11:38 +00:00
|
|
|
|
|
|
|
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>
|
|
|
|
|
2019-06-10 18:28:37 +00:00
|
|
|
<h3 id="sks-pool"><a href="#sks-pool">Is
|
|
|
|
<span class="brand">keys.openpgp.org</span> part of the "SKS" pool?</a>
|
|
|
|
</h3>
|
2019-06-04 22:11:38 +00:00
|
|
|
|
|
|
|
<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>
|
|
|
|
|
|
|
|
<!--
|
|
|
|
<ul>
|
|
|
|
<li><b>Do not distribute unverified or malicious data</b>
|
|
|
|
<p>Unlike traditional keyservers, <tt>keys.openpgp.org</tt> does not
|
|
|
|
distribute key material that isn't cryptographically verified.
|
|
|
|
This protects keys from unwanted spam, and helps protect the
|
|
|
|
service itself against "denial of service" attacks.
|
|
|
|
</p>
|
|
|
|
<p>We also do not distribute "third-party" signatures on keys. These
|
|
|
|
kinds of signatures were typically used to "sign" the keys of
|
|
|
|
others, in order to support a "Web of Trust" trust model. This
|
|
|
|
model meant that third parties could attach arbitrary spam to
|
|
|
|
any key, but didn't prove itself as a very effective trust model
|
|
|
|
in practice.
|
|
|
|
</p>
|
|
|
|
<p>We are open to alternative approaches that might be implemented
|
|
|
|
in the future, that avoid this issue.
|
|
|
|
</p>
|
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
-->
|
|
|
|
|
|
|
|
</div>
|
|
|
|
{{/layout}}
|