gph/es/c3.sgml

<chapter id="management" xreflabel="3">
<docinfo>
<date>
$Id: c3.sgml,v 1.1 2000/02/09 10:29:00 wkoch Exp $
</date>
</docinfo>
<title>
Gestión de Claves
</title>

<para>
En criptografía de clave pública la manipulación de claves es un punto flaco
a tener en cuenta.
Un &laquo;escucha&raquo; podría manipular los ficheros con las claves, o
falsificar la clave pública y hacerla pública para que la usaran otros como
si fuera la auténtica.
Por ejemplo, supongamos que Jordi quisiera monitorizar los mensajes que
Javier envía a Arancha.
Jordi podría montar lo que se conoce como un 
<firstterm>intermediario</firstterm> en el plan de ataque.
En este ataque Jordi crea una nuevo par de claves pública y privada,
reemplazando la clave pública de Arancha que posee Javier con la nueva clave
pública.
A partir de ahí intercepta los mensajes que Javier envía a Arancha.
Cada mensaje que intercepte lo descifrará usando la nueva clave privada, lo
volverá a cifrar con la clave auténtica de Arancha, y reenviará el mensaje
cifrado a Arancha.
Así, todos los mensajes que Javier envíe a Arancha pueden ser leídos por
Jordi.
</para>

<para>
Una buena gestión de claves es crucial para asegurarse, no sólo de la
integridad de nuestros ficheros de claves, sino también de la integridad de
los anillos de claves de otros.
El punto central en la gestión de claves en &gnupg; es la noción que hay
detrás de firmar las claves.
Firmar las claves tiene dos propósitos principales: nos permite detectar una
manipulación en nuestros anillos de claves, y nos permite certificar que una
clave realmente pertenece a la persona cuyo nombre aparece en el
identificador de usuario de la clave.
Las firmas de las claves también se usan en un esquema conocido como
<firstterm>anillo de confianza</firstterm> para hacer extensiva la
certificación de claves que no han sido firmadas directamente por el usuario,
sino que han sido firmadas por otros en los que él confía.
Un usuario responsable que lleve a cabo una buena gestión de claves puede
contrarrestar los efectos prácticos de la manipulación de claves con &gnupg;.
</para>

<sect1>
<title>
Gestionando nuestro par de claves
</title>

<para>
Un par de claves se compone de una clave pública y otra privada.
Una clave pública se compone de la parte pública de la clave de firmado
maestra, las partes públicas de las subclaves de firmado y cifrado,
y de un juego de identificadores de usuario que se usa para asociar la clave
pública con una persona real.
Cada una de estas partes contiene datos sobre sí misma.
Para una clave estos datos constan de su propio identificador, fecha de
creación, fecha de caducidad, etc...
Para un identificador de usuario, estos datos constan del nombre de la
persona a la que identifica, un comentario opcional, y una dirección de
correo electrónico.
La estructura de la claves privada es parecida, con la diferencia de que sólo
contiene las partes privadas de las claves, y que no tiene la información del
identificador de usuario.
</para>

<para>
La opción de la línea de órdenes
<link linkend="edit-key"><option>--edit-key</option></link>
se puede usar para ver un par de claves.
Por ejemplo,

<screen width="80">
<prompt>jordi%</prompt> <userinput>gpg --edit-key jordi@cat.es</userinput>
Secret key is available.

pub  1024D/1208DD4F  created: 1999-09-24 expires: never      trust: -/u
sub  1024g/B9688D9E  created: 1999-09-24 expires: never
sub  2016G/4D88ACC4  created: 1999-09-26 expires: 2002-09-25
sub   960D/412EAF0C  created: 1999-09-26 expires: 2002-09-25
(1)  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
(2)  Jordi (oficina) &lt;jordi@castell.com&gt;

<prompt>Command&gt;</prompt>
</screen>

La clave pública se muestra junto con una indicación sobre si la clave privada
se encuentra disponible o no.
La información sobre cada componente de la clave pública se da en una lista.
La primera columna indica el tipo de la clave.
La palabra clave <literal>pub</literal> identifica a la clave pública maestra
de firmado, y la palabra clave <literal>sub</literal> identifica a una clave
pública subordinada a la anterior.
La segunda columna informa sobre el tamaño en &dquo;bits&dquo; de la clave, el
tipo, y el identificador.
El tipo es <literal>D</literal> para una clave DSA, <literal>g</literal> para
una clave ElGamal que sólo se pueda usar para cifrar, y <literal>G</literal>
para una clave ElGamal que se pueda usar tanto para cifrar como para firmar.
La fecha de creación y la fecha de caducidad se muestran en las columnas tres
y cuatro.
Los identificadores de usuario aparecen en una lista a continuación de las
claves.
</para>

