[ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ??)
Wanicki, Martin
Martin.Wanicki at Australia.Boeing.com
Tue Apr 9 10:28:32 EST 2002
> Martin> In fact I'd prefer that the replacement option to be key
> Martin> based, so that only the bona fide originator of a
> Martin> notification has the right to recall or change the notif.
>
d >using keys could ensure that the replacement message was
authentic,
d >but this is separate from the replacement mechanism itself, i
think?
Yeah, I agree, although if a notif could be *keyed with the plaintext of the
replacement id hash
it would work, but then I know three fifths of feck-all about security and
keys :-(
*Keyed : Its my understanding that keys are not a client readable part of a
notification
and I'm not familiar enough with the api to know if there is a way
to throw a key at a routine
to check if the notif has this key
Basically i was thinking along the lines of a digital signature. the
signatures should match before replacement is done.
I really dont know how to solve this but I know i would prefer it to be
secure.
What i did in eTiks that started out as an exercise in keeping the message
thread and scroller quiet if I get 300 of the same notifs
ended up with me indicating in my message thread how many times a notif hase
been replaced or how many times a duplicate has been
received.
There is an audit trail associated with this showing the plaintext of each
and every notif and the subscription text that caused the client
to receive it.
If a duplicate is ever received on the same sub, I can safely assume the
second or subsequent ones are bogus, and I can check the contents
to see the diffs.
With replacement, I keep the same history, so I can see what was replaced by
what.
Over to y'all
regs'
Martin
More information about the ticker-dev
mailing list