 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi Alex, Thanks for the explanation - it
did indeed clarify things, and seems to provide a simple way to fix the
situation! The word "originator"
comes from RFC 5424, and the current version of syslog-sign seems to assume
that originator both originates normal syslog messages *and* signs them
(originates Signature/Certificate Block messages). But your explanation -- a
single originator (of normal syslog messages) could even have multiple signers
(with different APP-NAME,PROCID) that sign the *same* normal syslog messages
(with different algorithms) -- would seem to clarify things. However, this does require some
changes to the draft, right? (introducing the term "signer", and
replacing some instances of "originator" with "signer") Best regards, Pasi From: ext Alexander Clemm
(alex) [mailto:alex at cisco.com] Hello Pasi, I guess any confusion stems from the use of the word
“originator”. Therefore, let me use the term
“signer” for the purposes of this discussion. A signer signs
syslog-messages using a specific algorithm; it is an “originator”
of syslog-sign messages. A single host can host multiple signers, which
then each use their own Signature Groups and algorithms. The syslog-sign
messages can be attributed to a specific signer using (HOSTNAME, APP-NAME,
PROCID). Section 7 does say that you can separate syslog-sign messages
according to signer, using this triple. (It is the syslog-sign messages
you are concerned about; you separate the syslog-sign messages by
signers. You can separate the “normal” messages by virtue of
who signed them.) So, in summary, the ability to be able to use different
algorithms to sign messages is supported, but the corresponding syslog-sign
messages need to use different (HOSTNAME,APP-NAME,PROCID) to be able to
distinguish which is used where. Now, the question is whether to equate “signer”
with “originator”. If you equate them, then each signer would
be considered its own originator of its own syslog messages. However, you
can also simply regard it from the perspective that the same originator can in
effect incorporate multiple signers, if wanting to use multiple algorithms
concurrently. It doesn’t really matter – just like with
“normal” syslog messages without syslog sign you don’t really
distinguish if there are multiple originators on the same host or only one
– the syslog message does not contain an “originator-ID” but
(HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you support
the ability to sign messages using different algorithms from the same
host. Does this clarify? --- Alex Pasi
Eronen wrote: “Hmmm...
the major challenge in -25 was that although Payload/Signature Block
identify the originator (HOSTNAME,APP-NAME,PROCID), normal syslog
messages do not. So it seems you cannot separate the stored log
files by originator, and process the parts one by one. If
I understand you right, you're saying Section 7 does *not* in fact
assume that you can separate the normal syslog messages by
originator? BTW,
version -26 is still silent about whether a single originator can
sign the same set of messages using different algorithms (VER), and
if it can, whether these are same Signature Groups (with same message
number space) or different. What's your proposal for addressing
this -- or do you think signing using multiple algorithm doesn't
have to be supported?” |