Best practice for periodic key change?

Jerome Baum jerome at
Tue May 10 17:55:58 CEST 2011

I don't see why it would need a standards change, or why the option can't
be, well, optional. We aren't trying to force all gpg installations to
conform, but to make it possible to configure an installation to conform.
Normal gpg should continue to function.


Am 10.05.2011 15:33 schrieb "Hauke Laging" <mailinglisten at>:

Am Dienstag, 10. Mai 2011, 07:10:42 schrieb Jerome Baum:

> an option for GnuPG: reject-subkey-signatures

> No need to change OpenPGP for this.
This is possible only if it is safe for old implementations. I see one
for that: A signature notation for this purpose could be defined and this
notation could be marked critical. The standard says:

"If a subpacket is encountered that is marked critical but is unknown to the
evaluating software, the evaluator SHOULD consider the signature to be in

I don't understand whether this refers to the packet type or the packet
content. If an implementation knows what a notation is (and shows it) but
not know the meaning of the new standardized notation what is it supposed to
do according to RFC 4880? Generate an error saying "I don't understand what
this notation is about" or signal success saying "I recognize this as a
notation. (And I don't care about its content.)"?

If the recognition refers to the content then it's easy. There would be the
practical problem left to check how the (relevant) implementations behave.
It's no use if you are theoretically right but it is trivial to trick people
into acceptance of wrong signatures because an often used software does not
work right.

A safe solution should be to define a new packet type. That might be a
"notation with critical content" type. This would behave like a notation
the difference that the recognition check is extended to the content (if
packet is marked critical?).

But if the standard is extended then it makes more sense to have subkeys
certified explicitly instead of forbidding the acceptance of normal subkeys

> The CA would then sign the master key that is generated on-card, and the
> certification just wo...
In theory. The practice problem remains: Do "all" implementations behave

PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Gnupg-users mailing list
Gnupg-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110510/3f83c5f9/attachment-0001.htm>

More information about the Gnupg-users mailing list