[ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?)
David Arnold
arnold at dstc.monash.edu.au
Tue Apr 9 12:24:47 EST 2002
-->"Ian" == Ian Lister <ilister at dstc.edu.au> writes:
>> does this actually get you any greater confidence than using a
>> producer-scheme key? in both cases, all it proves is that the
>> message sender(s) had access to the same private key?
Ian> Yes, it allows you to verify invidual producers, as opposed to
Ian> just verifying that the producer is in the (possibly rather
Ian> large or even infinite) set of producers permitted to send
Ian> notifications that match a particular subscription.
ok, so that seems to be the crux of the issue.
it would be possible to achieve this by using a subscription together
with key(s) obtained from the sender to achieve the same result, but
you'd prefer to have a single, potentially more broad, subscription,
and do application-level checks on replacement messages.
while this basically introduces a redundant means of authenticating
messages, i suppose it *might* be easier to implement.
Ian> There's no point in having this mechanism if the original
Ian> message isn't at least obscured in some manner,
well, i'd debate that too. i'm perfectly happy with an insecure
mechanism for almost all my tickertape usage, and my current usage of
REPLACEMENT is no exception.
Ian> but as soon as you allow messages to replace others without
Ian> appropriate security measures (where I believe `appropriate'
Ian> means more than just making sure the producer has rights to
Ian> send to you) you have a potential attack.
right.
i'm happy with that, but i'm reluctant to require a duplicated
mechanism.
could you explain why you'd prefer this than using multiple
subscriptions and careful handling of the deliveries to achieve the
same result?
d
More information about the ticker-dev
mailing list