faq: add answer about non-email uids
This commit is contained in:
parent
97dc7d8a3c
commit
f51acb8560
|
@ -39,6 +39,14 @@ a.brand {
|
|||
color: #050505;
|
||||
}
|
||||
|
||||
h3:target {
|
||||
background-color: #ffa;
|
||||
}
|
||||
|
||||
h3 a, h3 a:visited {
|
||||
color: #050505;
|
||||
}
|
||||
|
||||
span.brand {
|
||||
font-family: monospace;
|
||||
font-size: large;
|
||||
|
|
|
@ -3,14 +3,32 @@
|
|||
|
||||
<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>
|
||||
|
||||
<h3>Why not sign keys after verification?</h3>
|
||||
<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>Why not encrypt verification e-mails?</h3>
|
||||
<h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
|
||||
for UserIDs 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="encrypt-verification-emails"><a href="#encrypt-verification-emails">
|
||||
Why not encrypt verification e-mails?</a></h3>
|
||||
|
||||
Various reasons:
|
||||
<ol>
|
||||
|
@ -23,7 +41,9 @@
|
|||
upload keys that can only sign.</li>
|
||||
</ol>
|
||||
|
||||
<h3>Is <span class="brand">keys.openpgp.org</span> part of the "SKS" pool?</h3>
|
||||
<h3 id="sks-pool"><a href="#sks-pool">Is
|
||||
<span class="brand">keys.openpgp.org</span> 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
|
||||
|
|
|
@ -53,12 +53,18 @@
|
|||
{{#if count_unparsed_one}}
|
||||
<p style="padding-top: 1em;">
|
||||
This key contains one identity that could not be parsed as an email
|
||||
address, which is not published.
|
||||
address.<br />
|
||||
This identity can't be published
|
||||
on <span class="brand">keys.openpgp.org</span>.
|
||||
(<a href="/about/faq#non-email-uids" target="_blank">Why?</a>)
|
||||
</p>
|
||||
{{else}}
|
||||
<p style="padding-top: 1em;">
|
||||
This key contains {{count_unparsed}} identities that could not be parsed
|
||||
as an email address, which are not published.
|
||||
as an email address.<br />
|
||||
These identities can't be published
|
||||
on <span class="brand">keys.openpgp.org</span>.
|
||||
(<a href="/about/faq#non-email-uids" target="_blank">Why?</a>)
|
||||
</p>
|
||||
{{/if}}
|
||||
{{/if}}
|
||||
|
|
Loading…
Reference in New Issue