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.
(Mobile/Handy) Am 10.05.2011 15:33 schrieb "Hauke Laging" <mailinglis...@hauke-laging.de>: 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 wo... In theory. The practice problem remains: Do "all" implementations behave that way. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
