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

Reply via email to