[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Series of minor questions about OpenPGP 4
On Thu, Jan 29, 2009 at 8:37 PM, Jon Callas <jon@xxxxxxxxxx> wrote:
> On the contrary, I think you should start discussing things here and
> start writing drafts.
I don't believe I'm technically skilled enough for doing this. And I
must admit that I've borrowed some (of course not all) ideas here from
some threads I've found on the gnupg mailing lists. I've already
contacted the author (Christoph Mitterer) of that threads and I hope
he'll have a look at the currently ongoing discussion.
>>> might also want to require the critical bit to be set on those
>>> although that will impair interoperability.
>> What do you mean with this? Require it by the RFC?
> No, the critical bit means that you want an operation to be 100%
> correct or to fail. If there is any doubt in anyone's mind, you want
> the system to halt with an unrecoverable error.
Would you guys here, I mean Hal/Jon from PGP and David from gnupg
suggest, that I set critical bits on the subpackets I listed before?
Would your implementations (PGP/GnuPG) support this?
Would you (and of course the other list members) support the idea of
having the security critical subpackets REQUIRED per default by a
> Hal points out that this will mar interoperability.
We'll but that was the idea. An implementation that does not support
e.g. signature expiration should better fail at all.
>> What was the reason that the key expiration time was taken out of the
>> key itself (I think it was there before?)?
> Because in PGP 3, a number of attributes were moved to the self-sigs
> with the thought that you might have a key with different user ids and
> different features. For example, I might have a user id in which a
> cipher is allowed, and one in which it is not. You might also want to
> have different expirations on those user ids.
Well my idea is the following: We have the key expiration time, we
have the User ID self-signatures and we have signature expiration.
- If a user wants to just expire the key with one specific User ID, he
could either revoke the corresponding self-signature or set an
signature expiration time on it.
He could even re-set it later by creating a new self-signature.
- If all self-signatures (0x10-0x13 and 0x1F) are expired or revoked
it's basically the same as if the whole key expired/revoked.
So I think the key expiration flags somehow doubles that functionality
and to me it made more sense when it was part of the key itself and
thus kind of a promise that could not be changed later (e.g. by
issuing a new self-signature)
>> Well this would be great,.. I mean the current MAIN implementations of
>> OpenPGP are probably GnuPG and PGP. I think David and Werner who
>> represent GnuPG are reading this list and you, are you still at PGP
Great, so you can comment whether you'd support such changes as I
propose for the criticality of signature subpackets.