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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
