diff options
Diffstat (limited to 'doc/gph/c3.sgml')
| -rw-r--r-- | doc/gph/c3.sgml | 885 |
1 files changed, 885 insertions, 0 deletions
diff --git a/doc/gph/c3.sgml b/doc/gph/c3.sgml new file mode 100644 index 000000000..541cf6c9d --- /dev/null +++ b/doc/gph/c3.sgml @@ -0,0 +1,885 @@ +<chapter id="management" xreflabel="3"> +<docinfo> +<date> +$Id$ +</date> +</docinfo> +<title> +Key Management +</title> + +<para> +Key tampering is a major security weakness with public-key cryptography. +An eavesdropper may tamper with a user's keyrings or forge a +user's public key and post it for others to download and use. +For example, suppose Chloe wants to monitor the messages that Alice +sends to Blake. +She could mount what is called a <firstterm>man in the +middle</firstterm> attack. +In this attack, Chloe creates a new public/private keypair. +She replaces Alice's copy of Blake's public key with the new public key. +She then intercepts the messages that Alice sends to Blake. +For each intercept, she decrypts it using the new private key, reencrypts +it using Blake's true public key, and forwards the reencrypted +message to Blake. +All messages sent from Alice to Blake can now be read by Chloe. +</para> + +<para> +Good key management is crucial in order to ensure not just the integrity +of your keyrings but the integrity of other users' keyrings as well. +The core of key management in &gnupg; is the notion of signing keys. +Key signing has two main purposes: it permits you to detect tampering +on your keyring, and it allows you to certify that a key truly belongs +to the person named by a user ID on the key. +Key signatures are also used in a scheme known as the <firstterm>web of +trust</firstterm> to extend certification to keys not directly signed by you +but signed by others you trust. +Responsible users who practice good key management can defeat key +tampering as a practical attack on secure communication with &gnupg;. +</para> + +<sect1> +<title> +Managing your own keypair +</title> + +<para> +A keypair has a public key and a private key. +A public key consists of +the public portion of the master signing key, +the public portions of the subordinate signing and encryption subkeys, and +a set of user IDs used to associate the public key with a real person. +Each piece has data about itself. +For a key, this data includes its ID, when it was created, when it +will expire, etc. +For a user ID, this data includes the name of the real person it identifies, +an optional comment, and an email address. +The structure of the private key is similar, except that it contains only +the private portions of the keys, and there is no user ID information. +</para> + +<para> +The command-line option +<link linkend="edit-key"><option>--edit-key</option></link> +may be used to view a keypair. +For example, + +<screen width="80"> +<prompt>chloe%</prompt> <userinput>gpg --edit-key [email protected]</userinput> +Secret key is available. + +pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u +sub 2048g/0CF8CB7A created: 1999-06-15 expires: never +sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14 +sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14 +(1) Chloe (Jester) <[email protected]> +(2) Chloe (Plebian) <[email protected]> +<prompt>Command></prompt> +</screen> + +The public key is displayed along with an indication of whether +or not the private key is available. +Information about each component of the public key is then listed. +The first column indicates the type of the key. +The keyword <literal>pub</literal> identifies the public master signing key, +and the keyword <literal>sub</literal> identifies a public subordinate key. +The second column indicates the key's bit length, type, and ID. +The type is <literal>D</literal> for a DSA key, <literal>g</literal> for an +encryption-only +ElGamal key, and <literal>G</literal> for an ElGamal key that may be used for +both encryption and signing. +The creation date and expiration date are given in columns three and four. +The user IDs are listed following the keys. +</para> + +<para> +More information about the key can be obtained with interactive commands. +The command <link linkend="toggle"><command>toggle</command></link> +switches between the public and private +components of a keypair if indeed both components are available. + +<screen width="80"> +<prompt>Command></prompt> <userinput>toggle</userinput> + +sec 1024D/26B6AAE1 created: 1999-06-15 expires: never +sbb 2048g/0CF8CB7A created: 1999-06-15 expires: never +sbb 1792G/08224617 created: 1999-06-15 expires: 2002-06-14 +sbb 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14 +(1) Chloe (Jester) <[email protected]> +(2) Chloe (Plebian) <[email protected]> +</screen> + +The information provided is similar to the listing for the public-key +component. +The keyword <literal>sec</literal> identifies the private master signing key, +and the keyword <literal>sbb</literal> identifies the private subordinates keys. +The user IDs from the public key are also listed for convenience. +</para> + +<sect2> +<title id="integrity"> +Key integrity +</title> + +<para> +When you distribute your public key, you are distributing the public +components of your master and subordinate keys as well as the user IDs. +Distributing this material alone, however, is a security risk since +it is possible for an attacker to tamper with the key. +The public key can be modified by adding or substituting keys, or by +adding or changing user IDs. +By tampering with a user ID, the attacker could change the user ID's email +address to have email redirected to himself. +By changing one of the encryption keys, the attacker would +also be able to decrypt the messages redirected to him. +</para> + +<para> +Using digital signatures is a solution to this problem. +When data is signed by a private key, the corresponding public key +is bound to the signed data. +In other words, only the corresponding public key can be used to +verify the signature and ensure that the data has not been modified. +A public key can be protected from tampering by using its corresponding +private master key to sign the public key components and user IDs, thus +binding the components to the public master key. +Signing public key components with the corresponding private master +signing key is called <firstterm>self-signing</firstterm>, and a public key that has +self-signed user IDs bound to it is called a <firstterm>certificate</firstterm>. +</para> + +<!-- +%\begin{figure} +%Blank +%\caption{This should depict how self-signatures bind information to +%a public key.}\label{fig:selfsignedkey} +%\end{figure} +% +%As an example, Figure~\ref{fig:selfsignedkey} illustrates Chloe's public +%key, which has been self-signed to bind the user IDs and public subkeys +%to the public master key. +%The signatures on the user IDs can be checked with the \texttt{check} +%command from the key edit menu. +--> + +<para> +As an example, Chloe has two user IDs and three subkeys. +The signatures on the user IDs can be checked with the command +<link linkend="check"><command>check</command></link> from the key edit menu. + +<screen width="80"> +<prompt>chloe%</prompt> <userinput>gpg --edit-key chloe</userinput> +Secret key is available. + +pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u +sub 2048g/0CF8CB7A created: 1999-06-15 expires: never +sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14 +sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14 +(1) Chloe (Jester) <[email protected]> +(2) Chloe (Plebian) <[email protected]> + +<prompt>Command></prompt> <userinput>check</userinput> +uid Chloe (Jester) <[email protected]> +sig! 26B6AAE1 1999-06-15 [self-signature] +uid Chloe (Plebian) <[email protected]> +sig! 26B6AAE1 1999-06-15 [self-signature] +</screen> + +As expected, the signing key for each signature is the master signing +key with key ID <literal>0x26B6AAE1</literal>. +The self-signatures on the subkeys are present in the public key, but +they are not shown by the &gnupg; interface. +</para> +</sect2> + +<sect2> +<title> +Adding and deleting key components +</title> + +<para> +Both new subkeys and new user IDs may be added to your keypair after +it has been created. +A user ID is added using the command +<link linkend="adduid"><command>adduid</command></link>. +You are prompted for a real name, email address, and comment just +as when you create an initial keypair. +A subkey is added using the command +<link linkend="addkey"><command>addkey</command></link>. +The interface is similar to the interface used when creating an initial +keypair. +The subkey may be a DSA signing key, and encrypt-only ElGamal +key, or a sign-and-encrypt ElGamal key. +When a subkey or user ID is generated it is self-signed using your +master signing key, which is why you must supply your passphrase +when the key is generated. +</para> + +<para> +Additional user IDs are useful when you need multiple identities. +For example, you may have an identity for your job and an identity +for your work as a political activist. +Coworkers will know you by your work user ID. +Coactivists will know you by your activist user ID. +Since those groups of people may not overlap, though, each group +may not trust the other user ID. +Both user IDs are therefore necessary. +</para> + +<para> +Additional subkeys are also useful. +The user IDs associated with your public master key are validated by +the people with whom you +communicate, and changing the master key therefore requires recertification. +This may be difficult and time consuming if you communicate with +many people. +On the other hand, it is good to periodically change encryption subkeys. +If a key is broken, all the data encrypted with that key will be +vulnerable. +By changing keys, however, only the data encrypted with the one broken +key will be revealed. +</para> + +<para> +Subkeys and user IDs may also be deleted. +To delete a subkey or user ID you must first select it using the +<link linkend="key"><command>key</command></link> or +<link linkend="uid"><command>uid</command></link> commands respectively. +These commands are toggles. +For example, the command <command>key <parameter>2</parameter></command> +selects the second subkey, +and invoking <command>key <parameter>2</parameter></command> again +deselects it. +If no extra argument is given, all subkeys or user IDs are deselected. +Once the user IDs to be deleted are selected, the command +<link linkend="deluid"><command>deluid</command></link> +actually deletes the user IDs from your key. +Similarly, the command <link linkend="delkey"><command>delkey</command></link> +deletes all selected subkeys from both your public and private keys. +</para> + +<para> +For local keyring management, deleting key components is a good way +to trim other people's public keys of unnecessary material. +Deleting user IDs and subkeys on your own key, however, is not always +wise since it complicates key distribution. +By default, when a user imports your updated public key it will be merged +with the old copy of your public key on his ring if it exists. +The components from both keys are combined in the merge, and this +effectively restores any components you deleted. +To properly update the key, the user must first delete the old version +of your key and then import the new version. +This puts an extra burden on the people with whom you communicate. +Furthermore, if you send your key to a keyserver, the merge will +happen regardless, and anybody who downloads your key from a keyserver +will never see your key with components deleted. +Consequently, for updating your own key it is better to revoke key +components instead of deleting them. +</para> +</sect2> + +<sect2> +<title> +Revoking key components +</title> + +<para> +To revoke a subkey it must be selected. +Once selected it may be revoked with the +<link linkend="revkey"><command>revkey</command></link> command. +The key is revoked by adding a revocation self-signature to the key. +Unlike the command-line option <option>--gen-revoke</option>, the effect of +revoking a subkey is immediate. +</para> + +<screen width="80"> +<prompt>Command></prompt> <userinput>revkey</userinput> +Do you really want to revoke this key? y + +You need a passphrase to unlock the secret key for +user: "Chloe (Jester) <[email protected]>" +1024-bit DSA key, ID B87DBA93, created 1999-06-28 + + +pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u +sub 2048g/B7934539 created: 1999-06-28 expires: never +sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28 +rev! subkey has been revoked: 1999-06-29 +sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28 +(1) Chloe (Jester) <[email protected]> +(2) Chloe (Plebian) <[email protected]> +</screen> + +<para> +A user ID is revoked differently. +Normally, a user ID collects signatures that attest that the user ID +describes the person who actually owns the associated key. +In theory, a user ID describes a person forever, since that person will +never change. +In practice, though, elements of the user ID such as the email address +and comment may change over time, thus invalidating the user ID. +</para> + +<para> +The OpenPGP +<comment>First reference to OpenPGP</comment> +specification does not support user ID revocation, but +a user ID can effectively be revoked by revoking the self-signature +on the user ID. +For the security reasons described +<link linkend="integrity">previously</link>, +correspondents will not trust a user ID with no valid self-signature. +</para> + +<para> +A signature is revoked by using the command +<link linkend="revsig"><command>revsig</command></link>. +Since you may have signed any number of user IDs, the user interface +prompts you to decide for each signature whether or not to revoke it. +</para> + +<screen width="80"> +<prompt>Command></prompt> <userinput>revsig</userinput> +You have signed these user IDs: + Chloe (Jester) <[email protected]> + signed by B87DBA93 at 1999-06-28 + Chloe (Plebian) <[email protected]> + signed by B87DBA93 at 1999-06-28 +user ID: "Chloe (Jester) <[email protected]>" +signed with your key B87DBA93 at 1999-06-28 +Create a revocation certificate for this signature? (y/N)n +user ID: "Chloe (Plebian) <[email protected]>" +signed with your key B87DBA93 at 1999-06-28 +Create a revocation certificate for this signature? (y/N)y +You are about to revoke these signatures: + Chloe (Plebian) <[email protected]> + signed by B87DBA93 at 1999-06-28 +Really create the revocation certificates? (y/N)y + +You need a passphrase to unlock the secret key for +user: "Chloe (Jester) <[email protected]>" +1024-bit DSA key, ID B87DBA93, created 1999-06-28 + + +pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u +sub 2048g/B7934539 created: 1999-06-28 expires: never +sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28 +rev! subkey has been revoked: 1999-06-29 +sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28 +(1) Chloe (Jester) <[email protected]> +(2) Chloe (Plebian) <[email protected]> +</screen> + +<para> +A revoked user ID is indicated by the revocation signature on +the ID when the signatures on the key's user IDs are listed. +</para> + +<screen width="80"> +<prompt>Command></prompt> <userinput>check</userinput> +uid Chloe (Jester) <[email protected]> +sig! B87DBA93 1999-06-28 [self-signature] +uid Chloe (Plebian) <[email protected]> +rev! B87DBA93 1999-06-29 [revocation] +sig! B87DBA93 1999-06-28 [self-signature] +</screen> + +<para> +Revoking both subkeys and self-signatures on user IDs adds revocation +self-signatures to the key. +Since signatures are being added and no material is deleted, a +revocation will always be visible to others when your updated public +key is distributed and merged with older copies of it. +Revocation therefore guarantees that everybody has a consistent +copy of your public key. +</para> +</sect2> + +<sect2> +<title> +Updating a key's expiration time +</title> + +<para> +The expiration time of a key may be updated with the command +<link linkend="expire"><command>expire</command></link> from the key edit menu. +If no key is selected the expiration time of the primary key +is updated. +Otherwise the expiration time of the selected subordinate key +is updated. +</para> + +<para> +A key's expiration time is associated with the key's self-signature. +The expiration time is updated by deleting the old self-signature +and adding a new self-signature. +Since correspondents will not have deleted the old self-signature, they +will see an additional self-signature on the key when they update +their copy of your key. +The latest self-signature takes precedence, however, so all correspondents +will unambiguously know the expiration times of your keys. +</para> +</sect2> +</sect1> + +<sect1> +<title> +Validating other keys on your public keyring +</title> + +<para> +In Chapter <xref linkend="intro"> a procedure was given to validate your +correspondents' public keys: a correspondent's key is validated by +personally checking his key's fingerprint and then signing his public +key with your private key. +By personally checking the fingerprint you can be sure that the +key really does belong to him, and since you have signed they key, you +can be sure to detect any tampering with it in the future. +Unfortunately, this procedure is awkward when either you must validate +a large number of keys or communicate with people whom you do not +know personally. +</para> + +<para> +&Gnupg; addresses this problem with a mechanism popularly known +as the <firstterm>web of trust</firstterm>. +In the web of trust model, responsibility for validating public +keys is delegated to people you trust. +For example, suppose +<itemizedlist spacing="compact"> +<listitem> +<para> +Alice has signed Blake's key, and +</para> +</listitem> +<listitem> +<para> +Blake has signed Chloe's key and Dharma's key. +</para> +</listitem> +</itemizedlist> + +If Alice trusts Blake to properly validate keys that he signs, then +Alice can infer that Chloe's and Dharma's keys are valid without +having to personally check them. +She simply uses her validated copy of Blake's public key to +check that Blake's signatures on Chloe's and Dharma's are good. +In general, assuming that Alice fully trusts everybody to properly +validate keys they sign, then any key signed by a valid key is also +considered valid. +The root is Alice's key, which is axiomatically assumed to be valid. +</para> + +<sect2> +<title> +Trust in a key's owner +</title> + +<para> +In practice trust is subjective. +For example, Blake's key is valid to Alice since she signed it, but she +may not trust Blake to properly validate keys that he signs. +In that case, she would not take Chloe's and Dharma's key as valid +based on Blake's signatures alone. +The web of trust model accounts for this by associating with each +public key on your keyring an indication of how much you trust the +key's owner. +There are four trust levels. + +<variablelist> +<varlistentry> +<term> +unknown +</term> +<listitem> +<para> +Nothing is known about the owner's judgement in key signing. +Keys on your public keyring that you do not own initially have +this trust level. +</para> +</listitem> +</varlistentry> +<varlistentry> +<term> +none +</term> +<listitem> +<para> +The owner is known to improperly sign other keys. +</para> +</listitem> +</varlistentry> +<varlistentry> +<term> +marginal +</term> +<listitem> +<para> +The owner understands the implications of key signing and +properly validates keys before signing them. +</para> +</listitem> +</varlistentry> +<varlistentry> +<term> +full +</term> +<listitem> +<para> +The owner has an excellent understanding of key signing, +and his signature on a key would be as good as your own. +</para> +</listitem> +</varlistentry> +</variablelist> + +A key's trust level is something that you alone assign to the +key, and it is considered private information. +It is not packaged with the key when it is exported; it is even +stored separately from your keyrings in a separate database. +</para> + +<para> +The &gnupg; key editor may be used to adjust your trust in a key's owner. +The command is <link linkend="trust"><command>trust</command></link>. +In this example Alice edits her trust in Blake and then updates +the trust database to recompute which keys are valid based on her new +trust in Blake. + +<screen width="80"> +<prompt>alice%</prompt> <userinput>gpg --edit-key blake</userinput> + +pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f +sub 1024g/C19EA233 created: 1999-07-02 expires: never +(1) Blake (Executioner) <[email protected]> + +<prompt>Command></prompt> <userinput>trust</userinput> +pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f +sub 1024g/C19EA233 created: 1999-07-02 expires: never +(1) Blake (Executioner) <[email protected]> + +Please decide how far you trust this user to correctly +verify other users' keys (by looking at passports, +checking fingerprints from different sources...)? + + 1 = Don't know + 2 = I do NOT trust + 3 = I trust marginally + 4 = I trust fully + s = please show me more information + m = back to the main menu + +<prompt>Your decision?</prompt> <userinput>3</userinput> + +pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: m/f +sub 1024g/C19EA233 created: 1999-07-02 expires: never +(1) Blake (Executioner) <[email protected]> + +<prompt>Command></prompt> <userinput>quit</userinput> +[...] +</screen> + +Trust in the key's owner and the key's validity are indicated to the +right when the key is displayed. +Trust in the owner is displayed first and the key's validity is +<!-- HERE, need to fix quotation marks --> +second<footnote> +<para> +&Gnupg; overloads the word "trust" by using it to mean +trust in an owner and trust in a key. +This can be confusing. +Sometimes trust in an owner is referred to as +<firstterm>owner-trust</firstterm> to +distinguish it from trust in a key. +<!-- HERE, need to fix quotation marks --> +Throughout this manual, however, "trust" is used to +mean trust in a key's +<!-- HERE, need to fix quotation marks --> +owner, and "validity" is used to mean trust that a key +belongs to the human associated with the key ID. +</para> +</footnote>. +The four trust/validity levels are abbreviated: unknown (<literal>q</literal>), +none (<literal>n</literal>), marginal (<literal>m</literal>), and +full (<literal>f</literal>). +In this case, Blake's key is fully valid since Alice signed it herself. +She initially has an unknown trust in Blake to properly sign other keys +but decides to trust him marginally. +</para> +</sect2> + +<sect2> +<title> +Using trust to validate keys +</title> + +<para> +The web of trust allows a more elaborate algorithm to be used to +validate a key. +Formerly, a key was considered valid only if you signed it personally. +<!-- HERE, math --> +A more flexible algorithm can now be used: a key <emphasis>K</emphasis> is considered valid +if it meets two conditions: +<orderedlist spacing="compact"> +<listitem> +<para> +it is signed by enough valid keys, meaning +<itemizedlist spacing="compact"> +<listitem> +<para> +you have signed it personally, +</para> +</listitem> +<listitem> +<para> +it has been signed by one fully trusted key, or +</para> +</listitem> +<listitem> +<para> +it has been signed by three marginally trusted keys; and +</para> +</listitem> +</itemizedlist> +</para> +</listitem> +<listitem> +<para> +<!-- HERE, math --> +the path of signed keys leading from <emphasis>K</emphasis> back +to your own key is five steps or shorter. +</para> +</listitem> +</orderedlist> + +The path length, number of marginally trusted keys required, and number +of fully trusted keys required may be adjusted. +The numbers given above are the default values used by &gnupg;. +</para> + +<para> +<xref linkend="wot-examples"> shows a web of trust rooted at Alice. +The graph illustrates who has signed who's keys. +The table shows which keys Alice considers valid based on her +trust in the other members of the web. +<comment>Potential bug: <option>--completes-needed</option> on command +line seems to be ignored when combined with <option>--update-trustdb</option>. +Value is taken correctly if put in options file, however.</comment> +This example assumes that two marginally-trusted keys or one +fully-trusted key is needed to validate another key. +The maximum path length is three. +</para> + +<para> +When computing valid keys in the example, Blake and Dharma's are +always considered fully valid since they were signed directly +by Alice. +The validity of the other keys depends on trust. +In the first case, Dharma is trusted fully, which implies +that Chloe's and Francis's keys will be considered valid. +In the second example, Blake and Dharma are trusted marginally. +Since two marginally trusted keys are needed to fully validate a +key, Chloe's key will be considered fully valid, but Francis's +key will be considered only marginally valid. +In the case where Chloe and Dharma are marginally trusted, +Chloe's key will be marginally valid since Dharma's key is +fully valid. +Francis's key, however, will also be considered marginally +valid since only a fully valid key can be used to validate +other keys, and Dharma's key is the only fully valid key +that has been used to sign Francis's key. +When marginal trust in Blake is added, Chloe's key becomes +fully valid and can then be used to fully validate Francis's +key and marginally validate Elena's key. +Lastly, when Blake, Chloe, and Elena are fully trusted, this is +still insufficient to validate Geoff's key since the maximum +certification path is three, but the path length from Geoff +back to Alice is four. +</para> + +<para> +The web of trust model is a flexible approach to the problem of safe +public key exchange. +It permits you to tune &gnupg; to reflect how you use it. +At one extreme you may insist on multiple, short paths from your +<!-- HERE, math --> +key to another key <emphasis>K</emphasis> in order to trust it. +On the other hand, you may be satisfied with longer paths and +<!-- HERE, math --> +perhaps as little as one path from your key to the other +key <emphasis>K</emphasis>. +<!-- HERE, math --> +Requiring multiple, short paths is a strong guarantee +that <emphasis>K</emphasis> belongs to whom your think it does. +The price, of course, is that it is more difficult to validate keys +since you must personally sign more keys than if you accepted fewer +and longer paths. +</para> + +<figure id="wot-examples" float=1> +<title> +A hypothetical web of trust +</title> +<!-- +The graph indicates who has signed who's keys. +The table, in which names have been abbreviated, shows which keys are +valid depending on how Alice trusts other members in the web. +Alice considers different keys valid depending on how she trusts +the members of the web. +--> + +<graphic fileref="signatures.jpg"></graphic> + +<informaltable frame="all"> +<tgroup cols="4" rowsep="1" colsep="1"> +<colspec colname="one" colnum="1"> +<colspec colname="two" colnum="2"> +<colspec colname="three" colnum="3"> +<colspec colname="four" colnum="4"> +<spanspec spanname="lefthalf" namest="one" nameend="two" align="center"> +<spanspec spanname="righthalf" namest="three" nameend="four" align="center"> + +<thead> +<colspec +<row> +<entry spanname="lefthalf">trust</entry> +<entry spanname="righthalf">validity</entry> +</row> +<row> +<entry align="center">marginal</entry> +<entry align="center">full</entry> +<entry align="center">marginal</entry> +<entry align="center">full</entry> +</row> +</thead> +<tbody> +<row> +<entry></entry> +<entry>Dharma</entry> +<entry></entry> +<entry>Blake, Chloe, Dharma, Francis</entry> +</row> + +<row> +<entry>Blake, Dharma</entry> +<entry></entry> +<entry>Francis</entry> +<entry>Blake, Chloe, Dharma</entry> +</row> + +<row> +<entry>Chloe, Dharma</entry> +<entry></entry> +<entry>Chloe, Francis</entry> +<entry>Blake, Dharma</entry> +</row> + +<row> +<entry>Blake, Chloe, Dharma</entry> +<entry></entry> +<entry>Elena</entry> +<entry>Blake, Chloe, Dharma, Francis</entry> +</row> + +<row> +<entry></entry> +<entry>Blake, Chloe, Elena</entry> +<entry></entry> +<entry>Blake, Chloe, Elena, Francis</entry> +</row> +</tbody> +</tgroup> +</informaltable> +</figure> +</sect2> +</sect1> + +<sect1> +<title> +Distributing keys +</title> + +<para> +Ideally, you distribute your key by personally giving it to your +correspondents. +In practice, however, keys are often distributed by email or some +other electronic communication medium. +Distribution by email is good practice when you have only a few +correspondents, and even if you have many correspondents, you can use +an alternative means such as posting your public key on your World Wide +Web homepage. +This is unacceptable, however, if people who need your public key do +not know where to find it on the Web. +</para> + +<para> +To solve this problem public key servers are used to collect +and distribute public keys. +A public key received by the server is either added to the server's +database or merged with the existing key if already present. +When a key request comes to the server, the server consults its +database and returns the requested public key if found. +</para> + +<para> +A keyserver is also valuable when many people are frequently signing other +people's keys. +Without a keyserver, when Blake sign's Alice's key then Blake would send +Alice a copy of her public key signed by him so that Alice could +add the updated key to her ring as well as distribute it to all of her +correspondents. +Going through this effort fulfills Alice's and Blake's responsibility +to the community at large in building tight webs of trust and thus +improving the security of PGP. +It is nevertheless a nuisance if key signing is frequent. +</para> + +<para> +Using a keyserver makes the process somewhat easier. +When Blake signs Alice's key he sends the signed key to the key server. +The key server adds Blake's signature to its copy of Alice's key. +Individuals interested in updating their copy of Alice's key then consult +the keyserver on their own initiative to retrieve the updated key. +Alice need never be involved with distribution and can retrieve signatures +on her key simply by querying a keyserver. +<comment><option>--keyserver</option> must come before +<option>--send-key</option> or <option>--recv-key</option>. +This appears to be a bug.</comment> +</para> + +<para> +One or more keys may be sent to a keyserver using the command-line +option <link linkend="send-keys"><option>--send-keys</option></link>. +The option takes one or more key specifiers and sends the specified +keys to the key server. +The key server to which to send the keys is specified with the +command-line option <link linkend="keyserver"><option>--keyserver</option></link>. +Similarly, the option +<link linkend="recv-keys"><option>--recv-keys</option></link> is used +to retrieve keys from a keyserver, but the option <option>--recv-keys</option> +requires a key ID be used to specify the key. +In the following example Alice sends her public key to the keyserver +<parameter>certserver.pgp.com</parameter> and then updates her copy +of Blake's key from the same keyserver. + +<screen width="80"> +<prompt>alice%</prompt> <userinput>gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC</userinput> +gpg: requesting key BB7576AC from certserver.pgp.com ... +gpg: key BB7576AC: 1 new signature + +gpg: Total number processed: 1 +gpg: new signatures: 1 +<prompt>alice%</prompt> <userinput>gpg --keyserver certserver.pgp.com --send-key [email protected]</userinput> +gpg: success sending to 'certserver.pgp.com' (status=200) +</screen> + +There are several popular keyservers in use around the world. +The major keyservers synchronize themselves, so it is fine to +pick a keyserver close to you on the Internet and then use it +regularly for sending and receiving keys. +</para> +</sect1> + +</chapter> + |