pgg doesn't recognise disabled keys!

pgg doesn't recognise disabled keys!

[clemens fischer]

pgg/gpg exposes the following behaviour:  when given a disabled key as
a recipient who has another enabled key, the following error is thrown
by mml:

[GNUPG:] USERID_HINT xxxxxxxxyyyyyyyy z
[GNUPG:] NEED_PASSPHRASE xxxxxxxxyyyyyyyy xxxxxxxxyyyyyyyy 17 0
[GNUPG:] GOOD_PASSPHRASE
gpg: user@host.domain: skipped: public key is disabled
[GNUPG:] INV_RECP 0 user@host.domain
gpg: [stdin]: sign+encrypt failed: unusable public key

clemens

Re: pgg doesn't recognise disabled keys!

[Simon Josefsson]

clemens fischer <ino-waiting@gmx.net> writes:

> pgg/gpg exposes the following behaviour:  when given a disabled key as
> a recipient who has another enabled key, the following error is thrown
> by mml:
>
> [GNUPG:] USERID_HINT xxxxxxxxyyyyyyyy z
> [GNUPG:] NEED_PASSPHRASE xxxxxxxxyyyyyyyy xxxxxxxxyyyyyyyy 17 0
> [GNUPG:] GOOD_PASSPHRASE
> gpg: user@host.domain: skipped: public key is disabled
> [GNUPG:] INV_RECP 0 user@host.domain
> gpg: [stdin]: sign+encrypt failed: unusable public key

How can this be improved?  If you give PGG/GPG a disabled key,
shouldn't it complain?

Re: pgg doesn't recognise disabled keys!

[Clemens Fischer]

(sorry for sending this to you personally as well, but i read ding on
gmane, so the list would bounce back to me.  please be kind enough to
forward to the list.)

Simon Josefsson <jas@extundo.com>:

> clemens fischer <ino-waiting@gmx.net> writes:
>
>> pgg/gpg exposes the following behaviour:  when given a disabled key as
>> a recipient who has another enabled key, the following error is thrown
>> by mml:
>>
>> [GNUPG:] USERID_HINT xxxxxxxxyyyyyyyy z
>> [GNUPG:] NEED_PASSPHRASE xxxxxxxxyyyyyyyy xxxxxxxxyyyyyyyy 17 0
>> [GNUPG:] GOOD_PASSPHRASE
>> gpg: user@host.domain: skipped: public key is disabled
>> [GNUPG:] INV_RECP 0 user@host.domain
>> gpg: [stdin]: sign+encrypt failed: unusable public key
>
> How can this be improved?  If you give PGG/GPG a disabled key,
> shouldn't it complain?

what can i say?

