Re: Automatically generating subkey revocation certificates

2019-12-27 Thread Dirk-Willem van Gulik



> On 27 Dec 2019, at 20:52, Werner Koch  wrote:
> 
> On Thu, 26 Dec 2019 23:04, Dirk-Willem van Gulik said:
> 
>> But this does not seem to happen when doing a --quick-add-key
>> subkey. Is this intentional ? Or is there a flag one can set ?
> 
> Right.  If you want to revoke a subkey we can assume that you still have
> access to the primary key and thus it is possible to create a specific
> revocation.  If you don't have access to the primary key anymore, a
> subkey revocation does not make sense because you can't create a new one
> - in that case revoke the entire keyblock using the prefabricated
> revocation.

Thanks - had not though of it in that fashion (in our use case - the governance 
is a bit less personal - and we want to be able to revoke a sub-key without 
much (additional) interaction -- so pre-generating them & leaving them domestic 
makes sense).


Dw
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Automatically generating subkey revocation certificates

2019-12-27 Thread Werner Koch via Gnupg-users
On Thu, 26 Dec 2019 23:04, Dirk-Willem van Gulik said:

> But this does not seem to happen when doing a --quick-add-key
> subkey. Is this intentional ? Or is there a flag one can set ?

Right.  If you want to revoke a subkey we can assume that you still have
access to the primary key and thus it is possible to create a specific
revocation.  If you don't have access to the primary key anymore, a
subkey revocation does not make sense because you can't create a new one
- in that case revoke the entire keyblock using the prefabricated
revocation.



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Automatically generating subkey revocation certificates

2019-12-26 Thread Dirk-Willem van Gulik
When you generate the main key (even with a programmatic 
--quick-key-generate) - it nicely puts revocation certificats in the 
revocs.d directory of GNUPGHOME.


But this does not seem to happen when doing a --quick-add-key subkey. Is 
this intentional ? Or is there a flag one can set ?


Dw


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Update FAQ about revocation certificates?

2018-11-12 Thread Daniel Kahn Gillmor
fwiw, i agree with Damien that the existing text in the FAQ about
generating a revocation certificate should be removed.

I think that there should be some text like "where can i find my key's
revocation certificate?" which could be added to the FAQ.

However, situations like these:

On Sat 2018-11-10 15:20:41 +, MFPA wrote:
> Not immediately after generating a new GnuPG certificate. But it
> probably still belongs under "some common best practices". A user
> might find they have deleted the auto-generated revocation
> certificate, or the disk where it is stored may have died. Or maybe a
> user is revoking a key and wants to generate a revocation certificate
> that gives a reason for the revocation.

Sound like corner cases to me, and they will clutter the FAQ.  The FAQ
is not designed to answer all possible situations (and certainly not
general file system management questions, etc).  It will be better
(clearer, simpler) if it is targeted on the truly frequently-asked
questions.  For the corner cases, there is the man page, and there is
DETAILS.gz, and there is the mailing list, and there is the source.

I salute Damien's effort to get the FAQ into a more maintainable and
accessible state.

   --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Update FAQ about revocation certificates?

2018-11-10 Thread MFPA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 8 November 2018 at 3:21:58 PM, in
,
Damien Goutte-Gattat via Gnupg-users wrote:-


> And with
> modern GnuPG there
> is no need to recommend to generate a revocation
> certificate.

Not immediately after generating a new GnuPG certificate. But it
probably still belongs under "some common best practices". A user
might find they have deleted the auto-generated revocation
certificate, or the disk where it is stored may have died. Or maybe a
user is revoking a key and wants to generate a revocation certificate
that gives a reason for the revocation.



- --
Best regards

MFPA  

Lack of money is no obstacle. Lack of an idea is an obstacle.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCW+b3WF8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+sFgAQDH3JRs8fA52oI8TLW1crr5xWbZYH+graflvhRFUHQUagD/flhODM/8g7QI
zjAJeGhfWUzBqQ7PTieAKJU6BgVdWgCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCW+b3WF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/xM2D/4kHmaiTlisAI7fPChpwX+WKe7H
z5CpATuVTwz7c7EFFjYj4kiUg05LrQ6+A6aQD7DA82A5ozYiFiofgHTcrh7R9S/L
P/ukgf9dkAPkhgXaeoUys6rsOrNv2gl4k5FMll0oCqfLlevxz6vDPdQXPDhGykD1
/IXE0egCNbLVQDEJo/umI0zByc98L/i6IWuhwiW42w6ZX05hPkN0VpzcdJVeoWYw
+2gfO/RUA5KTej926OhebCOA2446NoPDlS+G0emy8dbt1LJhLvhaV6ogNiRJ8Lzq
ZTylCf9DCIjHC+qy2UtBHTrEIYc+nSp7oy/jTAHUmndPcUlgEUWfMxqQcGKrViLA
ixRmJPkSKzDeodCYYZ2/eR4UNmRgsmgTBc3CrcnhQHZ7bImqj3/JjlNlw5x7RT7W
UVY4B8EqUmuClZszS2iyDx8b1rapOckjZZprCZ/3dWtYjLARoMZjpazmaZj+T032
QGHLCK+bcNIAjCufMdhUoV6siF7LSrY3VRPnX87l+1J/YyzwZZuPeG2iCaTEnYRf
FqXlOdgCpXZrfWTu6QBQ2dlQSyiiyYS20MfPsBk3Z1VSmg26KN/iIwUQ4HpNt+1H
Bj+9MoHJiEtY5ifD5UEYtkW/FeCsknSFsPg1SUfhfaXgpkoMgASWGtvKL5YLNL8c
oV2aN58Kij3TGylfHw==
=NIuj
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Update FAQ about revocation certificates?

2018-11-09 Thread Stefan Claas
On Fri, 09 Nov 2018 09:22:13 +0100, Werner Koch wrote:
> On Thu,  8 Nov 2018 18:34, stefan.cl...@posteo.de said:
> 
> > apartment and accidentally threw away the box
> > in which the revocation cert was stored... :-(  
> 
> :-(
> 
> > How would you procede now?  
> 
> Fetch your backup which for you will have stored at a different
> venue .-)

Thanks, i think i have now learned my lesson... ;-)

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas


pgpCIQlFIVG9L.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Update FAQ about revocation certificates?

2018-11-09 Thread Werner Koch
On Thu,  8 Nov 2018 18:34, stefan.cl...@posteo.de said:

