Linux Security Cookbook [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Security Cookbook [Electronic resources] - نسخه متنی

Daniel J. Barrett, Robert G. Byrnes, Richard Silverman

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










Recipe 7.22 Revoking a Key



7.22.1 Problem




You
want to inform a keyserver that a
particular public key (of yours) is no longer valid.


7.22.2 Solution



  1. Create a revocation certificate:

    $ gpg --gen-revoke --output certificate.asc key_id

  2. Import the certificate:

    $ gpg --import certificate.asc

  3. Revoke the key at the keyserver:

    $ gpg --keyserver server_name --send-keys key_id

  4. Delete the key (optional)

    $ gpg --delete-secret-and-public-key key_id







THINK CAREFULLY BEFORE DELETING A KEY. Once you delete a key, any
files that remain encrypted with this key CANNOT BE DECRYPTED. EVER.


7.22.3 Discussion


At times it becomes necessary to stop using a particular key. For
example:


  • Your private key has been lost.


  • Your private key has been stolen, or you suspect it may have been.


  • You have forgotten your private key passphrase.


  • You replace your keys periodically (say, every two years) to enhance
    security, and this key has expired.



Whatever the reason, it's time to inform others to
stop using the corresponding public key to communicate with you.
Otherwise, if the key is lost, you might receive encrypted messages
that you can no longer decrypt. Worse, if the key has been stolen or
compromised, the thief can read messages encrypted for you.

To tell the world to cease using your key, distribute a

revocation
certificate for that key: a cryptographically secure digital object
that says, "Hey, don't use this
public key anymore!" Once you create the
certificate, send it directly to your communication partners or to a
keyserver [Recipe 7.19] for general distribution.

For security reasons, the revocation certificate is digitally signed
by you, or more specifically, with the private key that it revokes.
This proves (cryptographically speaking) that the person who
generated the certificate (you) is actually authorized to make this
decision.

But wait: how can you create and sign a revocation certificate if
you've lost the original private key necessary for
signing it? Well, you can't.[3]
Instead, you should create the certificate in advance, just in case
you ever lose the key. As standard practice, you should create a
revocation certificate immediately each time you generate a new key.
[Recipe 7.6]

[3] And
this is a good thing. Otherwise,

anybody could
create a revocation certificate for your keys.


Guard your revocation certificate as carefully as your private key.
If a thief obtains it, he can publish it (anonymously) and
immediately invalidate your keys, causing you a big headache.


7.22.4 See Also


http://www.keyserver.net/en/infol and
http://www.keyserver.net/en/aboutl.

/ 247