Thomas Roessler, <roessler(_at_)guug(_dot_)de>, writes:
How do the current implementations handle this situation (most
notably the NAI ones)? Should the specification be changed? Should
extensions to RFC 2440 which have to put critical information into
signatures define sub-packets of their own, or should they use
notation data to avoid name-space cluttering?
The NAI software ignores notation packets. If they are marked critical,
it treats the signature as invalid for trust calculation purposes.
Notation data is meant as an extension mechanism which is more text
oriented rather than using new binary signature packets.
I would suggest that if the human-readable bit is set, the only
obligation on the part of the application is to display it to the user.
If it does so, then it can consider the notation "handled" and it can
validate the signature even if the critical bit is set. (Probably it
would be a good idea to note to the user that the critical bit was set,
when the notation was displayed.)
If the human-readable bit is not set, then the application should see
if the name field in the notation is one that it recognizes the meaning
of. If not, and the critical bit is set, it should not validate the
signature, because it doesn't know what this critical packet is trying
to say.
Hal Finney
Network Associates, Inc.