<para>
Se puede obtener más información sobre la clave mediante órdenes
interactivas.
La orden <link linkend="toggle"><command>toggle</command></link> sirve para
conmutar entre los componentes público y privado de un par de claves, siempre
y cuando ambos componentes estén presentes.

<screen width="80">
<prompt>Command&gt;</prompt> <userinput>toggle</userinput>

sec  1024D/1208DD4F  created: 1999-09-24 expires: never
sbb  1024g/B9688D9E  created: 1999-09-24 expires: never
sbb   960D/412EAF0C  created: 1999-09-26 expires: 2002-09-25
sbb  2016G/4D88ACC4  created: 1999-09-26 expires: 2002-09-25
(1)  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
(2)  Jordi (oficina) &lt;jordi@castell.com&gt;
</screen>

Esta información es parecida a la del componente para la clave pública.
La palabra clave <literal>sec</literal> identifica a la clave privada maestra
de firmado, y la palabra clave <literal>sbb</literal> identifica las claves
subordinadas privadas.
Los identificadores de usuario de la clave pública también aparecen en este
caso.
</para>

<sect2>
<title id="integrity">
Integridad de claves
</title>

<para>
Al distribuir nuestra clave pública, estamos distribuyendo los componentes
públicos de nuestras claves maestra y subordinada, así como los
identificadores de usuario.
Sin embargo, por sí sola, la distribución de este material constituye un
riesgo para la seguridad ya que sería posible que un atacante manipulara la
clave.
Se puede modificar una clave pública añadiendo o substituyendo claves, o
añadiendo o cambiando los identificadores de usuario.
Al manipular un identificador de usuario, el atacante podría cambiar la
dirección de correo del identificador de usuario y redireccionar así el
correo a su propia dirección.
Al cambiar una de las claves de cifrado el atacante también podría descifrar
los mensajes que le llegaran redireccionados.
</para>

<para>
El uso de las firmas digitales es una solución a este problema.
Cuando unos datos son firmados por una clave privada, la clave pública
correspondiente queda ligada a los datos firmados.
En otras palabras, sólo la clave pública correspondiente puede verificar la
firma y asegurar que los datos no han sido modificados.
Una clave pública se puede proteger de la manipulación usando su
correspondiente clave privada maestra, y firmando con ésta los componentes de
la clave pública y los identificadores de usuario, ligando de este modo los
componentes a la clave pública maestra.
La acción de firmar los componentes de la clave pública con la
correspondiente clave privada maestra se conoce como
<firstterm>autofirmar</firstterm>, y una clave pública que contenga
identificadores de usuario autofirmados ligados a ella se llama
<firstterm>certificado</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>
Como ejemplo, si Jordi tuviera dos identificadores de usuario y tres
subclaves, las firmas en los identificadores de usuario se podrían comprobar
con la orden <link linkend="check"><command>check</command></link> desde el
menú de edición de la clave.

<screen width="80">
<prompt>jordi%</prompt> <userinput>gpg --edit-key jordi</userinput>
Secret key is available.

pub  1024D/1208DD4F  created: 1999-09-24 expires: never      trust: -/u
sub  1024g/B9688D9E  created: 1999-09-24 expires: never
sub   960D/412EAF0C  created: 1999-09-26 expires: 2002-09-25
sub  2016G/4D88ACC4  created: 1999-09-26 expires: 2002-09-25
(1)  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
(2)  Jordi (oficina) &lt;jordi@castell.com&gt;

<prompt>Command&gt;</prompt> <userinput>check</userinput>
uid  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
sig!       1208DD4F 1999-09-24   [self-signature]
uid  Jordi (oficina) &lt;jordi@castell.com&gt;
sig!       1208DD4F 1999-09-26   [self-signature]
</screen>

Como era de esperar, la clave firmante para cada firma es la clave de firmado
maestra con el identificador de clave <literal>0x26B6AAE1</literal>.
La autofirma en las subclaves se encuentra presente en la clave pública, pero
en la interfaz de &gnupg; no aparece.
</para>
</sect2>

<sect2>
<title>
Añadir y eliminar componentes a las claves
</title>

<para>
Tanto las nuevas subclaves como los nuevos identificadores de usuario,
pueden ser añadidos a nuestro par de claves una vez que éste ya haya sido
creado.
Un identificador de usuario se añade mediante la orden
<link linkend="adduid"><command>adduid</command></link>.
A continuación se nos pedirá que introduzcamos un nombre real, una dirección
de correo electrónico, y un comentario, del mismo modo que cuando generamos
el par de claves inicial.
Una subclave se añade usando la orden
<link linkend="addkey"><command>addkey</command></link>.
La interfaz es parecida a la usada cuando generamos un par de claves nuevo.
La subclave puede ser una clave para firmado DSA y una clave sólo para cifrado
ElGamal, o una clave para firmado y cifrado ElGamal.
Cuando se genera una subclave o un identificador de usuario, éstos son
autofirmados con nuestra clave de firmado maestra, por lo que se nos
requerirá que introduzcamos la contraseña.
</para>