this user "has _another enabled key_" by the same id (email address
here).  pgg might complain (i don't care), but it should use the
enabled key instead!

the manual to gpg says in the section "edit key":

  enable    Disable  or  enable  an  entire key. A
            disabled key can normally not be  used
            for encryption.

there's a problem here with pgg's key-list parser(?).  gpg can list
keys in a way enabling a check for this condition.

from the DETAILS file in the documentation:

$ gpg --fixed-list-mode --with-colons --list-keys \
   --with-fingerprint --with-fingerprint wk@gnupg.org

pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC:
fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013:
uid:f::::::::Werner Koch <wk@g10code.com>:
uid:f::::::::Werner Koch <wk@gnupg.org>:
sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e:
fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1:
sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:

The double --with-fingerprint prints the fingerprint for the subkeys
too, --fixed-list-mode is themodern listing way printing dates in
seconds since Epoch and does not merge the first userID with the pub
record.

 1. Field:  Type of record
            pub = public key
            crt = X.509 certificate
            crs = X.509 certificate and private key available
            sub = subkey (secondary key)
            sec = secret key
            ssb = secret subkey (secondary key)
            uid = user id (only field 10 is used).
            uat = user attribute (same as user id except for field
            10).
            sig = signature
            rev = revocation signature
            fpr = fingerprint: (fingerprint is in field 10)
            pkd = public key data (special field format, see below)
            grp = reserved for gpgsm
            rvk = revocation key

 2. Field:  A letter describing the calculated trust. This is a single
            letter, but be prepared that additional information may
            follow
            in some future versions. (not used for secret keys)
                o = Unknown (this key is new to the system)
                i = The key is invalid (e.g. due to a missing
                self-signature)
                d = The key has been disabled
                r = The key has been revoked
                e = The key has expired
                - = Unknown trust (i.e. no value assigned)
                q = Undefined trust
                    '-' and 'q' may safely be treated as the same
                    value for most purposes
                n = Don't trust this key at all
                m = There is marginal trust in this key
                f = The key is full trusted.
                u = The key is ultimately trusted; this is only used
                for
                    keys for which the secret key is also available.

note the convenience for managing keys.  as long as a key hasn't been
verified, but already imported (the most regular case!), you can
always use a verified, but older key.  in my case i need to use the
newer key, but that's not important here.

clemens

Re: pgg doesn't recognise disabled keys!

[Raymond Scholz]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

* "Clemens Fischer" <ino-waiting@gmx.net> wrote:

> note the convenience for managing keys.  as long as a key hasn't been
> verified, but already imported (the most regular case!), you can
> always use a verified, but older key.  in my case i need to use the
> newer key, but that's not important here.

I wonder whether the detailled information can be used to query the
user if more than one key matches the recipient address.  Currently,
PGG always selects the first key reported, doesn't it?

As a work-around, one can specify recipients=<key-id> in the MML tag.

Cheers, Ray
-- 
It's a bit like shooting sparrows with a cannon (what's the English/US
idiom for this?) - Using Emacs to edit text files.
                         (Kai Großjohann and Per Abrahamsen on (ding))

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: pgg doesn't recognise disabled keys!

[Florian Weimer]

clemens fischer <ino-waiting@gmx.net> writes:

> pgg/gpg exposes the following behaviour:  when given a disabled key as
> a recipient who has another enabled key, the following error is thrown
> by mml:

Ah, I've just expirienced this myself.  I believe this is a bug in the
GnuPG key selection algorithm, and it should be fixed there.

Re: pgg doesn't recognise disabled keys!

[Clemens Fischer]

Florian Weimer <fw=d32yF4oPJVt0XxTmqZlbVQ@public.gmane.org>:

> clemens fischer <ino-waiting=hi6Y0CQ0nG0@public.gmane.org> writes:
>
>> pgg/gpg exposes the following behaviour:  when given a disabled key as
>> a recipient who has another enabled key, the following error is thrown
>> by mml:
>
> Ah, I've just expirienced this myself.  I believe this is a bug in the
> GnuPG key selection algorithm, and it should be fixed there.

no, this isn't true.  i just labored thru re-incorporating a "doubled"
key, disabling it and using the id beeing the same on both keys for
encryption.  it turns out that gpg-1.2.0 correctly ignores the
disabled key.  so this is a bug in pgg.

clemens

Re: pgg doesn't recognise disabled keys!

[Florian Weimer]

Clemens Fischer <ino@despammed.com> writes:

> no, this isn't true.  i just labored thru re-incorporating a "doubled"
> key, disabling it and using the id beeing the same on both keys for
> encryption.  it turns out that gpg-1.2.0 correctly ignores the
> disabled key.  so this is a bug in pgg.

A simple test is not sufficient, I guess.  If the active key is found
first, the disable one is probably never checked.

I've observed the phenomenon using the GnuPG command line interface...

Re: pgg doesn't recognise disabled keys!

[Werner Koch]

On Tue, 19 Nov 2002 23:45:54 +0100, Florian Weimer said:

> A simple test is not sufficient, I guess.  If the active key is found
> first, the disable one is probably never checked.

> I've observed the phenomenon using the GnuPG command line interface...

Yeah, we have this bug on our todo list.


Shalom-Salam,

   Werner

Re: pgg doesn't recognise disabled keys!

[Clemens Fischer]

Werner Koch <wk@gnupg.org>:

> On Tue, 19 Nov 2002 23:45:54 +0100, Florian Weimer said:
>
>> A simple test is not sufficient, I guess.  If the active key is found
>> first, the disable one is probably never checked.
>
>> I've observed the phenomenon using the GnuPG command line interface...
>
> Yeah, we have this bug on our todo list.

thank's very much, this will make disabling keys a useful feature.

  clemens