> apartment and accidentally threw away the box
> in which the revocation cert was stored... :-(

:-(

> How would you procede now?

Fetch your backup which for you will have stored at a different
venue .-)

Call the locksmith to open the lock; sometimes locksmiths are not able
to do that and will use brute force to open the door.  Then you have to
install a new lock.

With a private key you need to do the same - unfortunately, or better,
fortunately, you also need to build an entire new house and not just a
new lock.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp5JkaU6DkCL.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Update FAQ about revocation certificates?

2018-11-08 Thread Stefan Claas
On Thu, 8 Nov 2018 15:21:58 +, Damien Goutte-Gattat via Gnupg-users
wrote:
> Hi GnuPG folks,
> 
> The current version of the FAQ recommends creating a revocation
> certificate at several places.
> 
> 
> § 7.17
> 
>   "We recommend you create a revocation certificate immediately
>after generating a new GnuPG certificate."
> 
> 
> § 8.5
> 
>   "What should I do after making my certificate?
>Generate a revocation certificate"
> 
> 
> § 10
> 
>   "What are some common best practices?
>[...] Generate a revocation certificate"

O.k. i have an example, which happened a while
ago to me... [stupid me]

I forgot the passphrase of my key but had a revocation
certificate stored in a save place. I renovated my
apartment and accidentally threw away the box
in which the revocation cert was stored... :-(

How would you procede now?

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas


pgpFFUnlAbfMc.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Update FAQ about revocation certificates?

2018-11-08 Thread Damien Goutte-Gattat via Gnupg-users
Hi GnuPG folks,

The current version of the FAQ recommends creating a revocation
certificate at several places.


§ 7.17

  "We recommend you create a revocation certificate immediately
   after generating a new GnuPG certificate."


§ 8.5

  "What should I do after making my certificate?
   Generate a revocation certificate"


§ 10

  "What are some common best practices?
   [...] Generate a revocation certificate"


However, since GnuPG 2.1 a revocation certificate is now
automatically generated by GnuPG at the same time a new key pair
is created, and stored in $GNUPGHOME/openpgp-revocs.d.

Therefore the above recommendations should either be removed or at
the very least amended to explain that they are only necessary
with GnuPG < 2.1.

FWIW, I believe they should be removed completely. Rationale: It
has already been decided three years ago not to mention GnuPG 1.4
in the FAQ [1]. Since then, GnuPG 2.0 has been end-of-lifed and so
in my opinion should not be mentioned either.  Thus the FAQ should
only focus on "modern" GnuPG (>= 2.1). And with modern GnuPG there
is no need to recommend to generate a revocation certificate.

On the same topic, the answer to the question "How do I generate a
revocation certificate?" (§ 8.5) should be amended to explain that
such a revocation certificate may already have been generated.
("May", because it is possible the user asking this question has
generated his or her key a long time ago, using an older version
of GnuPG.)

Comments are welcome.

Cheers,

Damien


[1] https://lists.gnupg.org/pipermail/gnupg-users/2015-August/054172.html


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-24 Thread Heinz Diehl
On 24.01.2014, Leo Gaspard wrote: 

 Actually, this is something I never understood. Why should people create a
 revocation certificate and store it in a safe place, instead of backing up the
 main key?

Because a backup only makes sense when it's stored in a diffrent place
than the key itself: With every backup you create, you have one place more 
you'll have to
keep secure, and doubled the chance that your key can be accessed.





___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-24 Thread Leo Gaspard
On Thu, Jan 23, 2014 at 04:38:19PM -0800, Robert J. Hansen wrote:
 Well... I don't know how you type
 
 With a nine-volt battery, a paperclip, and a USB cable that has only one end
 -- the other is bare wires.  You wouldn't believe how difficult it is to do
 the initial handshake, but once you've got it down you can easily tap out
 oh, three or four words a minute.  For speed, nothing else comes close.
 
 My father gets on my case for using the nine-volt battery.  In his day, they
 had a potato and a couple of wire leads plunged into it.  But really,
 technology marches on and we should all embrace battery technology.

Great laugh!

(of course, I meant how fast)

 passphrase would really have to try hard to guess what passphrase I am using.
 And even more to remember a seven-word sentence seen once.
 
 You are not the typical use case.  No one person is a typical use case.

Well... You are right, of course. Yet this does not answer my second point: if
the spouse is spying on you to get your passphrase and remember it, then love is
already gone, and you are being subject to the usual hooker attack.

Yet I do see your point for revocation certificates here, I think.

Oh, just found another one in favor of revocation certificates: they can be
easily sent to keyservers from cybercafes without any special software
installed.

Thanks and cheers,

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates

2014-01-24 Thread Leo Gaspard
On Fri, Jan 24, 2014 at 07:47:15AM +0100, Werner Koch wrote:
 [...]
 
  the usefulness of revocation certificate, just the advice always popping 
  out to
  generate a revocation certificate in any case, without thinking of whether 
  it
  would be useful.
 
 Okay, that is a different thing.  I plan to change that with a notice
 saying which file has the edited revocation certificate.

OK, thanks! (for the remainder of the message as well, just have nothing to
answer)

Guess I got my answer, with every message combined.

Thanks all!

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Leo Gaspard
On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote:
 Hi Uwe,
 
 Johannes Zarl:
  So in short:
   - a delay won't help you
   - protect your private key so this won't happen
   - always use a strong passphrase
 and in addition: if you fear (or know) that your secret key was copied
 from your system, revoke it!
 To me, this is a very important feature of OpenPGP: _you_ can actually
 do something to reduce (not more, but also not less!) harm for yourself
 and others.
 And, you can be prepared for such an event (i.e. having created the
 revocation certificates in advance, stored them in a save but accessible
 place, printed out on paper,...).

Actually, this is something I never understood. Why should people create a
revocation certificate and store it in a safe place, instead of backing up the
main key?

So long as the primary key is encrypted and the passphrase is strong, this
should not lead to any security danger. (Anyway, it's stored in a safe place.
And a revocation certificate misused is dangerous too, as it ruins a web of
trust.)

And the advantages of doing so are that in case or accidental erasing of the
private key (who never accidentally deleted an important file?), it also allows
the main key to be retrieved.

The primary key allows one to create a revocation certificate, not the other way
around. So, why store a safe revocation certificate?

Leo

PS: Please, do not tell me one might have forgotten his passphrase. In this case
there is no harm in shredding the secret key and waiting for the expiration
date, answering persons emailing you encrypted files that you lost your
passphrase. Anyway, in this case, you're screwed, and a revocation certificate
would be no better -- unless it was stored unencrypted, at the risk of having it
used when you do not want it to be.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Pete Stephenson
On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard ekl...@gmail.com wrote:
 On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote:
 And, you can be prepared for such an event (i.e. having created the
 revocation certificates in advance, stored them in a save but accessible
 place, printed out on paper,...).

 Actually, this is something I never understood. Why should people create a
 revocation certificate and store it in a safe place, instead of backing up the
 main key?

It's a sensible thing to do both, of course.

 So long as the primary key is encrypted and the passphrase is strong, this
 should not lead to any security danger. (Anyway, it's stored in a safe 
 place.
 And a revocation certificate misused is dangerous too, as it ruins a web of
 trust.)

 And the advantages of doing so are that in case or accidental erasing of the
 private key (who never accidentally deleted an important file?), it also 
 allows
 the main key to be retrieved.

 The primary key allows one to create a revocation certificate, not the other 
 way
 around. So, why store a safe revocation certificate?

The most damage that a misused revocation certificate can do is
revoking one's certificate. This is a bit of a pain, in that one would
need to create a new keypair, get it signed, etc., but it wouldn't
result in the compromise of sensitive information, messages, etc.
Misuse of a revocation certificate is a minor denial-of-service, but
not a complete break of security.

For example, one could easily give a trusted friend or family member a
copy of a revocation certificate (perhaps printed on paper) to keep in
a physically distant location. They would need to be trustworthy
enough to not abuse the revocation certificate by revoking your
certificate, but otherwise would not need to be given absolute trust
that comes with having a copy of the private key. Same thing with
keeping revocation certificates in a bank safe deposit box or some
other location protected by a third-party -- if the box were
compromised (say by the authorities with a court order), your private
key would not be compromised.

 Leo

 PS: Please, do not tell me one might have forgotten his passphrase. In this 
 case
 there is no harm in shredding the secret key and waiting for the expiration
 date, answering persons emailing you encrypted files that you lost your
 passphrase. Anyway, in this case, you're screwed, and a revocation certificate
 would be no better -- unless it was stored unencrypted, at the risk of having 
 it
 used when you do not want it to be.

Actually, that's a fairly reasonable scenario. Someone may have
forgotten their passphrase for whatever reason (ranging from
forgetfulness to head trauma) and would like to inform others that
their key is no longer usable. Replying to people saying that their
key is lost is essentially indistinguishable from a man-in-the-middle
attack -- some people might simply resend the encrypted message in
plaintext, defeating the purpose of encryption in the first place.

A revocation certificate allows one to revoke the certificate even
without access to the private key, so one could reply with their
now-revoked public key (or direct someone to the revoked key on the
keyserver) and say Sorry, I lost the private key and had to revoke
it. -- while this doesn't resolve the issue of people resending
things in plaintext, it does permit someone to actually show that
their key is, in fact, revoked.

Also, not all keys have expiration dates. I, for one, tend not to set
expiration dates on my primary keys, but instead rotate encryption and
signing subkeys (which do have expiration dates) for day-to-day use.
While I could put an expiration date on the primary and extend the
date as needed, it's easier for me to just make revocation
certificates and keep them stored off-site.

Your mileage may vary, of course.

Cheers!
-Pete

-- 
Pete Stephenson

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Robert J. Hansen

Actually, this is something I never understood. Why should people create a
revocation certificate and store it in a safe place, instead of  
backing up the main key?


A safe place for a revocation certificate may be vastly different  
from a safe place for a backup of your certificate.  For instance,  
if you're married you may be completely comfortable storing a  
revocation certificate in a locked desk drawer to which your spouse  
also has a key, but you may not wish to leave a backup of your  
certificate there.  In the event of divorce proceedings the worst your  
now-aggrieved spouse can do is revoke your certificate; your spouse  
won't have access to your private key as well.


And yes, a strong passphrase is still the strongest bar against these  
backups being misused -- but unless you've got an eye-poppingly strong  
passphrase, your best bet is to rely on denying attackers access to  
the data as well as the passphrase.


(I've often told people I'd be happy to post my private key to this  
mailing list in order to prove my claim that with a strong passphrase  
you have nothing to fear -- I never said I wouldn't grab 32 bytes from  
/dev/random, base64 encode them, and use that as a passphrase.  That  
counts as eye-poppingly strong, I think...)



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates

2014-01-23 Thread Werner Koch
On Thu, 23 Jan 2014 21:25, ekl...@gmail.com said:

 PS: Please, do not tell me one might have forgotten his passphrase. In this 
 case
 there is no harm in shredding the secret key and waiting for the expiration

Experience has shown that this is the most common reason why there are
so many secret keys on the servers which are useless.  Further, an
expiration data is not set by default and waiting a year until the key
expired is not a good option.

Further, it is also common that a secret key is lost (disk crash - no
backup, backup not readable or too old) or simply stolen.  This has the
same effect as a forgotten passphrase.  In particular in the stolen key
case, you want to immediately revoke it and not wait until you can
restore the key from a backup stored at some safe place.

There are other rare scenarios, for example a high security key in a far
away place, you are traveling and you want to immediately revoke the key
for whatever reason.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Leo Gaspard
On Thu, Jan 23, 2014 at 09:59:30PM +0100, Pete Stephenson wrote:
 [...]
 
 They would need to be trustworthy
 enough to not abuse the revocation certificate by revoking your
 certificate, but otherwise would not need to be given absolute trust
 that comes with having a copy of the private key. Same thing with
 keeping revocation certificates in a bank safe deposit box or some
 other location protected by a third-party -- if the box were
 compromised (say by the authorities with a court order), your private
 key would not be compromised.

Well, why not give them a copy of the encrypted key? So long as your passphrase
is strong enough (e.g. diceware for 128-bit passphrase), it should not require
to have absolute trust in the backup holder.

And if you want to account for risks of mental injury serious enough to make you
forget your passphrase, well... our threat models are not the same: in mine, my
key will expire soon enough in this case, and noone will ever be able to
compromise my secret key as noone on earth remembers the cryptographically
strong passphrase.

  PS: Please, do not tell me one might have forgotten his passphrase. In this 
  case
  there is no harm in shredding the secret key and waiting for the expiration
  date, answering persons emailing you encrypted files that you lost your
  passphrase. Anyway, in this case, you're screwed, and a revocation 
  certificate
  would be no better -- unless it was stored unencrypted, at the risk of 
  having it
  used when you do not want it to be.
 
 Actually, that's a fairly reasonable scenario. Someone may have
 forgotten their passphrase for whatever reason (ranging from
 forgetfulness to head trauma) and would like to inform others that
 their key is no longer usable. Replying to people saying that their
 key is lost is essentially indistinguishable from a man-in-the-middle
 attack -- some people might simply resend the encrypted message in
 plaintext, defeating the purpose of encryption in the first place.

As you put it, this is essentially indistinguishable from a man-in-the-middle
attack, so anyone who resend the encrypted message unencrypted is not respecting
the protocol (or believe it is not important enough to be encrypted -- let's
remember a lot of people just send christmas cards without envelopes).

If anything important has to be transmitted (and the sender refuses to send it
in cleartext), the sender will most likely send the message to someone else with
physical contact with the recipient.

One might argue this protocol is non-perfect, yet it is the best one the sender
could achieve, revocation certificate or not.

 A revocation certificate allows one to revoke the certificate even
 without access to the private key, so one could reply with their
 now-revoked public key (or direct someone to the revoked key on the
 keyserver) and say Sorry, I lost the private key and had to revoke
 it. -- while this doesn't resolve the issue of people resending
 things in plaintext, it does permit someone to actually show that
 their key is, in fact, revoked.

Indeed. Yet absence of answer should be clear enough to let the sender
understand his message did not come to the recipient. Sure, a MitM could block
the outgoing message, but anyway the sender has no better option than to find
another way of sending his message: the recipient clearly does not receive the
message.

In case the fact of knowing a key has been revoked is critical in time, well...
Knowledge of head traumas tend to expand quickly enough into the circles of
acquaintances. (Sure, forgetfulness is a risk. Yet, forgetting a passphrase you
type so often must be quite hard past the first few weeks.)

And, what's more, such a time-critical scenarios happen only with special needs,
which are AFAICT not usual.

 Also, not all keys have expiration dates. I, for one, tend not to set
 expiration dates on my primary keys, but instead rotate encryption and
 signing subkeys (which do have expiration dates) for day-to-day use.
 While I could put an expiration date on the primary and extend the
 date as needed, it's easier for me to just make revocation
 certificates and keep them stored off-site.

Well, you lose the dead-man-switch. BTW, once your key is revoked, will it some
day be cleared out of the keyservers, or will it stay there forever?
AFAIC guess, keys with an expiration date must be purged a little while after
they expired, as there is no point in keeping them, while revoked keys must be
kept, as anyone might need to update them to retrieve the revocation
certificate.

Of course, I'm only discussing the case of normal people. There must be plenty
of cases for which a revocation certificate is really useful, yet the number of
tutorials in which I read Store a backup of your private key and a revocation
certificate just looks like nonsense to me: if one stores both, it should at
least be precised it should be in two different locations, as storing the two
together is completely pointless, one

Re: Revocation certificates

2014-01-23 Thread Leo Gaspard
On Thu, Jan 23, 2014 at 10:26:33PM +0100, Werner Koch wrote:
 On Thu, 23 Jan 2014 21:25, ekl...@gmail.com said:
 
  PS: Please, do not tell me one might have forgotten his passphrase. In this 
  case
  there is no harm in shredding the secret key and waiting for the expiration
 
 Experience has shown that this is the most common reason why there are
 so many secret keys on the servers which are useless.  Further, an
 expiration data is not set by default and waiting a year until the key
 expired is not a good option.

Oh? I thought the most common reason was test keys, and tutorials which explain
step-by-step how to make a keypair and push it on a keyserver, without telling
to put an expiration date. I, unfortunately, have myself put a few test keys on
the keyservers (whose passphrase I no longer have) without expiration date
before knowing they would never (?) be deleted, and am still remorseful about
it.

And keys with an expiration date are someday deleted, while keys, even revoked,
without are never, are they?

BTW, revocation certificates are not produced by default either. So, why not
advise people to put an expiration date, instead of counselling them to generate
a revocation certificate?

 Further, it is also common that a secret key is lost (disk crash - no
 backup, backup not readable or too old) or simply stolen.  This has the
 same effect as a forgotten passphrase.  In particular in the stolen key
 case, you want to immediately revoke it and not wait until you can
 restore the key from a backup stored at some safe place.

Well, my question is then: Why not restore the key immediately (having stored it
at the place you would have stored the revocation certificate), and revoke it
then?

 There are other rare scenarios, for example a high security key in a far
 away place, you are traveling and you want to immediately revoke the key
 for whatever reason.

These corner-case scenarios are ones I did not mean to discuss, sorry for not
having made them clear.

I'm also feeling I may have failed to make myself understood: I am not denying
the usefulness of revocation certificate, just the advice always popping out to
generate a revocation certificate in any case, without thinking of whether it
would be useful.

Cheers !

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Leo Gaspard
On Thu, Jan 23, 2014 at 01:27:58PM -0800, Robert J. Hansen wrote:
 [...]
 
 And yes, a strong passphrase is still the strongest bar against these
 backups being misused -- but unless you've got an eye-poppingly strong
 passphrase, your best bet is to rely on denying attackers access to the data
 as well as the passphrase.
 
 [...]

Well... Diceware generates 128-bit passphrases of ten words, which is not *that*
much. Yet is can be regarded as far too much. Well... seven-word passphrase
provides 90-bit of security, and should not be so hard to remember. And
bruteforcing it should be quite long...

Sure, you would need to use really good random number generator, yet you could
use /dev/random just as well as you would have for your randomly-generated
passphrase.

Yet, I agree I would not send my encrypted private key. But having your divorced
spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an
unreasonable threat to me. And AFAICT even well-funded-organizations are not yet
powerful enough to bruteforce a 90-bit passphrase with enough s2k iterations.

Cheers,

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Robert J. Hansen
Yet, I agree I would not send my encrypted private key. But having  
your divorced

spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an
unreasonable threat to me.


It is.  That's why that's not the threat being defended against.

The threat is against your spouse seeing you enter your passphrase.   
It's very easy for roommates to discover each other's passwords and  
passphrases; sometimes it happens by accident.  Everyone knows not to  
enter a passphrase with a shoulder surfer around, but if you and your  
spouse are sitting on the couch with your laptops open and you receive  
an encrypted email, are you really going to tell her, Sorry, honey, I  
have to take this into the other room so I can enter my passphrase  
without worrying about you spotting it?


So long as there's marital bliss, you're perfectly safe.  You just  
can't rely on that lasting forever.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Leo Gaspard
On Thu, Jan 23, 2014 at 03:08:40PM -0800, Robert J. Hansen wrote:
 Yet, I agree I would not send my encrypted private key. But having your
 divorced
 spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an
 unreasonable threat to me.
 
 It is.  That's why that's not the threat being defended against.
 
 The threat is against your spouse seeing you enter your passphrase.  It's
 very easy for roommates to discover each other's passwords and passphrases;
 sometimes it happens by accident.  Everyone knows not to enter a passphrase
 with a shoulder surfer around, but if you and your spouse are sitting on the
 couch with your laptops open and you receive an encrypted email, are you
 really going to tell her, Sorry, honey, I have to take this into the other
 room so I can enter my passphrase without worrying about you spotting it?
 
 So long as there's marital bliss, you're perfectly safe.  You just can't
 rely on that lasting forever.

Well... I don't know how you type, but someone looking at me who sees me type my
passphrase would really have to try hard to guess what passphrase I am using.
And even more to remember a seven-word sentence seen once.

BTW, I once had a fun experiment: just type an eight random chars password with
no protection at all, and asking people behind me to remember it. The password
was displayed as I typed it, and left approx. two seconds more. No one managed
to see it and remember it. A few days later, I conducted the same experiment
with the same people and the same password, and no password was successfully
guessed. Sure, the information gathered would be enough to bootstrap a
successful bruteforce, but the experiment was a lot more easy to complete than
peeping at and remembering a seven-word password.

So, if the spouse is doing it, then marital bliss has already come to an end,
and one should have noticed it.

Yet, being unmarried, I cannot say anything about such things.

So, within that threat model, revocation certificates are useful for sure.
Assuming one's spouse would first grab the secret key and remember the
passphrase before divorce.

Thanks for making that point!

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates [was: time delay unlock private key.]

2014-01-23 Thread Robert J. Hansen

Well... I don't know how you type


With a nine-volt battery, a paperclip, and a USB cable that has only  
one end -- the other is bare wires.  You wouldn't believe how  
difficult it is to do the initial handshake, but once you've got it  
down you can easily tap out oh, three or four words a minute.  For  
speed, nothing else comes close.


My father gets on my case for using the nine-volt battery.  In his  
day, they had a potato and a couple of wire leads plunged into it.   
But really, technology marches on and we should all embrace battery  
technology.



passphrase would really have to try hard to guess what passphrase I am using.
And even more to remember a seven-word sentence seen once.


You are not the typical use case.  No one person is a typical use case.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates

2014-01-23 Thread Werner Koch
On Thu, 23 Jan 2014 23:15, ekl...@gmail.com said:

 Oh? I thought the most common reason was test keys, and tutorials which 
 explain
 step-by-step how to make a keypair and push it on a keyserver, without telling

Obviously, I don't have no hard evidence for the claim that forgotten
passpharses are a reason for many unusable keys.  However, I have heard
too many times statements like “Please don't encrypt to that key; I -
uhmm - can't remember my passphrase”.

 And keys with an expiration date are someday deleted, while keys, even 
 revoked,
 without are never, are they?

No they are not deleted.  They are still useful for signature
verification.  Think about gnupg 1.0.0 which has been signed by a long
expired key of mine - verifying it still gives some evidence that the
tarball is genuine.  The key merely expired.  If I had reasons to assume
that the key is compromised I would issue a revocation.  Verification
tools show that.

 BTW, revocation certificates are not produced by default either. So, why not
 advise people to put an expiration date, instead of counselling them

The reason why they are not generated by default is that I am sure that
many people would accidentally publish the revocation.  That is not
optimal and thus my current plan is to create a revocation be default
but modify the armored file so that it can only be imported after
editing the file.

 Well, my question is then: Why not restore the key immediately (having stored 
 it
 at the place you would have stored the revocation certificate), and revoke it
 then?

The key is of course stored at a bank safe.  The sheet/cdrom with the
revocation is in the drawer of my desk.

 the usefulness of revocation certificate, just the advice always popping out 
 to
 generate a revocation certificate in any case, without thinking of whether it
 would be useful.

Okay, that is a different thing.  I plan to change that with a notice
saying which file has the edited revocation certificate.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation certificates

2010-01-28 Thread Robert J. Hansen
On 01/28/2010 10:44 PM, Richard Geddes wrote:
 Generating a revocation certificate as soon as you generate your key
 pair is a wise thing to do, in case you lose control of your passphrase
 ... I did that.

Good!  :)

 My question is, if I edit my key pair... let's say I add a new uid to my
 key pair... do I need to generate a new revocation certificate or will
 the original revocation certificate work on the modified key pair?

The original revocation certificate will work on the modified key pair.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-07 Thread John Clizbe
David Shaw wrote:
 But you seem to be missing the point.  Uuencode (or GPG armor) creates  
 lines that are very difficult to type in.  There are no spaces, and  
 the character set includes uppercase, lowercase, numbers, and  
 symbols.  There is no CRC to help you type it back in again, so if  
 there is an error, you must proofread the whole file.  Plus, as you  
 say, it's around 100 lines long.

And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs 'l';
and '8' vs 'B'.

I'll take 0-9A-F any day.

-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
 mailto:[EMAIL PROTECTED]

Q:Just how do the residents of Haiku, Hawai'i hold conversations?
A:An odd melody / island voices on the winds / surplus of vowels



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-07 Thread John Clizbe
Faramir wrote:
 John Clizbe escribió:
 
 And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs 'l';
 and '8' vs 'B'.
 
   But I suppose you can copy/paste it into a text editor, and chose a
 font clearer to read... or I am wrong?

Could you explain how you are going to copy-and-paste from a paper copy?
Yes, you can use a scanner and OCR, but you're still left with the task of
proofreading the entire document.

 I'll take 0-9A-F any day.

   What is that?

The values used in Hexadecimal: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F.

The numerals 0 to 9 followed by the letters A to F


-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
 mailto:[EMAIL PROTECTED]

Q:Just how do the residents of Haiku, Hawai'i hold conversations?
A:An odd melody / island voices on the winds / surplus of vowels



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-07 Thread Faramir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John Clizbe escribió:
 Faramir wrote:
 John Clizbe escribió:

 And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs 
 'l';
 and '8' vs 'B'.
   But I suppose you can copy/paste it into a text editor, and chose a
 font clearer to read... or I am wrong?
 
 Could you explain how you are going to copy-and-paste from a paper copy?

  Well, if it was already printed You will pay the price for your lack
of vision. as Palpatine would say. (I am joking). But if I understood
it right, paperkey generates a txt output file (ascii 7 bits). You can
copy and paste that output, chose a clear font, and print it...

 Yes, you can use a scanner and OCR, but you're still left with the task of
 proofreading the entire document.

  I don't even dare to think the effort that would require, since the
few OCR software I have used, made use of dictionaries to avoid making
too many errors... and still they made a lot of them. Without the aid of
dictionaries... it's scary XD

 I'll take 0-9A-F any day.
 
   What is that?
 
 The values used in Hexadecimal: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, 
 F.
 
 The numerals 0 to 9 followed by the letters A to F

  Oh.. right, I will remember that... I have not been exposed to
hexadecimal... yet (I suppose I will learn a lot about that in the
network curse...).

  Best Regards

P.S: tomorrow I will try paperkey... may the Force be with me ;)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBCAAGBQJI6xg/AAoJEMV4f6PvczxABRwH/1MOxV5nQ3JNoOijm3VTjUdR
7WJwyAWLl7R+eB8IIRG18TUmCoyVhwROYMfaai2ACKUdR6ZiaQozjcdDevIbYQtk
3Zu+TOSTMpxDeAlwfmjH1ghGP4qcFDUp/Zal4RFhQbC5hjHhpUmHgYXNh6/SmxTM
87qci23UH/AqZzXdgLkQSNtEssIQv3KtoNmLoYZ1sLzZC6r0bF9FRhJFPnQMwjoW
MD5LWib6ZlhUB+SmmeYRKZ1iRyo9VrkBDI8fRpNG2+kpN5//wldSF5vzCNC8Bo2C
NRzZ0Km8VbN5vjLW5xkMqj6Tuz+na84BMshCEmPTfyQPB5fNhQ3Js/ivgYjsmX8=
=fu+d
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-07 Thread Faramir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John Clizbe escribió:

 And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs 'l';
 and '8' vs 'B'.

  But I suppose you can copy/paste it into a text editor, and chose a
font clearer to read... or I am wrong?


 I'll take 0-9A-F any day.
  What is that?

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

iQEcBAEBCAAGBQJI6wzrAAoJEMV4f6PvczxAI6kH/0+TS7yo6FDqPRUEt4850Lwg
aUCfmBqOjrgUtB0tImfhK40TOVaU/uoLO78wcSjRWabhmqcLdKJgAI+KFRu3v8ZB
cQtkW5zZL5PxU2pfwJTuLv6S7feA0CVO6cahIgsdrmWxie2YxTRyBwbWFt0PeORq
YfBsbWRPYGb8ZVM434coO6iAmy7o4gA/uSahq+O1v5uLje9LzzBMIYVOF7ogKvPK
KJZPSM5jg+++rIotQNmBxqc0XDOVvdQwLS4VRRJsBeLWDs89hVB6WpgfebdJ8/IL
vq/LituNg3qq4cnp80pFbZVbZ/MK3/U4oQmEpGPPYAMXlPxs0OiI5L2iNTxDMF8=
=zzuj
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-06 Thread Sven Radde
Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:
 A revocation certificate, on the other hand, doesn't  
 have all that much that can be removed.  Luckily revocation  
 certificates are pretty short to begin with.  The only real advantage  
 that paperkey could bring to revocation certificates is the per-line  
 CRC, which makes retyping easier.

