/usr/share/doc/gnupg-doc/GNU_Privacy_Handbook/de/html/c319.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Schlüsselverwaltung</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Das GNU-Handbuch zum Schutze der Privatsphäre"
HREF="book1.htm"><LINK
REL="PREVIOUS"
TITLE="Digitale Signaturen"
HREF="x275.htm"><LINK
REL="NEXT"
TITLE="Authentisieren anderer Schlüssel"
HREF="x420.htm"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Das GNU-Handbuch zum Schutze der Privatsphäre</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x275.htm"
ACCESSKEY="P"
>Zurück</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x420.htm"
ACCESSKEY="N"
>Weiter</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="MANAGEMENT"
></A
>Kapitel 3. Schlüsselverwaltung</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Inhaltsverzeichnis</B
></DT
><DT
><A
HREF="c319.htm#AEN327"
>Verwaltung Ihres Schlüsselpaares</A
></DT
><DT
><A
HREF="x420.htm"
>Authentisieren anderer Schlüssel</A
></DT
><DT
><A
HREF="x569.htm"
>Weitergabe von Schlüsseln</A
></DT
></DL
></DIV
><P
>Schlüsselverfälschungen sind ein nicht zu unterschätzender
Unsicherheitsfaktor bei der Public-Key-Kryptographie. Ein Angreifer
kann beispielsweise die Schlüsselbunde eines Benutzers manipulieren
oder sich einen öffentlichen Schlüssel mit einer vorgetäuschten
Identität erzeugen und ihn an andere zum Herunterladen und Benutzen
schicken. Wenn z.B. Chloe unbemerkt die Nachrichten, welche Alice an
Blake sendet, lesen will, dann könnte sie folgendermaßen vorgehen:
zuerst erzeugt sie ein neues Schlüsselpaar mit einer gefälschten
Benutzer-ID. Dann ersetzt sie Alices Kopie von Blakes öffentlichem
Schlüssel durch den neuen Schlüssel. Anschließend fängt sie die
Nachrichten ab, die Alice an Blake sendet. Diese Nachrichten kann sie
dann mit dem neuen geheimen Schlüssel entschlüsseln. Dann verschlüsselt
sie die Nachricht wieder, aber diesmal mit dem echten öffentlichen
Schlüssel von Blake und schickt sie weiter an Blake. Chloe kann jetzt
- ohne daß jemand etwas bemerkt - alle von Alice an Blake geschickten
Nachrichten mitlesen.</P
><P
>Eine gute Schlüsselverwaltung ist entscheidend für die Integrität
Ihrer eigenen Schlüsselbunde, wie auch der Schlüsselbunde anderer
Benutzer. Der Kern der Schlüsselverwaltung von GnuPG ist das
<I
CLASS="EMPHASIS"
>Signieren von Schlüsseln</I
> und verfolgt zwei
Hauptzwecke: es erlaubt Ihnen, Verfälschungen an Ihrem Schlüsselbund zu
entdecken, und es ermöglicht Ihnen, die Zugehörigkeit eines Schlüssels
zu der von der jeweiligen Benutzer-ID genannten Person zu überprüfen.
Schlüsselunterschriften werden in einem <I
CLASS="FIRSTTERM"
>Web of
Trust</I
> genannten Schema benutzt, um die Authentisierung
auch auf Schlüssel auszudehnen, die nicht direkt von Ihnen selbst,
sondern von anderen Personen, denen Sie zutrauen, Schlüssel nur nach
sorgfältiger Prüfung zu signieren, signiert worden sind. Durch eine
gewissenhafte Schlüsselverwaltung können Sie Schlüsselverfälschungen
als einen praktischen Angriff auf ihre sichere und vertrauliche
Kommunikation abwehren.</P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN327"
>Verwaltung Ihres Schlüsselpaares</A
></H1
><P
>Ein Schlüsselpaar besteht aus einem öffentlichen und einem geheimen
Schlüssel und einem Satz von Benutzer-IDs, um die Schlüssel
einer realen Person zuzuordnen. Jeder dieser Bestandteile enthält
Informationen über sich selbst. Bei einem öffentlichen Schlüssel sind
dies seine ID sowie Angaben darüber, wann er erzeugt worden ist, wann
seine Gültigkeit abläuft usw. Bei der Benutzer-ID sind das der Name der
realen Person, die durch die ID identifiziert wird, eine optionale
Bemerkung sowie eine E-mail-Adresse. Der geheime Schlüssel enthält
dagegen keine Informationen über die Benutzer-ID.</P
><P
>Wenn Sie Informationen über ein Schlüsselpaar sehen möchten, dann
rufen Sie am besten mit der Kommandozeilen-Option
<CODE
CLASS="OPTION"
>--edit-key</CODE
>
den Schlüsseleditor auf.
Zum Beispiel:

<PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>chloe$ </TT
>
<KBD
CLASS="USERINPUT"
>gpg --edit-key chloe@cyb.org</KBD
>
Geheimer Schlüssel ist vorhanden.

pub  1024D/1B087D04  created: 2000-06-07 expires: never      trust: -/u
sub  2048g/6A3E902A  created: 2000-06-07 expires: never     
sub  1792G/7D5D4DAE  created: 2000-06-07 expires: 2002-06-07
sub   960D/C0A27DBE  created: 2000-06-07 expires: 2002-06-07
(1)  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
(2)  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;

<TT
CLASS="PROMPT"
>Befehl&gt;</TT
></PRE
>

Zusammen mit dem öffentlichen Schlüssel wird angezeigt, ob der geheime
Schlüssel verfügbar ist oder nicht. Alle Informationen über die
Bestandteile des öffentlichen Schlüssels werden dann aufgelistet. Die
erste Spalte gibt den Typ des Schlüssels an. Das Schlüsselwort
<TT
CLASS="LITERAL"
>pub</TT
> identifiziert den öffentlichen Hauptschlüssel
 und das Schlüsselwort <TT
CLASS="LITERAL"
>sub</TT
> identifiziert einen
untergeordneten öffentlichen Schlüssel (Subkey). Die zweite Spalte gibt Länge,
Typ und ID des Schlüssels an. Dabei steht <TT
CLASS="LITERAL"
>D</TT
> für
DSA-Schlüssel, <TT
CLASS="LITERAL"
>g</TT
> für einen nur zur Verschlüsselung
geeigneten ElGamal-Schlüssel und <TT
CLASS="LITERAL"
>G</TT
> für einen
ElGamal-Schlüssel, der sowohl zur Verschlüsselung als auch zum
Unterschreiben verwendet werden kann. Das Datum der Erzeugung und das
Verfallsdatum wird in den Spalten drei und vier angegeben. Die
Benutzer-IDs werden nach den Schlüsseln angegeben.</P
><P
>Es stehen noch weitere Befehle zu Verfügung, um
zusätzliche Informationen über die Schlüssel zu erhalten. Der Befehl
<B
CLASS="COMMAND"
>toggle</B
> schaltet
zwischen den öffentlichen und den geheimen Komponenten eines
Schlüsselpaares um, wenn tatsächlich beides zur Verfügung
steht.

<PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>Befehl&gt;</TT
> <KBD
CLASS="USERINPUT"
>toggle</KBD
>

sec  1024D/1B087D04  created: 2000-06-07 expires: never     
sbb  2048g/6A3E902A  created: 2000-06-07 expires: never     
sbb  1792G/7D5D4DAE  created: 2000-06-07 expires: 2002-06-07
sbb   960D/C0A27DBE  created: 2000-06-07 expires: 2002-06-07
(1)  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
(2)  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;</PRE
>

