On Mar 7, 2013, at 5:45 AM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
If criticality is fraught with problems, doesn't that suggest extending
the usage flags is a more responsible way to go?
No, because either you want *that* to be critical, too, which has the same
criticality issue, or criticality is not important in which case the notation
works too.
My comment was one about criticality in general. We have criticality because
there were people in the late '90s who thought it was a good idea. It *is* a
good idea, but it is such a subtle idea that it's Shannon information,
kolmogorov complexity, etc. is more than one bit.
or should i create a subkey with all usage flags set to 0, and then
include a notation to indicate the use? that way, the subkey wouldn't
be used by any existing system except the ones willing to parse and
interpret the notation, regardless of its criticality.
Well, if you did that, you wouldn't not be RFC 4880 compliant. There is a way
to do this within the standard -- the notation.
The whole reason that we have notations is so that if you want to do something
on your own, there's a supported way to do that. What's wrong with using the
supported way, as opposed to violating the standard with hacks? (I'm not above
violating standards with hacks, but I expect to have to answer that question,
myself.)
If my cynical beliefs about criticality scared you away from doing the right
thing, then I apologize. I never intended to do that. I was merely pointing out
that if you put the critical flag on it, then it possibly would have unintended
failure modes and meta-failures.
The correct thing to do is a notation. Put the critical flag on it. Please.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp