On Mar 6, 2005, at 5:45 PM, Douglas Otis wrote:
A requirement that the opaque identifier represents only a single
label would keep this mechanism simple. Allowing use of multiple
could provide an administrative advantage by being able to kill a
message rather than a whole account, as Phillip suggests. The selector
could be included within this path as well to allow immediate reuse of
account numbers, as example. An opaque identifier definition would
allow greater complexity without constraints. In an effort to ensure
simplicity, one or two labels could be a limit. This is a trade-off.
What is wrong with just making the revocation ID any valid domain name?
That makes this really simple and puts the choice of complexity for
revocation in the hands of the admins.
There is another cost savings, by authenticating the HELO and finding
that it is within the signature domain, a revocation record check could
be skipped. Even when everyone published revocation-identifiers, the
traffic should remain small by being generated when the message is
forwarded or sent unaltered from a list server.
I'm not sure this is a good idea. By attaching the HELO identity to a
subpart of the signature domain, doesn't this impact forwarding? Also,
it requires the HELO identity to be a subpart of the signature domain
which isn't true even in a lot of hop-by-hop cases.
If you are suggesting this is an optimization, I'm not sure it is
saving much if anything. It also seems to be introducing an extra step
adding to overall complexity.