Yes, that's the point.
While I agree with Robert and you that revocation certs are smaller and
therefore easier to OCR than keys, they would be *even easier* to OCR if
they were encoded in Base16 and had per-line checksums.

ASCII armor has a few characters which are somewhat hard to tell apart 
(orimarily 0s and Os - note to myself: find a better font) and if such 
'entropy' can be avoided this increases reliability of the import.

cu, Sven


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-06 Thread David Shaw
On Mon, Oct 06, 2008 at 08:03:12AM +0200, Sven Radde wrote:
 Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:
  A revocation certificate, on the other hand, doesn't  
  have all that much that can be removed.  Luckily revocation  
  certificates are pretty short to begin with.  The only real advantage  
  that paperkey could bring to revocation certificates is the per-line  
  CRC, which makes retyping easier.
 
 Yes, that's the point.
 While I agree with Robert and you that revocation certs are smaller and
 therefore easier to OCR than keys, they would be *even easier* to OCR if
 they were encoded in Base16 and had per-line checksums.
 
 ASCII armor has a few characters which are somewhat hard to tell
 apart (orimarily 0s and Os - note to myself: find a better font) and
 if such 'entropy' can be avoided this increases reliability of the
 import.

Good point.  I'll consider that, but in the meantime, note that you
can do something like this:

  gpg --gen-revoke (thekey) | gpg --dearmor | od -tx1