Die Information ist ähnlich der Auflistung für die Komponente des
öffentlichen Schlüssels. Das Schlüsselwort <TT
CLASS="LITERAL"
>sec</TT
>
identifiziert den geheimen Hauptschlüssel und das
Schlüsselwort <TT
CLASS="LITERAL"
>ssb</TT
> identifiziert die
geheimen Subkeys. Die Benutzer-IDs vom öffentlichen Schlüssel
werden der Bequemlichkeit halber auch aufgelistet.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN350"
>Schlüssel-Integrität</A
></H2
><P
>Wenn Sie Ihren öffentlichen Schlüssel weitergeben, so geben Sie
damit die öffentlichen Komponenten Ihres Hauptschlüssels und Ihrer
Subkeys ebenso wie Ihre Benutzer-IDs weiter. Wenn Sie
diese Informationen jedoch ungeschützt weitergeben, so besteht ein
Sicherheitsrisiko, da es für einen potentiellen Angreifer möglich ist,
den Schlüssel zu verfälschen. Der öffentliche Schlüssel kann durch
Hinzufügen oder Ersetzen von Schlüsseln oder von Benutzer-IDs modifiziert
werden. Der Angreifer könnte beispielsweise durch Verfälschen der
E-Mail-Adresse einer Benutzer-ID die E-Mail an sich selbst umleiten. Durch
Veränderung der öffentlichen Schlüssel wäre der Angreifer auch in der
Lage, die zu ihm umgeleiteten Nachrichten zu entschlüsseln.</P
><P
>Die Benutzung digitaler Signaturen ist die Lösung für dieses
Problem. Indem man den öffentlichen Schlüssel sowie die Benutzer-IDs mit
seinem geheimen Schlüssel unterzeichnet, lassen sich Verfälschungen
daran leicht feststellen. Dieser Vorgang wird
Eigenbeglaubigung genannt; ein
öffentlicher Schlüssel, der eigenbeglaubigte Benutzer-IDs enthält,
wird <I
CLASS="FIRSTTERM"
>Zertifikat</I
> genannt.</P
><P
>Ein Beispiel: Chloe hat zwei Benutzer-IDs und drei untergeordnete
öffentliche Schlüssel bzw. Subkeys. Die Unterschriften auf den
Benutzer-IDs können mit dem Befehl
<B
CLASS="COMMAND"
>check</B
> im
Schlüsseleditior geprüft werden.

<PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>chloe$ </TT
> <KBD
CLASS="USERINPUT"
>gpg --edit-key chloe</KBD
>
geheimer Schlüssel ist vorhanden.

pub  1024D/1B087D04  created: 2000-06-07 expires: never      trust: -/u
sub  2048g/6A3E902A  created: 2000-06-07 expires: never     
sub  1792G/7D5D4DAE  created: 2000-06-07 expires: 2002-06-07
sub   960D/C0A27DBE  created: 2000-06-07 expires: 2002-06-07
(1)  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
(2)  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;

<TT
CLASS="PROMPT"
>Befehl&gt;</TT
> <KBD
CLASS="USERINPUT"
>check</KBD
>
uid  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
sig!       1B087D04 2000-06-07   [Eigenbeglaubigung]
uid  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;
sig!       1B087D04 2000-06-07   [Eigenbeglaubigung]</PRE
>