<para>
Los identificadores de usuario adicionales son útiles si necesitamos
múltiples identidades.
Por ejemplo, puede darse el caso de que utilicemos una identidad para el 
trabajo y otra para nuestras actividades políticas.
Los colegas de trabajo nos conocerán por nuestro identificador de usuario del
trabajo.
Los correligionarios políticos nos conocerán por nuestra identidad de usuario
política.
Como es posible que estos grupos de personas no coincidan, cada grupo no se
fiará del identificador que no corresponda.
Por lo tanto, ambos identificadores de usuario son necesarios.
</para>

<para>
Las subclaves adicionales son también muy útiles.
Los identificadores de usuario asociados con nuestra clave pública maestra
son validados por las personas con quien nos comunicamos y por tanto, cambiar
la clave maestra requiere &laquo;recertificación&raquo;.
Pero esto puede resultar difícil y una pérdida de tiempo si nos comunicamos
con muchas personas.
Por otra parte, es bueno cambiar las subclaves de cifrado periódicamente.
Si una clave es descubierta, todos los datos cifrados con esa clave serán
vulnerables.
De todos modos, al cambiar las claves sólo los datos cifrados con la clave
descubierta serán revelados.
</para>

<para>
También es posible eliminar las subclaves y los identificadores de usuario.
Para eliminar una subclave o un identificador de usuario es preciso
seleccionarlo primero con las órdenes
<link linkend="key"><command>key</command></link> o
<link linkend="uid"><command>uid</command></link> respectivamente.
Estas órdenes actúan como conmutadores.
Por ejemplo, la orden <command>key <parameter>2</parameter></command>
selecciona la segunda subclave, e invocando
<command>key <parameter>2</parameter></command> de nuevo, desactiva la
selección.
Si no se da ningún otro argumento extra, todas las subclaves o
identificadores de usuario son deseleccionados.
Una vez que los identificadores de usuario que se van a eliminar son
seleccionados, la orden
<link linkend="deluid"><command>deluid</command></link>
elimina los identificadores de usuario de la clave.
De igual forma, la orden
<link linkend="delkey"><command>delkey</command></link>
elimina todas las subclaves previamente seleccionadas de nuestras claves
pública y privada.
</para>

<para>
En la gestión local de anillos de claves, el eliminar componentes
innecesarios de una clave es una buena práctica para aliviar los anillos de
claves públicas de otros.
Sin embargo, eliminar identificadores de usuarios y subclaves de nuestra
propia clave no es siempre conveniente, ya que puede complicar la
distribución de la clave.
Por definición, cuando un usuario importa nuestra clave pública actualizada
ésta se fusiona con la copia de la clave pública vieja en su anillo de
claves, siempre que la vieja esté allí &laquo;a priori&raquo;.
Los componentes de ambas claves se combinan con la fusión, y el resultado de
ésta es que se añade cualquier nuevo componente, pero también que se
restaura cualquier componente eliminado.
Para actualizar de manera correcta la clave es necesario que el usuario
elimine primero la versión antigua de nuestra clave, y después que importe la
versión nueva.
Esto significa una carga extra para la gente con la que nos comunicamos.
Es más, si enviáramos nuestra clave a un servidor de claves la fusión
ocurriría a nuestro pesar, y cualquiera que se bajara nuestra clave del
servidor no vería nunca nuestra clave con los componentes eliminados.
En consecuencia, para actualizar nuestra propia clave es mejor revocar los
componentes de la clave que eliminarlos.
</para>
</sect2>

<sect2>
<title>
Revocar componentes de una clave
</title>

<para>
Para revocar una subclave antes tenemos que seleccionarla.
Una vez seleccionada, puede ser revocada con la orden
<link linkend="revkey"><command>revkey</command></link>.
La clave se revoca añadiéndole una autofirma de revocación.
Al contrario que la opción de la línea de órdenes
<option>--gen-revoke</option>, el efecto de revocación de una subclave es
inmediato.
</para>

<screen width="80">

<prompt>Command&gt;</prompt> <userinput>key</userinput> <parameter>4D88ACC4</parameter>

pub  1024D/1208DD4F  created: 1999-09-24 expires: never      trust: -/u
sub  1024g/B9688D9E  created: 1999-09-24 expires: never
sub* 2016G/4D88ACC4  created: 1999-09-26 expires: 2002-09-25
sub   960D/412EAF0C  created: 1999-09-26 expires: 2002-09-25
(1)  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
(2)  Jordi (oficina) &lt;jordi@castell.com&gt;

