Bug: Unusable key

[David Shaw]

On Thu, Feb 05, 2004 at 11:20:17PM -0500, gabriel rosenkoetter wrote:
> On Thu, Feb 05, 2004 at 12:12:43PM -0500, David Shaw wrote:
> > Unless I misunderstand your suggestion, that would mean that in cases
> > where a user has a collection of old expired subkeys (and the one
> > current one), there will be a whole lot of output about "subkey xxxxx
> > expired" every time the key was used.  Messy.
> 
> No, you only produce error output if you can't find a useable key.
> 
> > Even if the error list was only printed if there were no usable
> > (sub)keys at all, over time the list would just get longer and longer.
> 
> So?

Where does it end?

> If you prefer, or in absence of a request for verbosity, just print
> the latest-dated (by creation would work, but by expiry or
> revocation would be better) key and the reason it was unuseable.

I think that's more confusing than helpful.  "such-and-such skipped:
the most recent subkey was revoked or expired".  If I saw an error
message like that I'd wonder why the other subkeys weren't usable.
Worse, I'd start to think that only the most recent subkey was
relevant, as stated by the error message, which isn't true.  Worse
again, there doesn't have to be SUBkeys involved in the first place.
V3 keys don't have them, and V4 keys can be sign+encrypt.

The current error message says, perhaps over-tersely, that the user
asked to encrypt to key such-and-such.  Key such-and-such (including
any and all subkeys) couldn't do it.  Thus, "unusable public key".

"key does not support encryption" - better, but not completely good
because clearly it did support encryption before the subkey expired.

"key does not currently support encryption" - sure, but why?  It did
support it yesterday.

"no currently valid encryption capability" ?

"no unexpired or unrevoked encryption capability" ?

"all encryption capability is missing, expired, or revoked" ?  Ugh.

"no usable encryption capability" ?

"not capable of encryption" ?

These are really just trading something terse and mostly unhelpful
(but true) for something else terse, mostly unhelpful, but true.

> As soon as you've got a useable one, you're done, and you don't
> produce any error output, and that's BY FAR the more common case,
> isn't it?

I'm not concerned about the successful case.  There is already a good
answer for that (say nothing).  I don't agree with the argument that
an error message doesn't matter because it isn't the common case.
Clearly, this one confuses people because this isn't the first time
it's come up on the list.  If it really didn't matter, then I may as
well leave it as "unusable public key".

If the user requested a particular subkey, I could show an error
saying "subkey XXXXXX: can't use it because it's not capable of
encryption" or "is expired", or "is revoked".  If the user asks to use
"the key" as a whole, then the unfortunate fact is that there are a
huge number of possible reasons why a given public key might be
"unusable".

David