David

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-06 Thread Morton D. Trace
David Shaw wrote:
 On Mon, Oct 06, 2008 at 08:03:12AM +0200, Sven Radde wrote:
 Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:
 A revocation certificate, on the other hand, doesn't  
 have all that much that can be removed.  Luckily revocation  
 certificates are pretty short to begin with.  The only real advantage  
 that paperkey could bring to revocation certificates is the per-line  
 CRC, which makes retyping easier.
 Yes, that's the point.


NAME
 uuencode, uudecode - encode a binary  file,  or  decode  its
 encoded representation

SYNOPSIS
 uuencode [source-file] decode_pathname

 uuencode [-m] [source-file] decode_pathname

 uudecode [-p] [encoded-file]

 uudecode [-o outfile] [encoded-file]


uuencode  -m  .gnupg/secring.gpg   ./

Does the trick for me.

Less than 100 lines and good paper printable.

Sincerely yours,

Morten





___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-06 Thread David Shaw

On Oct 6, 2008, at 3:25 PM, Morton D. Trace wrote:


David Shaw wrote:

On Mon, Oct 06, 2008 at 08:03:12AM +0200, Sven Radde wrote:

Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:

A revocation certificate, on the other hand, doesn't
have all that much that can be removed.  Luckily revocation
certificates are pretty short to begin with.  The only real  
advantage
that paperkey could bring to revocation certificates is the per- 
line