<prompt>Command&gt;</prompt> <userinput>revkey</userinput>
Do you really want to revoke this key? y

You need a passphrase to unlock the secret key for
user: "Jordi (Castell S.L.) &lt;jordi@cat.es&gt;"
1024-bit DSA key, ID 1208DD4F, created 1999-09-24

pub  1024D/1208DD4F  created: 1999-09-24 expires: never      trust: -/u
sub  1024g/B9688D9E  created: 1999-09-24 expires: never
sub  2016G/4D88ACC4  created: 1999-09-26 expires: 2002-09-25
rev! subkey has been revoked: 1999-09-26
sub   960D/412EAF0C  created: 1999-09-26 expires: 2002-09-25
(1)  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
(2)  Jordi (oficina) &lt;jordi@castell.com&gt;
</screen>

<para>
La revocación de un identificador de usuario funciona de modo diferente.
Generalmente, un identificador de usuario recolecta firmas que atestigüen que
el identificador de usuario describe a la persona que sea la auténtica
propietaria de la clave asociada.
En teoría un identificador de usuario describe a una persona para siempre,
ya que la identidad de esa persona no cambiará nunca.
En la práctica los elementos del identificador de usuario, como la dirección
de correo electrónico y el comentario, pueden cambiar con el tiempo,
invalidando así el identificador de usuario.
</para>

<para>
Las especificaciones de OpenPGP
<comment>Primera referencia a OpenPGP</comment>
no preveen la revocación del identificador de usuario, pero un identificador
de usuario puede ser revocado de modo efectivo, revocando la autofirma en el
identificador de usuario.
Por razones de seguridad descritas
<link linkend="integrity">anteriormente</link>, los corresponsales no
confiarán en un identificador de usuario con una autofirma no válida.
</para>

<para>
Una firma puede ser revocada mediante la orden
<link linkend="revsig"><command>revsig</command></link>.
Como es posible que hayamos firmado cualquier cantidad de identificadores de
usuario, la interfaz nos pedirá que decidamos si queremos o no revocar cada
una de las firmas.
</para>

<screen width="80">
<prompt>Command></prompt> <userinput>revsig</userinput>
Command> revsig
You have signed these user IDs:
     Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
   signed by 1208DD4F at 1999-09-24
     Jordi (oficina) &lt;jordi@castell.com&gt;
   signed by 1208DD4F at 1999-09-26
user ID: "Jordi (Castell S.L.) &lt;jordi@cat.es&gt;"
signed with your key 1208DD4F at 1999-09-24
Create a revocation certificate for this signature? (y/N)n
user ID: "Jordi (oficina) &lt;jordi@castell.com&gt;"
signed with your key 1208DD4F at 1999-09-26
Create a revocation certificate for this signature? (y/N)y
You are about to revoke these signatures:
     Jordi (oficina) &lt;jordi@castell.com&gt;
   signed by 1208DD4F at 1999-09-26
Really create the revocation certificates? (y/N)y

You need a passphrase to unlock the secret key for
user: "Jordi (Castell S.L.) &lt;jordi@cat.es&gt;"
1024-bit DSA key, ID 1208DD4F, created 1999-09-24

Enter passphrase:

pub  1024D/1208DD4F  created: 1999-09-24 expires: never      trust: -/u
sub  1024g/B9688D9E  created: 1999-09-24 expires: never
sub  2016G/4D88ACC4  created: 1999-09-26 expires: 2002-09-25
rev! subkey has been revoked: 1999-09-26
sub   960D/412EAF0C  created: 1999-09-26 expires: 2002-09-25
(1)  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
(2)  Jordi (oficina) &lt;jordi@castell.com&gt;
</screen>

<para>
Un identificador de usuario revocado vendrá indicado por la firma de
revocación en el identificador, y se podrá ver en las firmas en la lista de
identificadores de usuario de las claves.
</para>

<screen width="80">
<prompt>Command&lt;</prompt> <userinput>check</userinput>
uid  Jordi (Castell S.L.) &lt;jordi@cat.es&gt;
sig!       1208DD4F 1999-09-24   [self-signature]
uid  Jordi (oficina) &lt;jordi@castell.com&gt;
rev!       1208DD4F 1999-09-26   [revocation]
sig!       1208DD4F 1999-09-26   [self-signature]
sig!       B87DBA93 1999-06-28   [self-signature]
</screen>