Wie erwartet, wird für jede Unterschrift der primäre Schlüssel mit der
Schlüssel-ID <TT
CLASS="LITERAL"
>0x26B6AAE1</TT
> genommen. Die Eigenbeglaubigungen auf
den Subkeys sind in dem öffentlichen Schlüssel enthalten, doch
werden sie vom Schlüsseleditor nicht gezeigt.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN364"
>Editieren von Schlüsseln</A
></H2
><P
>Zu Ihrem ursprünglichen Schlüsselpaar können Sie später sowohl neue
Subkeys als auch neue Benutzer-IDs hinzufügen. Eine neue Benutzer-ID wird durch
Verwendung des Befehls <B
CLASS="COMMAND"
>adduid</B
> erzeugt. Dabei werden Sie wieder
nach Ihrem wirklichem Namen, E-Mail-Adresse und einer optionalen
Bemerkung gefragt. Ein Subkey wird durch Verwendung des Befehls
<B
CLASS="COMMAND"
>addkey</B
>
hinzugefügt und kann von beliebigem Typ sein. Das ist so ähnlich, wie
Sie es vom Erzeugen Ihres anfänglichen Schlüsselpaares kennen. Wenn
Sie einen neuen Subkey oder eine neue Benutzer-ID erzeugen, so werden
diese mit Ihrem geheimen Schlüssel eigenbeglaubigt; deshalb müssen Sie
auch Ihr Mantra eingeben, wenn der Schlüssel erzeugt wird. </P
><P
>Zusätzliche Benutzer-IDs sind nützlich, wenn Sie für verschiedene Zwecke
verschiedene IDs benötigen. So wollen Sie vielleicht eine Benutzer-ID
für Ihre Arbeit, eine für Ihre politische Tätigkeit und eine weitere
für private Korrespondenz haben. Ihre Mitarbeiter und Geschäftspartner,
Politische Mitstreiter und Freunde werden Sie dann jeweils unter einer
anderen ID kennen.</P
><P
>Zusätzliche Subkeys sind ebenfalls nützlich. Die zu
Ihrem primären öffentlichen Schlüssel gehörigen Benutzer-IDs werden von
den Leuten, mit denen Sie kommunizieren, authentisiert, deshalb
erfordert eine Änderung des primären Schlüssels eine nochmalige
Bestätigung. Wenn Sie mit vielen Leuten kommunizieren, kann dies
schwierig und zeitaufwendig sein. Andererseits ist es gut, von Zeit zu
Zeit die Subkeys für die Verschlüsselung zu ändern. Wenn
ein Schlüssel kompromittiert wurde, ist die Sicherheit aller mit diesem
Schlüssel verschlüsselten Daten gefährdet. Durch das Ändern der
Schlüssel erreichen Sie jedoch, daß in der Zukunft zu verschlüsselnde
Daten nicht auch noch gefährdet werden.</P
><P
>Subkeys und Benutzer-IDs können auch gelöscht werden. Dazu müssen Sie
diese zunächst im Schlüsseleditor auswählen, indem Sie die Befehle
<B
CLASS="COMMAND"
>key</B
> bzw.
<B
CLASS="COMMAND"
>uid</B
>
benutzen. So wählt beispielsweise der Befehl <B
CLASS="COMMAND"
>key
<TT
CLASS="PARAMETER"
><I
>2</I
></TT
></B
> den zweiten Subkey aus; ein
nochmaliger Aufruf des Befehls <B
CLASS="COMMAND"
>key
<TT
CLASS="PARAMETER"
><I
>2</I
></TT
></B
> macht diese Auswahl wieder
rückgängig. Wird <B
CLASS="COMMAND"
>key</B
> ohne Argument aufgerufen, wird
die komplette Auswahl an Subkeys wieder aufgehoben. Das gleiche gilt
für den Befehl <B
CLASS="COMMAND"
>uid</B
>. Wenn Sie die zu löschenden
Benutzer-IDs ausgewählt haben, werden diese mit dem Befehl <B
CLASS="COMMAND"
>deluid</B
> aus Ihrem Schlüssel
entfernt. Ebenso löscht der Befehl <B
CLASS="COMMAND"
>delkey</B
> alle ausgewählten Subkeys aus Ihren
öffentlichen und geheimen Schlüsseln.</P
><P
>Für die lokale Schlüsselverwaltung ist das Löschen von
Schlüssel-Komponenten ein geeignetes Mittel, um die öffentlichen
Schlüssel anderer von unnötigem Ballast frei zu halten. Hingegen
sollten Sie normalerweise keine Benutzer-IDs und Subkeys von Ihrem
eigenen Schlüssel entfernen, da Sie so die Weiterverbreitung dieses
Schlüssels verkomplizieren. Wenn ein anderer GnuPG-Benutzer Ihren
aktuellen öffentlichen Schlüssel importiert, wird dieser
standardmäßig mit dessen alter Kopie Ihres öffentlichen Schlüssels
zusammengeführt. Dadurch werden effektiv alle Komponenten wieder
hergestellt, die Sie gelöscht haben. Um den Schlüssel wirklich zu
aktualisieren, müßte der Benutzer zuerst die alte Version Ihres
Schlüssels löschen und dann die neue Version importieren. Dies bringt
eine zusätzliche Belastung für Ihre Kommunikationspartner mit
sich. Es ist daher auch keine gute Idee, Ihren aktualisierten Schlüssel zu
einem Key-Server zu schicken. Zum Aktualisieren Ihres eigenen
Schlüssels ist es folglich besser, die jeweiligen Schlüsselkomponenten
zu widerrufen, statt sie zu löschen.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN389"
>Widerrufen von Schlüssel-Komponenten</A
></H2
><P
>Um einen Subkey zu widerrufen, wählen Sie ihn im Schlüsseleditor aus,
dann können Sie ihn mit dem Befehl
<B
CLASS="COMMAND"
>revkey</B
>
widerrufen. Der Schlüssel wird dadurch widerrufen, daß
man dem Schlüssel eine Widerruf-Unterschrift hinzufügt.
Anders als bei der Kommandozeilen-Option <CODE
CLASS="OPTION"
>--gen-revoke</CODE
>
tritt der Widerruf sofort in Kraft.</P
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>Befehl&gt;</TT
> <KBD
CLASS="USERINPUT"
>key 2</KBD
>

