> And then you also have the case of multiple signature blocks being
> lost. Either proposal ("past-34" or "past-17+next17") sounds like
> it will well cover what we have in the charter.
I'm not sure how you send a hash for the next 17 messages, particularly if
you haven't generated them yet? Perhaps it would be better to phrase it as
"the most recent 34 messages" signed every 17 messages, so each signature
winds up in two messages.
Of course, this could be every 34 messages if using reliable delivery.
> >The big question to me is how we can encode this signature
> >block so that it will always be forwarded to the same place
> >as the messages associated with it are forwarded. Is there
> >any way to reliably do this?
>
> I think that would be an implementation issue. The import thing
> in the ID is the description of the signature block and its
> usage. It should be noted in the ID that it will only be useful
> if it is received by the devices receiving the syslog messages.
> I'd suggest keeping it within the syslog format; perhaps using
> <46> = syslogd facility + informational severity.
Another possibility is to include signatures only from one particular
priority, so the signatures go all the same places the priorities go. I.e.,
a <29> priority message is signed only in a <29> priority signature. I can
see that might confuse some syslog analysis clients that are currently
expecting a particular format for messages, tho.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Both democracy and capitalism are attempts to make
greed and selfishness work for the greater good.