<para>
Al revocar tanto las subclaves como las autofirmas en los identificadores de
usuarios, añadimos autofirmas de revocación a la clave.
Ya que las firmas son añadidas a la clave y no eliminamos nada, una
revocación siempre estará visible para otros usuarios desde el momento en el
que la actualización de nuestra clave pública sea distribuida y fusionada con
las copias más viejas de ésta.
Por lo tanto, la revocación garantiza que todos los usuarios tengan una copia
consistente de nuestra clave pública.
</para>
</sect2>

<sect2>
<title>
Actualizar la fecha de caducidad de una clave
</title>

<para>
La fecha de caducidad de una clave puede ser actualizada con la orden
<link linkend="expire"><command>expire</command></link>
desde el menú de edición de la clave.
Si no se selecciona ninguna clave, se actualizará la fecha de caducidad de la
clave primaria.
De otro modo, se actualizará la fecha de caducidad de la clave subordinada
que hayamos seleccionado.
</para>

<para>
La fecha de caducidad de una clave está asociada con la autofirma de la
clave.
La fecha de caducidad se actualiza eliminando la autofirma antigua y
añadiendo una nueva autofirma.
Ya que los corresponsales no habrán eliminado la autofirma antigua, verán una
autofirma adicional en la clave cuando actualicen su copia de nuestra clave.
La última autofirma es la que tiene precedencia, así que todos los
corresponsales pueden saber sin ambigüedad las fechas de caducidad de
nuestras claves.
</para>
</sect2>
</sect1>

<sect1>
<title>
Validar otras claves en nuestro anillo de claves públicas
</title>

<para>
En el capítulo <xref linkend="intro"> se introdujo un procedimiento para
validar las claves públicas de otros usuarios:  la clave de otro usuario se
valida comprobando personalmente la huella digital de su clave, y firmando su
clave pública con nuestra clave privada.
Comprobando personalmente la huella digital podemos estar seguros de que la
clave pertenece realmente al supuesto usuario y, dado que hemos firmado la
clave, podemos estar seguros de que detectaremos cualquier manipulación o
falsificación en un futuro.
Desafortunadamente este proceso se complicado cuando debemos validar un gran
número de claves o cuando debemos comunicarnos con personas a las que no
conocemos personalmente.
</para>

<para>
&Gnupg; trata este problema con un mecanismo conocido como
<firstterm>anillo de confianza</firstterm>.
En el modelo del anillo de confianza la responsabilidad de la validación de
las claves públicas recae en las personas en las que confiamos.
Por ejemplo, supongamos que
<itemizedlist spacing="compact">
<listitem>
<para>
Javier ha firmado la clave de Arancha y que,
</para>
</listitem>
<listitem>
<para>
Arancha ha firmado las claves de Jordi y de Ignacio.
</para>
</listitem>
</itemizedlist>

Si Javier confía en Arancha lo suficiente como para validar las claves que él
firma, entonces Javier puede deducir que las claves de Jordi y de Ignacio son
válidas sin llegar a comprobarlas personalmente.
Javier se limitará a usar su copia validada de la clave pública de Arancha para
comprobar que las firmas de Arancha sobre Jordi e Ignacio son auténticas.
Por lo general, y asumiendo que Javier confíe plenamente en todos como para
validar las claves que firmen, cualquier clave firmada por una clave válida
también es considerada válida.
El origen es la clave de Javier, que se asumirá axiomáticamente como válida.
</para>

<sect2>
<title>
Confianza en el propietario de una clave
</title>

<para>
En la práctica la confianza es algo subjetivo.
Por ejemplo, la clave de Arancha es válida para Javier ya que ha sido firmada
por ella, pero Javier puede desconfiar de otras claves que hayan sido
validadas por la firma de Arancha.
En este caso, Javier no aceptaría las claves de Jordi e Ignacio como válidas
sólo porque hayan sido firmadas por Arancha.
El modelo del anillo de confianza prevee este caso mediante un indicador que
asocia nuestro nivel de confianza en el propieario de la clave, a cada clave
pública en nuestro anillo de claves.
Existen cuatro niveles de confianza:

<variablelist>
<varlistentry>
<term>
unknown
</term>
<listitem>
<para>
Desconocido.
No se sabe nada sobre el dueño de la clave firmante.
Las claves en nuestro anillo de claves que no nos pertenezcan tendrán al
principio este nivel de confianza.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
none
</term>
<listitem>
<para>
Ninguno.
Se sabe que el propietario firma otras claves de modo impropio.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
marginal
</term>
<listitem>
<para>
Marginal.
El propietario comprende las implicaciones de firmar una clave y valida las
claves de forma correcta antes de firmarlas.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
full
</term>
<listitem>
<para>
Absoluto.
El propietario comprende perfectamente las implicaciones de firmar una clave
y su firma sobre una clave es tan buena como la nuestra.
</para>
</listitem>
</varlistentry>
</variablelist>