pub  1024D/1B087D04  created: 2000-06-07 expires: never      trust: -/u
sub  2048g/6A3E902A  created: 2000-06-07 expires: never     
sub* 1792G/7D5D4DAE  created: 2000-06-07 expires: 2002-06-07
sub   960D/6E82436B  created: 2000-06-07 expires: 2002-06-07
(1)  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
(2)  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;

<TT
CLASS="PROMPT"
>Befehl&gt;</TT
> <KBD
CLASS="USERINPUT"
>revkey</KBD
>
Möchten Sie diesen Schlüssel wirklich wiederrufen? j
                                                    
Sie benötigen ein Mantra, um den geheimen Schlüssel zu entsperren.
Benutzer: "Chloe (Journalistin) &lt;chloe@cyb.org&gt;"
1024-Bit DSA Schlüssel, ID 1B087D04, erzeugt 2000-06-07

                          
pub  1024D/1B087D04  created: 2000-06-07 expires: never      trust: -/u
sub  2048g/6A3E902A  created: 2000-06-07 expires: never     
sub  1792G/7D5D4DAE  created: 2000-06-07 expires: 2002-06-07
rev! subkey has been revoked: 2000-06-07
sub   960D/6E82436B  created: 2000-06-07 expires: 2002-06-07
(1)  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
(2)  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;</PRE
><P
>Beim Widerrufen einer Benutzer-ID wird anders verfahren. Durch
Unterschriften auf einer Benutzer-ID wird bestätigt, daß der Eigentümer
des Schlüssels tatsächlich identisch mit der in der Benutzer-ID genannten
Person ist. In der Theorie beschreibt eine Benutzer-ID eine Person für
immer, da diese Person sich nie ändert. In der Praxis können sich
jedoch Elemente der Benutzer-ID, so z.B. die E-Mail-Adresse oder eine
Bemerkung, mit der Zeit verändern und so die Benutzer-ID unbrauchbar
machen.</P
><P
>Die Spezifikation von OpenPGP unterstützt den Widerruf einer
Benutzer-ID nicht. Man kann sich aber dadurch helfen, daß man seine
Eigenbeglaubigung für die entsprechende Benutzer-ID widerruft. Aus den
<A
HREF="c319.htm#AEN350"
>zuvor</A
> beschriebenen
Sicherheitsgründen werden die Korrespondenzpartner keiner Benutzer-ID
ohne gültige Eigenbeglaubigung trauen, GnuPG lehnt den Import eines
solchen Schlüssels sogar gänzlich ab.</P
><P
>Eine Unterschrift wird unter Verwendung des Befehls
<B
CLASS="COMMAND"
>revsig</B
>.
widerrufen. Da Sie eine beliebige Zahl von Benutzer-IDs
unterschrieben haben können, verlangt der Schlüsseleditor
von Ihnen für jede Unterschrift eine Entscheidung, ob
sie widerrufen werden soll oder nicht.</P
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>Befehl&gt;</TT
> <KBD
CLASS="USERINPUT"
>revsig</KBD
>
Befehl&#62; revsig
Sie haben folgende User-IDs beglaubigt:
     Chloe (Journalistin) &lt;chloe@cyb.org&gt;
   beglaubigt durch 1B087D04 um 2000-06-07
   beglaubigt durch 1B087D04 um 2000-06-07
User-ID: ``Chloe (Journalistin) &lt;chloe@cyb.org&gt;''
unterschrieben mit Ihrem Schlüssel 1B087D04 um 2000-06-07
Ein Widerrufszertifikat für diese Unterschrift erzeugen (j/N)n
User-ID: ``Chloe (Freie Autorin) &lt;chloe@tel.net&gt;''
unterschrieben mit Ihrem Schlüssel 1B087D04 um 2000-06-07
Ein Widerrufszertifikat für diese Unterschrift erzeugen (j/N)j
Es werden nun folgende Beglaubigungen entfernt:               
     Chloe (Freie Autorin) &lt;chloe@tel.net&gt;
   beglaubiigt durch 1B087D04 um 2000-06-07
