Best practice for periodic key change?
mailinglisten at hauke-laging.de
Tue May 10 15:26:30 CEST 2011
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 option
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 does
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
A safe solution should be to define a new packet type. That might be a generic
"notation with critical content" type. This would behave like a notation with
the difference that the recognition check is extended to the content (if this
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 in
> The CA would then sign the master key that is generated on-card, and the
> certification just won't apply to the sub-keys. Does this solve the "all
> signatures _must_ be generated on-card" issue?
In theory. The practice problem remains: Do "all" implementations behave that
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users