El nivel de confianza en una clave es algo que sólo nosotros podemos asignar
a la clave, y se considera información privada.
El nivel de confianza no se exporta con la clave, de hecho no se almacena en
los anillos de claves sino en una base de datos aparte.
</para>

<para>
El editor de claves de &gnupg; puede ser usado para ajustar nuestra confianza
en el propietario de una clave.
La orden es <link linkend="trust"><command>trust</command></link>.
En el siguiente ejemplo Javier edita su confianza en Arancha y actualiza la base
de datos para recomputar qué claves son válidas, basándose en su nuevo nivel
de confianza en Arancha.

<screen width="80">
<prompt>javier:~$</prompt> <userinput>gpg --edit-key Aranzanzu</userinput>

pub  1024D/B63E132C  created: 1999-09-24 expires: never      trust: q/f
sub  1024g/581A915F  created: 1999-09-24 expires: never
(1)  Ar\xc3\xa1nzazu (A.G.deZ.) &lt;arancha@nav.es&gt;

<prompt>Command&gt;</prompt> <userinput>trust</userinput>
pub  1024D/B63E132C  created: 1999-09-24 expires: never      trust: q/f
sub  1024g/581A915F  created: 1999-09-24 expires: never
(1)  Ar\xc3\xa1nzazu (A.G.deZ.) &lt;arancha@nav.es&gt;

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/B63E132C  created: 1999-09-24 expires: never      trust: m/f
sub  1024g/581A915F  created: 1999-09-24 expires: never
(1)  Ar\xc3\xa1nzazu (A.G.deZ.) &lt;arancha@nav.es&gt;

<prompt>Command></prompt> <userinput>quit</userinput>
[...]
</screen>

La confianza en el propietario de la clave y la validez de la clave se
indican a la derecha al mostrar la clave.
La confianza en el propietario se muestra primero, y la validez
después<footnote><para>N. de T.:  &Gnupg; hace un uso excesivo de la palabra 
&ldquo;trust&rdquo;, utilizándola en el sentido de &laquo;confianza en el 
propietario y confianza en la clave&raquo;.
Esto puede llevar a confusión.
Algunas veces la confianza en un propietario viene referida como
<firstterm>owner-trust</firstterm>
para distinquirla de la confianza en una clave.
Sin embargo, a lo largo de este manual &ldquo;trust&rdquo; se usa en el 
sentido de &laquo;confianza en el propietario de la clave&raquo;, y
&ldquo;validity&rdquo; en el sentido de &laquo;confianza en que una clave
pertenece a la persona asociada con el identificador de clave&raquo;.
</para></footnote>.
Los cuatro niveles de confianza/validez se encuentran abreviados: unknown
(<literal>q</literal>), none (<literal>n</literal>), marginal
(<literal>m</literal>), y full (<literal>f</literal>).
O sea, <firstterm>desconocido</firstterm>, <firstterm>ninguno</firstterm>,
<firstterm>marginal</firstterm> y <firstterm>absoluto</firstterm>.
En este caso, la clave de Arancha es totalmente válida ya que está firmada por
Javier.  Al principio el nivel de confianza que Javier tiene en Arancha es
desconocido, por lo que no procede validar otras claves;
pero luego decide confiar en ella de modo marginal.
</para>
</sect2>

<sect2>
<title>
Usar la confianza para validar las claves
</title>

<para>
El anillo de confianza permite usar un algoritmo más elaborado para validar
una clave.
Anteriormente, una clave sólo se consideraba válida si la firmábamos
nosotros personalmente.
<!-- HERE, math -->
Ahora es posible usar un algoritmo más flexible:  una clave
<emphasis>K</emphasis> se considera válida si cumple dos condiciones:
<orderedlist spacing="compact">
<listitem>
<para>
si viene firmada por las suficientes claves válidas, lo que quiere decir
<itemizedlist spacing="compact">
<listitem>
<para>
que la hemos firmado nosotros personalmente,
</para>
</listitem>
<listitem>
<para>
o que ha sido firmada por una clave de plena confianza,
</para>
</listitem>
<listitem>
<para>
o que ha sido firmada por tres claves de confianza marginal;
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
<!-- HERE, math -->
y si el camino de claves firmadas que nos lleva desde <emphasis>K</emphasis>
hasta nuestra propia clave es de cinco pasos o menos.
</para>
</listitem>
</orderedlist>

La longitud del camino, en número de claves con confianza marginal
requeridas, y el número de claves con confianza plena requeridas se pueden
cambiar.
Los números dados arriba son los valores por definición usados por &gnupg;.
</para>

