There is one additional aspect, concerning consistency of APP-NAME and PROCID
between Signature Block and
Certificate Block messages. There is currently no statement regarding this,
although I believe it makes sense.
I am putting the following text - please let me know if there are objections:
In section 5.3.1 (on Certification Block messages):
Syslog-sign does not mandate particular
values for these fields; however,
for consistency, implementations MUST
use the
same value for APP-NAME, PROCID, and
MSGID fields for
every Certificate Block message,
whichever values are chosen.
To allow for the possibility of
multiple originators per host,
the combination of APP-NAME, PROCID,
and MSGID MUST be unique for each such originator.
If an originator daemon is restarted,
it MAY use a new PROCID for what is otherwise the
same originator. The combination of
APP-NAME and PROCID MUST
be the same that is used for Signature
Block messages of the same originator; however, a
different MSGID MAY be used.
In section 4.1: (on Signature Block messages):
This specification does not mandate particular
values for these fields; however,
for consistency, originators MUST use the
same values for APP-NAME, PROCID, and MSGID
fields for
every Signature Block message that is sent,
whichever values are chosen.
To allow for the possibility of multiple
originators per host,
the combination of APP-NAME, PROCID, and MSGID
MUST be unique for each such originator.
If an originator daemon is restarted, it MAY
use a new PROCID for what is otherwise the
same originator.
In section 4.2.2 (on reboot sessions):
If a reboot of an originator takes
place, Signature Block messages MAY use a new PROCID.
However, Signature Block messages of
the same originator MUST continue to use the
same APP-NAME and MSGID, in order
to prevent collectors from mistaking
the originator.
--- Alex
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte
Sent: Monday, August 04, 2008 6:59 PM
To: [email protected]
Subject: Re: [Syslog] Syslog-sign: Multiple signers on host?
Alexander Clemm (alex) schrieb:
> It is possible to differentiate different signers by saying APP-NAME
> and PROCID are relevant and MUST be used consistently. It would then
> also imply that different signers can "reuse" the same SPRI,
> providing they indicate SG=3 when establishing the signature group.
Different signers can also use the same SG. Otherwise it would be
impossible to have a central log server for many clients (=signers) ;)
> Not sure if it was intentional, but you bring up a notion of a
> duration of a signature group. This is a different notion than what
> we have right now. We only have a notion of a reboot session. At
> the beginning of the reboot session, the payload blocks are sent for
> the various signature groups. So, the duration is "global" for an
> originator, not differentiated between signature groups. Now, in
> principle it is certainly possible to change the semantics of "reboot
> session" to that of "signature group session". It does open up a lot
> of other questions and add complexity, as now a multitude of reboot
> sessions needs to be kept track of. Is this really required? It
> would seem that we should stick to the simple semantics of reboot
> session. Different signers can of course have their own reboot
It was unintentional.
From the perspective of the originator I implicitly assumed the RSID is
a global state and a "reboot event" affects all signature groups.
But now that I think of it I do not see that it makes a big difference
whether "signature group session" were allowed.
The sender can use whatever it wants, so the focus has to be on the
receiver/verifier and the protocol has to limit its complexity.
Our receiver already has to process different message streams, keep
track of multiple signature groups from different originators, check
every signature block's attributes for validity, and recognize new
reboot sessions from a sender.
Now what constraints do we have when we have when assuming a
"sender-global" reboot session? And which constraints disappear when we
allow "signature group sessions"?
I see only the difference between a) finding the signature group and
comparing the RSID and b) using the RSID as part of the identifier to
find the signature group. That certainly does not change the overall
complexity.
---
Just to make my position clear: I think a "sender-global" reboot session
is just fine; I do not see a serious use case for "signature group
sessions" and have no intent to 'push' this into the standard.
But on the other hand I do not I do not see a reason to limit the
possible options without an apparent reason.
---
With regard to the notion of a reboot session I would like to revise my
previous definition of signature group identifiers to use a more
hierarchical approach:
ORIGINATOR := (HOSTNAME, APP-NAME, PROCID)
REBOOT_SESSION := (ORIGINATOR, VER, RSID)
signature group := (REBOOT_SESSION, SG, SPRI)
Is that closer to your conception?
I am only a bit undecided whether VER identifies a REBOOT_SESSION or a
signature group inside the REBOOT_SESSION.
> sessions. So, your text is basically okay, but I would argue that
> the last sentence must read "To allow multiple originators per host,
> the values of APP-NAME and PROCID MUST be unique for the duration of
> the reboot session."
That's fine with me.
--
Martin
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