CRC, which makes retyping easier.

Yes, that's the point.



NAME
uuencode, uudecode - encode a binary  file,  or  decode  its
encoded representation

SYNOPSIS
uuencode [source-file] decode_pathname

uuencode [-m] [source-file] decode_pathname

uudecode [-p] [encoded-file]

uudecode [-o outfile] [encoded-file]


uuencode  -m  .gnupg/secring.gpg   ./

Does the trick for me.

Less than 100 lines and good paper printable.


Why would you use uuencode, when GPG actually has that built in?

  gpg --armor --export-secret-keys

But you seem to be missing the point.  Uuencode (or GPG armor) creates  
lines that are very difficult to type in.  There are no spaces, and  
the character set includes uppercase, lowercase, numbers, and  
symbols.  There is no CRC to help you type it back in again, so if  
there is an error, you must proofread the whole file.  Plus, as you  
say, it's around 100 lines long.


The same key run through paperkey is only the letters A-F and numbers  
0-9.  There are per-line CRCs so if there is a problem, you know which  
line to examine.  And it's just 10 lines long.  A bit easier to  
handle, no?


David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-05 Thread Jorgen Christiansen Lysdal
Robert J. Hansen wrote:
 This deputy sheriff reported to his superior, and I wound up
 with a thirty-day delay in the paperwork while the county sheriff made
 sure that I didn't have murder afoot.  Were they overreacting?  Sure,a
 bit.  But they were also doing their job.

They could have been overreacting to cover their own asses. In case you
really wanted to hurt someone, they wanted to make sure it was not their
mistake that got a person killed. Forgetting about the fact that there
is a gazillion normal household items, that can harm a person.
If they really had a bad feeling about you that day, wouldn't they have
done something more than just delay paperwork?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-05 Thread John W. Moore III
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jorgen Christiansen Lysdal wrote:
 Robert J. Hansen wrote:
 This deputy sheriff reported to his superior, and I wound up
 with a thirty-day delay in the paperwork while the county sheriff made
 sure that I didn't have murder afoot.  Were they overreacting?  Sure,a
 bit.  But they were also doing their job.
 
 They could have been overreacting to cover their own asses.

In My experience the majority of folks seriously contemplating Homicide
rarely to to the effort to obtain a permit for the murder weapon.

JOHN ;)
Timestamp: Sunday 05 Oct 2008, 07:23  --400 (Eastern Daylight Time)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10-svn4845: (MingW32)
Comment: Public Key at:  http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: Homepage:  http://tinyurl.com/yzhbhx

iQEcBAEBCgAGBQJI6KPTAAoJEBCGy9eAtCsPGz8H/0dUZfbsDkww9juRYUc1nCUH
34y689iJVDx5t5x01wNKGDkfo9DW79LooHWoJtij31E5OlHmpYccA3x7fUdr8svI
ws3OUnomhXDdck3rgLkws9Y5gSkpueY9gJV8xeUJR5uaejcKR9dfOFQGSopJdrKF
aN9TxAMLzzvps0njBZYBrWMpU1pZvXNfSpybaTRxlYsJ6wsXtoBNWeV+zCEg5AVV
O/JusY1+4Mqu4n6iWS0BqEHa9t7fetPosjhMDHjQ9GdbISmXERJp2/Qlr/hUZVME
lBTk01A43n4iz6729A1AWWBLWUiSIFOXL9sa4+LSVwmOgrVOXisZsqnngUpXfNk=
=OKTR
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-05 Thread Sven Radde
Hi!

Although David's awesome little tool [1] reduces the chance of losing a
secret key, I am still a fan for pre-generated revocation certificates
in case a key is irrecoverably lost.

David, is there a chance that you will extend paperkey so that it
encodes and decodes revocation certificates? Adding a line-wise CRC to
those seems particularly sensible to me as they would be printed to
paper even more often than keys. I am unsure as to how much they could
be shortened, though.

And, btw, is there a significant difference between 0.7 that ships with
Ubuntu and 0.8 on jabberwocky.com?

cu, Sven

[1] For those that might not know:
http://www.jabberwocky.com/software/paperkey/


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-05 Thread Robert J. Hansen
On Sun, 2008-10-05 at 21:40 +0200, Sven Radde wrote:
 David, is there a chance that you will extend paperkey so that it
 encodes and decodes revocation certificates?

I'm not David (obviously), but I don't see the win here.

The problem with paper copies of private keys is they're big.  If
there's an error while OCRing them, it's going to be an ordeal to do an
optical diff between what was printed and what was OCRed.

Revocation certs are much smaller.  They're a few lines of text, nothing
more.  The optical diff is much easier.

Where's the need for this tool?  Where's the use case?




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-05 Thread David Shaw

On Oct 5, 2008, at 3:40 PM, Sven Radde wrote:

Although David's awesome little tool [1] reduces the chance of  
losing a

secret key, I am still a fan for pre-generated revocation certificates
in case a key is irrecoverably lost.

David, is there a chance that you will extend paperkey so that it
encodes and decodes revocation certificates? Adding a line-wise CRC to
those seems particularly sensible to me as they would be printed to
paper even more often than keys. I am unsure as to how much they could
be shortened, though.


Paperkey does its trick by removing everything unnecessary from the  
secret key, and printing that out in an easily retyped (or OCRed)  
format.  This works well for secret keys, as the secret bits are only  
around 10-15% of the size of the key (most secret keys can be  
represented in as few as 170 bytes, which can be easily retyped in a  
few minutes).  A revocation certificate, on the other hand, doesn't  
have all that much that can be removed.  Luckily revocation  
certificates are pretty short to begin with.  The only real advantage  
that paperkey could bring to revocation certificates is the per-line  
CRC, which makes retyping easier.


