Best practice for periodic key change?

[Hauke Laging]

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 
error."

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 
work right.

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 
general.


> 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 
way.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110510/de074369/attachment.pgp>