Wirklich ein Unterschrift-Widerrufszertifikat erzeugen? (j/N) j
                                                               
Sie benötigen ein Mantra, um den geheimen Schlüssel zu entsperren.
Benutzer: ``Chloe (Journalistin) &lt;chloe@cyb.org&gt;''
1024-Bit DSA Schlüssel, ID 1B087D04, erzeugt 2000-06-07

                          
pub  1024D/1B087D04  created: 2000-06-07 expires: never      trust: -/u
sub  2048g/6A3E902A  created: 2000-06-07 expires: never     
sub  1792G/7D5D4DAE  created: 2000-06-07 expires: 2002-06-07
rev! subkey has been revoked: 2000-06-07
sub   960D/6E82436B  created: 2000-06-07 expires: 2002-06-07
(1)  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
(2)  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;&#13;</PRE
><P
>Eine widerrufene Benutzer-ID wird durch die Widerrufs-Signatur auf
der Benutzer-ID angezeigt, wenn die Unterschriften auf den
Benutzer-IDs des Schlüssels aufgelistet werden.</P
><PRE
CLASS="SCREEN"
><TT
CLASS="PROMPT"
>Befehl</TT
> <KBD
CLASS="USERINPUT"
>check</KBD
>

uid  Chloe (Journalistin) &lt;chloe@cyb.org&gt;
sig!       1B087D04 2000-06-07   [Eigenbeglaubigung]
uid  Chloe (Freie Autorin) &lt;chloe@tel.net&gt;
rev!       1B087D04 2000-06-07   [Widerruf]
sig!       1B087D04 2000-06-07   [Eigenbeglaubigung]</PRE
><P
>Ein Widerruf sowohl der Subkeys als auch der Eigenbeglaubigung auf
Benutzer-IDs fügt dem Schlüssel eine Widerrufs-Signatur hinzu. Da
also nur etwas hinzugefügt und nichts gelöscht wird, ist ein Widerruf
für andere stets sichtbar, wenn Ihr aktueller öffentlicher Schlüssel
weitergegeben und mit anderen älteren Kopien davon zusammengeführt
wird. Der Widerruf garantiert deshalb, daß jeder die aktuelle Kopie
Ihres öffentlichen Schlüssels haben kann.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN414"
>Aktualisieren des Verfallsdatums</A
></H2
><P
>Das Verfallsdatum eines Schlüssels kann mit dem Befehl
<B
CLASS="COMMAND"
>expire</B
>
im Schlüsseleditor aktualisiert werden. Wenn kein Schlüssel
ausgewählt ist, wird das Verfallsdatum des primären Schlüssels
aktualisiert, ansonsten das des jeweils ausgewählten Subkeys.</P
><P
>Das Verfallsdatum eines Schlüssels ist mit der Eigenbeglaubigung
des Schlüssels verbunden. Es wird dadurch aktualisiert, daß man die
alte Eigenbeglaubigung löscht und eine neue hinzufügt. Da die
Korrespondenzpartner die alte Eigenbeglaubigung noch nicht gelöscht
haben, werden sie eine zusätzliche Eigenbeglaubigung auf dem Schlüssel
sehen, wenn sie ihre Kopie Ihres Schlüssels aktualisieren. Die jüngste
Eigenbeglaubigung hat jedoch jeweils Vorrang, und so werden alle
Korrespondenzpartner unzweideutig die Verfallsdaten Ihrer Schlüssel
kennen.</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x275.htm"
ACCESSKEY="P"
>Zurück</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
ACCESSKEY="H"
>Zum Anfang</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x420.htm"
ACCESSKEY="N"
>Weiter</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Digitale Signaturen</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Authentisieren anderer Schlüssel</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
gnupg-doc 2003.04.06+dak1-1ubuntu1 / usr / share / doc / gnupg-doc / GNU_Privacy_Handbook / de / html / c319.htm