<para>
<xref linkend="wot-examples"> muestra un anillo de confianza cuyo origen está
en Javier.
El gráfico ilustra quién ha firmado las claves de quién.
La tabla muestra qué claves son consideradas válidas por Javier en base a su
confianza en otros miembros del anillo.
<comment>Un error potential: <option>--completes-needed</option> en la línea
de órdenes, parece que es ignorado al combinarlo con
<option>--update-trustdb</option>.
Sin embargo, el valor se toma correctamente si se pone en el fichero
&dquo;options&dquo;.</comment>
Este ejemplo asume que se necesitan dos claves de confianza marginal o una
de confianza plena para validar otra clave.
La longitud máxima del camino es tres.
</para>

<para>
Al computar claves válidas en el ejemplo, las de Arancha e Ignacio siempre son
consideradas como totalmente válidas, ya que están directamente firmadas por
Javier.
La validez de las otras claves depende de la confianza.
En el primer caso la confianza en Ignacio es plena, lo que implica que las
claves de Jordi y Claudia se considerarán válidas.
En el segundo ejemplo la confianza en Arancha e Ignacio es marginal.
Ya que son necesarias dos claves de confianza marginal para dar validez total
a una clave, la clave de Jordi será considerada como totalmente válida, pero
la clave de Claudia será considerada sólo como marginalmente válida.
En el caso en el que Jordi e Ignacio tuvieran confianza marginal, la clave de
Jordi sería marginalmente válida ya que la clave de Ignacio es totalmente
válida.
Sin embargo, la clave de Claudia será considerada marginalmente válida ya que
sólo se puede usar una clave completamente válida para validar otras claves,
y la clave de Ignacio es la única clave válida que se ha usado para firmar la
clave de Claudia.
Al añadir un nivel de confianza marginal a Arancha, la clave de Jordi se
convierte en totalmente válida y por tanto puede ser usada para validar
totalmente la clave de Claudia, y validar marginalmente la clave de Jimena.
Por último, una confianza plena en Arancha, Jordi y Jimena es todavía
insuficiente para validar la clave de Gonzalo ya que el camino máximo de
certificación es tres, pero la longitud del camino desde Gonzalo hasta Javier es
cuatro.
</para>

<para>
El modelo del anillo de confianza es una aproximación flexible al problema
del intercambio seguro de claves públicas.
Nos permite poner a punto &gnupg; para que refleje el modo en que lo usamos.
Es posible llegar a insistir en múltiples caminos cortos desde nuestra clave
hasta otra clave <emphasis>K</emphasis> para cambiar el nivel de confianza.
Por otra parte, puede ser que caminos más largos nos satisfagan e incluso
un sólo camino desde nuestra clave hasta la otra clave
<emphasis>K</emphasis>.
El requerimiento de múltiples caminos cortos es una fuerte garantía de que
<emphasis>K</emphasis> pertenece a quien nosotros creemos.
El precio, por supuesto, es la dificultad añadida para validar claves, ya que
debemos firmar personalmente más claves que si aceptáramos menos y más largos
caminos.
</para>

<figure id="wot-examples" float=1>
<title>
Un anillo de confianza hipotético
</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.
-->

<mediaobject>
  <!-- using marked sections here is not the perfect solution but
       until we have figured out how to modify the stylesheets to
       prefer one format over another depending on the backend,
       we can do it this way.
       The current TeX stylesheet takes only the first imageobject
       We do mark only the first imageobject so that the mediaobject
       is valid without requiring to do an nsgmls -i foo.
  -->
  <![ %tex; [
  <imageobject>
    <imagedata fileref="signatures.eps" format="eps">
  </imageobject>
  ]]>
  <imageobject>
    <imagedata fileref="signatures.jpg" format="jpg">
  </imageobject>
  <textobject>
     <phrase>A graph indicating who has signed who's key</phrase>
  </textobject>
  <textobject>
     <para>
      Some longer blurb to verbal describe the excact content
      of the image.  This may be of use for a Braille display.
     </para>
  </textobject>
</mediaobject>

<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>
<row>
<entry spanname="lefthalf">trust/confianza</entry>
<entry spanname="righthalf">validity/validez</entry>
</row>
<row>
<entry align="center">marginal</entry>
<entry align="center">full/plena</entry>
<entry align="center">marginal</entry>
<entry align="center">full/plena</entry>
</row>
</thead>
<tbody>
<row>
<entry></entry>
<entry>Ignacio</entry>
<entry></entry>
<entry>Arancha, Jordi, Ignacio, Claudia</entry>
</row>

<row>
<entry>Arancha, Ignacio</entry>
<entry></entry>
<entry>Claudia</entry>
<entry>Arancha, Jordi, Ignacio</entry>
</row>

