Revocation Certificates

Lawrence Chin kurtc1972 at gmail.com
Sat Oct 4 22:49:52 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kara wrote:
> ====
> 
> Reference Faramir's 27 Sep (2218 -0400) "Re: backing up keys etc"
> which responded to your 27 Sep (1738 -0700) "backing up keys etc":
> 
> Lawrence wrote in part:
>>> So, if I need to revoke this public key in the future, I just 
>>> upload it to the keyserver?
> Faramir wrote in part:
>> IIRC, you would need to import the certificate to your keyring, and
>>  then upload the key to the keyserver... once you have done that, 
>> there is no coming back... And I think if you do that, you will 
>> revoke the whole key, with all its UID... the only time I imported 
>> a revocation certificate, the key just had one UID, so I am not 
>> 100% sure about that. And it was very easy to import it (indeed, I 
>> didn't intend to do it).
> 
>     a.  Let's say you have a GPG/PGP key with five userIDs.  You can
>         revoke any four of those userIDs but not the last one since
>         by definition a key must have at least one userID.
> 
>             (1)  A userID has three possible elements:  The "name"
>                  is mandatory, the "e-mail address" and the
>                  "comment" are optional.
> 
>             (2)  A userID that has only a name is referred to as
>                  a free-form userID.
> 
>      b.  If you have a userID and for any reason you no longer wish
>          to use one of its elements because it has either changed or
>          you no longer wish to use it or have it shown on your key,
>          you'd normally revoke the userID.
> 
>              (1)  For example, the userID's "e-mail address"
>                   is no longer active or valid; or the "comment"
>                   indicating you are "CIA Deputy Director" is
>                   no longer valid since you're now the President's
>                   "National Security Advisor"; or the "name" only
>                   shows your first two initials and your last name
>                   and you now wish to use only your full name (e.g.,
>                   first, middle, and last) on the key; or the "name"
>                   is a pseudonym that you no longer wish to use or
>                   have shown on your key.
> 
>              (2)  After revoking the userID you'd upload the key to
>                   a public keyserver and then -- I'd delete that
>                   revoked userID from your key (and from the copy
>                   of your key posted on Biglumber (BL) or the PGP
>                   Global Directory (PGP-GD) if you posted your key
>                   on either site.
> 
>      c.  If you want to revoke all of the key's userIDs, you'd just
>          revoke the key itself and then upload the revoked key to
>          a public keyserver.
> 
>              (1)  Before you delete the revoked key from your
>                   keyring, however, keep in mind that if you
>                   do that you won't be able to decrypt any
>                   messages or files stored in your computer
>                   or on discs that were encrypted with that key.
> 
>              (2)  Also before you delete the revoked key keep
>                   in mind that if someone uses your revoked key
>                   without realizing its been revoked, you won't
>                   be able to decrypt any message they send which
>                   has been encrypted with that key.  Normally that
>                   wouldn't be a problem since you'd contact the
>                   sender and tell them to resend their message
>                   encrypting it with your xxxxxxxx key.
> 
>              (3)  For the majority of individuals subpara (1) and
>                   (2) above are not a problem and you can just
>                   delete the revoked key -- I only mention those
>                   two concerns so you can think of them before you
>                   actually delete the revoked key from your keyring.
> 
>              (4)  Once most folks obtain a copy of your key they
>                   frequently don't later update it via one of the
>                   public keyservers and those individuals won't be
>                   aware you've revoked it.  For those individuals
>                   who you frequently correspond with and that you
>                   know or think might have your revoked key, it is
>                   often helpful to go ahead and notify them of the
>                   key's revocation and tell them what key you wish
>                   them to use in the future when writing you.
> 
> ====
> 
>>> (2) So I used OpenPGP key management, "file" -> "export key to 
>>> file"...I can see each file consists of a public key block and a
>>>  private key block...
> 
> Also keep in mind that when you "export key to file" you are given the
> option of exporting the entire key pair or just the public part of the
> key pair.  Sometimes it's only the public part that you need to save.
> 
> ====
> 
>>> ..  typed in the correct passphrase at my third try. Now, where 
>>> can I find this revocation certificate? I don't even know the 
>>> file name!!!
> 
> a.  *If you've already created the key* (e.g., Dummy <fake at fake.fake>)
>     and wish to use the terminal mode (command line) procedure to
>     create a revocation certificate for it:
> 
>         (1)  Follow the atch 1 procedure.
> 
>         (2)  Note at the end of atch 1 you have the resulting
>              revocation certificate and save it wherever you
>              wish (e.g., on a CD, a flash drive, etc) and titled
>              the saved file as desire.
> 
> b.  *If you choose to create the key with Enigmail* ("Thunderbird |
>     OpenPGP | Key Management | Generate":
> 
>         (1)  You'll first be shown atch 2 for completion, then
> 
>         (2)  After the key has been created you'll get atch 3.
> 
>         (3)  If you answer atch 3 with a "Yes",
> 
>         (4)  You'll get atch 4 which will provide you with
> 
>              (a)  The proposed name (see the red circled area) for
>                   the revocation certificate is one which you can
>                   change as desired, and
> 
>              (b)  The ability to specify where you want the
>                   certificate saved (as indicates by either
>                   the blue or the green circled areas is
>                   one which you can change as desired.
> 
>              (c)  I normally save lots of things on my Desktop
>                   since it's uncluttered and I can easily find
>                   anything I've saved there and either subsequently
>                   delete it or move it elsewhere or copy it on a CD
>                   or flash drive, etc as desired.
> 
>              (d)  You'll note on atch 4 I'm saving it on my Desktop
>                   (which is my default setting for saving files).
>                   If I didn't want to save it there, I'd click on
>                   "Kara" which is where all my other files are
>                   located and then use the "green circled" option
>                   to select a specific folder or file to save the
>                   item.
> 
> c.  Note that since Enigmail is a "Graphic User Interface (GUI) it
>     only allows you to do some of the most common of the procedures
>     GPG is capable of doing.  As a GUI, it currently doesn't permit
>     you to create a key and then _later_ create a revocation
>     certificate for it.  To do the latter, you currently have to use
>     the terminal mode (command line) procedure.
> 
> ====
> 
> *Repeating again*:
> 
>>> ...Now, where can I find this revocation certificate? I don't 
>>> even know the file name!!!
>> Good question... I think it should be in the same folder where your
>>  backup key files were exported... and the name should be something
>>  like the one you showed us in the question n°1, something like 
>> "email address (keyID number) rev.asc". If it is not there, it 
>> could be at C:\Documents and Settings\YourWindowsUserName\  or 
>> maybe in the GnuPG folder, since you was working at that folder 
>> when you generated the rev certificate.
> 
> Here I'd politely tend to disagree with Faramir -- you are able to
> save the revocation statements wherever you wish -- it's your decision
> and not one that GPG or Enigmail automatically makes for you:
> 
>     a.  If the revocation certificate is created by the terminal mode
>         (command line) procedure, as atch 1 indicates you can provide
>         the file's title and where it is to be saved yourself.
> 
>     b.  If the revocation certificate is created via Enigmail when the
>         key itself is created, again as atch 4 indicates the title of
>         the file and where it is to be saved are decisions you control
>         yourself.
> 
>> ...the only time I imported a revocation certificate,...And it was 
>> very easy to import it (indeed, I didn't intend to do it)....
> 
> That to me is a very good reason not to keep your revocation
> certificates anywhere near your GPG keys or keyring if you're keeping
> revocation certificates on your computer.  You never wish to put
> yourself in the position that you've accidentally revoked a key if
> that can be avoided.
> 
> ====
> 
> *Personal Thoughts*:
> 
> a.  The common and recommended wisdom is that you should always create
>     a revocation certificate whenever you create a key.  The majority
>     of folks don't do that and then may at sometime in the future find
>     they would like to revoke the key but can't because they've either
>     lost the entire key, lost the secret (private) part of the
>     key pair, or have forgotten the passphrase associated with the
>     key.
> 
> b.  But if you do create a revocation certificate, you've got to keep
>     it someplace safe and so _I_ tend to do things a bit differently.
> 
>         (1)  I copy each of my keys (in each case the key pair) onto
>              two CDs and store that along with each key's passphrase
>              and a printed copy of each secret key:
> 
>                  (a)  First in a sealed envelope in what I consider
>                       a very secure location in my home.
> 
>                  (b)  Second in a sealed envelope in my bank safety
>                       deposit box.
> 
>         (2)  With that data I'm positive that I'm able to revoke any
>              of my keys as and when desired and thus don't need
>              revocation certificates.  If I were to create such
>              certificates I'd store them in the same two places noted
>              above.  But because I don't have them, unlike Faramir I
>              can't easily accidentally import or upload them.
> 
>         (3)  The two things you must have to maintain control over any
>              of your keys is first the passphrase for the key and
>              second the secret (private) part of the key pair.
> 
>                  (a)  I've securely stored the passphrase in
>                       written form.
> 
>                  (b)  I've securely stored the secret (private)
>                       and public parts of each key pair on a CD.
> 
>                  (c)  If for some reason neither CD will yield
>                       the secret key, I can -- with great care
>                       and effort, if I have to -- use the
>                       printed copy of the secret key to recreate
>                       it in my computer.
> 
>                  (d)  Since I try to keep each of my keys current
>                       and updated on both Biglumber and on the
>                       public keyservers, I don't need to worry
>                       about having access to the public portion
>                       of each of my keys -- however, if it was
>                       absolutely necessary, I could create the
>                       public part of my key pair by extracting
>                       it from the secret (private) part.  Note,
>                       you can't reverse the procedure and use
>                       the public part to create the secret (or
>                       private) part of the key pair.
> 
> ====
> 
> *Your four GPG/PGP Keys*:
> 
>>> ...to export both the public and secret part of all my 4 keys....
> 
> *If and when you're willing share them*, I'd like to obtain copies of
> your three other public keys (I've obviously got your 8E758D5F).  If
> they are posted on the public keyservers, I'd need just the three
> keyIDs, otherwise either a copy of each key or the URL where I could
> go to download them.
> 
> ====
> 
> *Question*:  Did the SMTP information I provided you yesterday help
>              resolve your problem or does it still exist?
> 
> If any of the above information is no clear or if you have any
> additional questions, please let me know.
> 
> 
> Best wishes for an enjoyable week.
> 
> 
> Timestamp: Mon 29 Sep 2008, 0252 Local (UTC -0400)
> 
> ====
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
This is another message of Kara's that's causing me nightmare last night
when I read through it. We shouldn't have words like "...Deputy
director" or "NS adviser" etc in an encrypted email!

Please no body send encrypted email anymore! I'll just practice
encryption with myself by writing to myself.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjn1vAACgkQE7PX/Y51jV8PBQCfWwBPo8uS+QDIzaKFS6TETOiT
poMAmQGZj2BSj3Sd85WJMGVQ4FYKloLE
=yMwA
-----END PGP SIGNATURE-----



More information about the Gnupg-users mailing list