And, btw, is there a significant difference between 0.7 that ships  
with

Ubuntu and 0.8 on jabberwocky.com?


Noteworthy changes in version 0.8 (2008-02-01)
--

* The file format is now included as part of the base16 output, as
  there is no guarantee that this program will be on-hand when a
  reconstruction is necessary.  The format can also be displayed
  via the --file-format command.  Suggested by Brendan Kidwell.

* Some bug fixes (actually to gnulib, but relevant here as well)
  to the SHA-1 code on platforms that require aligned access.
  Thanks to Peter Palfrader.

* New --comment option to add comments to the base16 output.

No major difference - just some convenience stuff and a bug fix that  
probably doesn't apply to you (you'd know it if you were on one of the  
platforms that had the gnulib bug because paperkey wouldn't run at all).


David

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-05 Thread Faramir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David Shaw escribió:
...
 that much that can be removed.  Luckily revocation certificates are
 pretty short to begin with.  The only real advantage that paperkey could
 bring to revocation certificates is the per-line CRC, which makes
 retyping easier.

  Also, if the key is reconstructed (and provided the passphrase can be
found somewhere), it should be easy to revoke it...

 * The file format is now included as part of the base16 output, as
   there is no guarantee that this program will be on-hand when a
   reconstruction is necessary.  The format can also be displayed
   via the --file-format command.  Suggested by Brendan Kidwell.

  So... the key can be reconstructed without using paperkey? How could
it be done?

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

iQEcBAEBCAAGBQJI6VeXAAoJEMV4f6PvczxAurwH/icuc3MPFksEZA4qgXCZ3Xv1
8YYCu/yxRuEPFI6FfrBB0ns+ZhbZ8jiUU/rQhePWdKdKYf5t3Rq0KEUMoFv6b/wa
KEUvFMICnDU0Ier6z+S2Qk617obyh3rcI2r2qvwigmtXcFiBcwkZzC0P0sCt9GTS
leuuOnZEi2Y/uv0FlnnAEh799eAuZ/LTgKP4RXi1nxWb4NhiWoCiEiwX1Ky6c291
L4/Hpjy4qnbmUQQLQLLfyJ9GacPHTVQyvjtViuaHzei/QMETUS1HbUG6Y2R/NhZy
s/DlrhPvOZszt6q+cfxvmY+BPUGLiLd4edN9Z/9M2RiMkzId4mDcnJKssm7yvIU=
=whfb
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey for Revocation Certificates? (Feature-Request :-)

2008-10-05 Thread David Shaw

On Oct 5, 2008, at 8:11 PM, Faramir wrote:


   * The file format is now included as part of the base16 output, as
 there is no guarantee that this program will be on-hand when a
 reconstruction is necessary.  The format can also be displayed
 via the --file-format command.  Suggested by Brendan Kidwell.


 So... the key can be reconstructed without using paperkey? How could
it be done?


You could theoretically reconstruct the key using any reasonable  
editor that works on binary files.  Paperkey just does the work for  
you.  Brendan pointed out, rather reasonably, that after a key is  
archived on paper for a long time, there may not be a copy of paperkey  
handy to restore it.  Thus, paperkey prints out the file format (as a  
human-readable comment) before the actual secret key data.  It's just  
there in case someone needs it someday.


David

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread Lawrence Chin
 already created the key* (e.g., Dummy [EMAIL PROTECTED])
 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

Re: Revocation Certificates

2008-10-04 Thread John W. Moore III
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Lawrence Chin wrote:

 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!

Why?  Even if Reference to entities whose existence is public knowledge
were known to exist; the Message was Encrypted [until re-Posted here]
and therefore privy _only_ to You and the Sender.  :-\

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

Your choice, of course, but prior to Your entry to Encryption there have
been many profane, obscene  inflammatory comments made about DIRNSA,
the President of the U.S.  many others.  At present all of these Public
figures have much larger fish to fry than concerning themselves about
references made to or about them.  :-D

JOHN ;)
Timestamp: Saturday 04 Oct 2008, 18:26  --400 (Eastern Daylight Time)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10-svn4845: (MingW32)
Comment: Public Key at:  http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: Homepage:  http://tinyurl.com/yzhbhx

iQEcBAEBCgAGBQJI5+3YAAoJEBCGy9eAtCsPQJUH/2gD4wD/JUS6jRM1xKBV94qO
TUbNsKBq43rABwLtRKNmWecIDALHSQ8Z8qWdpqH7TVRTZSVpyIPTKDMb5F9Ad3nW
heEOyM8xg5NfgTmfOdc1aK+6jWQLLAfdajqh4Jh9N+9YdccAkSpprNFh7VmdoFqJ
YFkuykdki+xNSpdlxgYvj4d4HkETFdEA4EYsgUKYRhsEhcsRz1WuZzNqDsj+BAsO
dJ8vTKWOFIj6M28Af6qzrCsnROKZI0j8aeg6mU1k+Cw/RKZcNGcSi4HQDiQLN7xS
cDeU5W36kR8bmQQcs+hfGlaSgtFdCOnhLN0PU3Y58xIgASMsCBqSj+LeGbvM0Bw=
=TVag
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread Faramir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lawrence, if your nerves are so shaken, maybe you should stop reading
this message right now, and delete this message, or maybe keep it to
read it once you are better. I will put some blank lines as spoiler,
just in case. And please note, this message is legal, and can't result
in any harm to your reputation, or anything like that...

Begin of spoiler blank lines





























