On Mon, Feb 2, 2009 at 4:12 AM, David Shaw <dshaw(_at_)jabberwocky(_dot_)com>
wrote:
Many of the questions you are asking are of that sort, hence the difficulty
answering them. At one point, there was discussion about writing a second
document to cover these sorts of questions. Possibly it is time to restart
that.
Yes I see, and fully understand ;-)
I hope I didn't get to much on your nerves,... but I think it showed
that there's really an interest in such kind of a document :-)
The
RFC also doesn't stop you from doing foolish things (which is a feature, not
a bug).
Well I'm not sure about this ;-)
From a cryptosystem I'd expect that nearly everything is as strictly
defined as possible, in order to avoid ambiguities or conflicts
between implementations, which could lead to security issues.
But of course this is just my opinion, and it's not my intention to
offend the way it's handled right now :)
I would advise against changing the expiration time of the key depending on
how it is selected. A key should have one expiration time, or you're in for
a lot of pain when a user sending to one user ID sees the key as expired,
but a user sending to a different user ID on the same key does not. If that
is the goal, you should be expiring the user IDs differently. Not the key.
Of course,.. but this is just the problem I want to show. An
implementation could call itself conforming to the RFC (and actually
it would be), but it could do all these stupid an bad things.
The shorter answer is that GPG will take an expiration, a revocation key
("designated revoker"), or key flags from an 0x1F.
Thanks.
Thanks,
Peter