<row>
<entry>Jordi, Ignacio</entry>
<entry></entry>
<entry>Jordi, Claudia</entry>
<entry>Arancha, Ignacio</entry>
</row>

<row>
<entry>Arancha, Jordi, Ignacio</entry>
<entry></entry>
<entry>Jimena</entry>
<entry>Arancha, Jordi, Ignacio, Claudia</entry>
</row>

<row>
<entry></entry>
<entry>Arancha, Jordi, Jimena</entry>
<entry></entry>
<entry>Arancha, Jordi, Jimena, Claudia</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</figure>
</sect2>
</sect1>

<sect1>
<title>
Distribución de claves
</title>

<para>
Lo ideal sería que pudiéramos distribuir nuestra clave entregándosela en
persona a nuestros corresponsales.
Sin embargo, en la práctica las claves se distribuyen a menudo por correo
electrónico o algún otro medio de comunicación electrónica.
La distribución por correo electrónico es una buena práctica sólo cuando
tengamos unos pocos corresponsales, e incluso si tuviéramos muchos
corresponsales, podríamos usar un medio alternativo como puede ser publicar
nuestra clave pública en nuestra página en internet.
Pero esto es inútil si las personas que necesitan nuestra clave pública no 
saben dónde encontrar nuestra página.
</para>

<para>
Para solventar este problema existen los servidores de claves públicas que
recolectan y distribuyen las claves públicas.
Cuando un servidor recibe una clave pública, bien la añade a la base de datos
o bien la fusiona con una copia de la clave.
Cuando alguien requiere al servidor una clave pública, éste la busca en la
base de datos y, si la encuentra, la envía a quien se la haya solicitado.
</para>

<para>
Los servidores de claves también son útiles cuando hay muchas personas que
firman las claves de otras con frecuencia.
Sin un servidor de claves, cuando Arancha firmara la clave de Javier, debería
enviar a éste una copia de la clave firmada por ella de manera que Javier
pudiera añadir la clave firmada a su anillo de claves, así como distribuirla a
todos sus corresponsales.
Mediante este proceso Javier y Arancha sirven a la totalidad de la comunidad
construyendo lazos en forma de anillos de confianza o lo que es lo mismo,
mejorando la seguridad de PGP.
De todos modos esto es una molestia si se firman las claves con frecuencia.
</para>

<para>
El uso de un servidor de claves facilita este proceso.
Después de firmar la clave de Javier, Arancha puede enviar la copia firmada por
ella al servidor de claves.
El servidor de claves añade la firma de Arancha a la copia que ya existente
de la clave pública de Javier.
Las personas que estén interesadas en actualizar su copia de la clave de
Javier consultan al servidor por propia iniciativa para obtener la clave
actualizada.
Javier no necesita distribuir la clave y puede obtener las firmas en su clave
requiriéndolas al servidor.
<comment>La opción <option>--keyserver</option> debe preceder a las opciones
<option>--send-key</option> o <option>--recv-key</option>.
Esto es un error.</comment>
</para>

<para>
Se puede enviar una o más claves usando la opción de la línea de órdenes
<link linkend="send-keys"><option>--send-keys</option></link>.
Esta opción toma uno o más especificadores de clave, y envía las claves
especificadas al servidor de claves.
El servidor al que se envían las claves es especificado con la opción de la
línea de orden <link linkend="keyserver"><option>--keyserver</option></link>.
Paralelamente, la opción
<link linkend="recv-keys"><option>--recv-keys</option></link> se usa para
obtener claves desde un servidor de claves, pero la opción
<option>--recv-keys</option> requiere el uso de un identificador de clave
para poder especificar la clave deseada.
En el siguiente ejemplo Javier actualiza su clave pública con nuevas firmas
desde el servidor de claves <parameter>certserver.pgp.com</parameter> y acto
seguido envía su copia de la clave pública de Arancha al mismo servidor de
claves para que se actualice con las claves que él mismo pueda haber
añadido.

<screen width="80">
<prompt>javier:~$</prompt> <userinput>gpg --keyserver certserver.pgp.com
--recv-key D58711B7</userinput>
gpg: requesting key D58711B7 from certserver.pgp.com ...
gpg: key D58711B7: 1 new signature

gpg: Total number processed: 1
gpg:         new signatures: 1
<prompt>javier:~$</prompt> <userinput>gpg --keyserver certserver.pgp.com
--send-key arancha@nav.es</userinput>
gpg: success sending to 'certserver.pgp.com' (status=200)
</screen>

Existen varios servidores de claves en funcionamiento en todo el mundo.
Los servidores más importantes están sincronizados de modo que es posible
elegir un servidor de claves cercano a nosotros en Internet y usarlo de
forma regular para enviar y recibir claves.
</para>
</sect1>

</chapter>