End of spoiler blank lines

  (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

   Come on, she was giving an example about comments in a key, and they
were about having a legal job... Is it so serious to think a member of
CIA could become an advisor of the president of USA?
   Also, please note that if the message was encrypted, it was not
possible for authorities to know these words were on the message... now
it was posted in a public list, they can know it. But again, these are
perfectly legal jobs, and to talk about them, or to mention them, is
perfectly legal too.

 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.

  I disagree, the current version allows you to create it, by accessing
the Key Manager, right click on the key, the contextual menu has the
option to do it.

 ...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

 Here I'd politely tend to disagree with Faramir -- you are able to

As a side note, I was just giving him a hint about possible places
to look for the rev cert he already had created... I was not suggesting
him to store it in that place.

  above.  But because I don't have them, unlike Faramir I
  can't easily accidentally import or upload them.

  Well, my mistake was to double click the rev cert, expecting to see
some output (something like: right rev cert for key ID...), but the GUI
interpreted it as the user wants me to import the certificate...
done!. But that taught me to be more careful...


 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!

  Why not? The message could not be read by any third party. And even if
it could, it was just a mention to these jobs... Take it easy...

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

  As you wish, but I still think you are overreacting a lot about those
things...

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

iQEcBAEBCAAGBQJI5/tdAAoJEMV4f6PvczxAJfIH/2enWJjxtIr6S8FxJNjCpTCJ
s6Pj3keJsRXNy91ABnFNz13Esac1im9CZ2hoiHPedoWFmlOodL2WR/TPqrUdUcv1
aInQnuowzhkvJ4+NfWvnpi8sAvWN1pufdBl8ft7WVuD5du/4Fi6J0sEAACcwTn4M
7B9dhCGB9UA9pbKivCv6GX9tYas/cNPvZv2Rb9j3wiUMBCpsLh6U4KTIdajyMzlp
k29xzkIy4IqCV04UlXsDZ5+TPWHuRbWxJ9Ad60MZWUi+QFKClOyffY3CAdK58P92
fsNAVSueJNBpBkg591raMJf7XuppHHzGL4qQ1keYlojaIdzXm56Kkkvyuufc+G8=
=jGkp
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread markus reichelt
* Faramir [EMAIL PROTECTED] wrote:

 Begin of spoiler blank lines
 [...]
 End of spoiler blank lines

niiice, I bet he didn't catch that one!

-- 
left blank, right bald


pgptXuX9KPvBR.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread Robert J. Hansen
Lawrence Chin wrote:
 So I'm very paranoid about, not just what I said to others, but
 precisely what others said to me.

If this is of so much concern to you, you should probably consider
leaving the various crypto mailing lists altogether.  Members of various
national intelligence communities are reading this list, the Enigmail
list, the PGP-Basics list, and others.  Not for any nefarious purpose,
mind you, but because they're privacy enthusiasts.

Remember: the NSA does both communications intelligence and
communications security.  This mailing list is right up the latter
group's alley.  They're great folks.

If you are that concerned about the intelligence and/or law-enforcement
communities seeing what you write, you should be very careful about your
involvement on this, or any of several other, mailing lists.




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread John W. Moore III
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Robert J. Hansen wrote:

 If you are that concerned about the intelligence and/or law-enforcement
 communities seeing what you write, you should be very careful about your
 involvement on this, or any of several other, mailing lists.

More precisely; You might be better served to abandon Email altogether
as a Communications medium.  You might inadvertently discuss cookware
and mistakenly become the focus of a bored CHP or DEA inquiry.  :-\

JOHN ;)
Timestamp: Saturday 04 Oct 2008, 23:40  --400 (Eastern Daylight Time)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10-svn4845: (MingW32)
Comment: Public Key at:  http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: Homepage:  http://tinyurl.com/yzhbhx

iQEcBAEBCgAGBQJI6DdHAAoJEBCGy9eAtCsP6VgH/jniB45uRzO5XxHbTgzu7Vav
xIDqC/8aK+VvcezRx1UQ47HnVg4ZC3N9ALhRxq5KnnYQUURi7EfuPgO/FH82CvvE
HzBQCsDcADvG8D4JbTnH+XgpAXl4Z3hkNTQxlSFINyq3ZnP3Xro6+nTN3HoPwdPw
DKwHSuXqefTpnNbreAPg7Ov2ux2AwFoUKioYD40vCO8GqvpuvOB5+qHj+Hq51B3s
DJcnvAON5MbPNfGYiXZqoCztB9bdLYftTq2sM9EIKp1KK7dPzTtahpDf3Pl40mHv
uCUhlKwsNuPhIxMdqKXI0yjrYnc3vLZaESLVrd5RlCpaIscXdT2RnJIdSVGmRTo=
=6VoN
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread Faramir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lawrence Chin escribió:

  I'm sorry to have failed to observed Netiquette, but I was just too
 afraid. I have been reported before to law enforcement as saying things

  You was reported? By somebody? The *proper* use of encryption should
prevent somebody from reading your messages, and signatures should
help to prove who said what was said... But since it is hard to prove if
gpg is being used properly (mainly, if it is being used in a clean
computer), maybe you should not take the risk. I suppose you can still
sign your messages, since any attempt to alter them would break the
signature.

 which in fact others said to me and got into trouble for that. Law
 enforcement would treat any words in my box as my product, but others

  Well, I don't know how things work in USA courts of justice, but I
suppose you can have a lawyer to defend you, and I suppose he can ask
the opinion of an expert... since you are using gmail, and it is very
likely you are not deleting the messages, it should be possible to prove
who said what...

 said it is no defense. So I'm very paranoid about, not just what I said

  Maybe it is not if you say that, but an expert should have more
chances to be believed. But again, I don't really know how justice works
there.

  With due respect to USA, each time I read things like this, I am happy
for not living there... my main concern here is if economy will be
affected or not for things happening outside my country. But at least I
know I can rely on justice to don't cause me problems for things I have
not done or said.

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

iQEcBAEBCAAGBQJI6D4XAAoJEMV4f6PvczxAZAsH/16s74iaZLgjzruCqjrCEwda
QLt21kLakyNZKD4u0CKPo5hgBz87nsp1WwS0E4wDvRYFimKVaRs2h7Layf2jv0PU
8dSmqbWXfJ+KILIWHxJ+mf/gNV3mX1C7HqOYHB8c+ecmP+ogWoo7anRb7VHLM00t
nnWpOCvOEnKIqxHfuxJxk9Bb2S/nt6mF9W/Xl2m3vM9hXGBNwBpC7rmVV6lTnUd4
s+kwoS/g1rmRsejlqZylg0VYFYNb0iOd5rDmPJ8ji1rejpcI2OK8MDj4axkfCR1D
f2AKtpGouRSbOo/h4Nv0s7U0HjEViFGXwiQlxVEmkz6vhxOaSSKSvzE8WIL49gw=
=kYb6
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Revocation Certificates

2008-10-04 Thread Robert J. Hansen
Faramir wrote:
   With due respect to USA, each time I read things like this, I am happy
 for not living there... my main concern here is if economy will be
 affected or not for things happening outside my country. But at least I
 know I can rely on justice to don't cause me problems for things I have
 not done or said.

At risk of continuing this thread more than it should be continued...

This is not a miscarriage of justice.  Even if everything Lawrence has
said is true.  Let's say that someone sends me a message in which they
threaten the life of the President of the United States.  I mention to
someone that I've received this, they tell someone else, and _bang_,
next thing I know I've got an appointment with some Secret Service
agents who want to ask me some very intrusive questions.

That's not a miscarriage of justice.  That's them doing their job.  It
would be a miscarriage of justice if I was indicted for a crime, much
less convicted -- but there's no miscarriage of justice in the police
seeing something which says hey, something may be afoot here, and
deciding to follow up on it.

In '98, I went down to the sheriff's office to renew my firearms permit.
 While filling out the form I was chatting with the woman behind the
desk, whom I've known for some years.  She asked me how my
then-girlfriend was doing, and I said that I'd recently proposed and
she'd said yes, and we were figuring out a wedding date.

This was a perfectly normal conversation of the sort that goes on every
single day.  However, some sharp-eared deputy sheriff heard me talk
about my fiancée and noticed I was standing in line for a firearms
permit.  This deputy sheriff reported to his superior, and I wound up
with a thirty-day delay in the paperwork while the county sheriff made
sure that I didn't have murder afoot.  Were they overreacting?  Sure, a
bit.  But they were also doing their job.

Remember that we've only heard Lawrence's side of things, and even then
we haven't heard much about it.  What does Lawrence mean by he got in
trouble?  Did an officer stop by his house and say hey, we heard
something about this, is there something I ought to know about?, or was
he actually put on trial?  The former is not objectionable; the police
are allowed to do their job.  The latter might very well be.

(Note: I am not asking to know the particulars.  I don't want to know
the particulars.  This entire thing is irrelevant.  But it really annoys
me to see people jump to such wild and unsupported conclusions based on
the flimsiest of evidence and the wildest of accusations.  It is one of
my biggest pet peeves.)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users