In some places, the draft seems to assume the "traditional Unix model" where a host has a single "syslog daemon", which receives messages from applications via IPC, and sends them to relays/collectors using the syslog protocol (and signs them). This of course isn't the case in all systems; e.g. if I configure Apache Tomcat on Windows to send messages to a remote syslog collector, it does so directly (not going via any central syslog daemon).
If there are multiple syslog signers on the same host, the assumption (in Section 3) that "the signature and certificate data do not need to include an additional parameter to identify the machine that orginates the message" is no longer 100% accurate. While HOSTNAME identifies the host, to figure out which Certificate Block messages belong together, and which Payload Block applies to which Signature Block, it seems additional information could be needed in some situations? (unless you try all combinations by brute force) There might be many different ways to solve this problem; one semi-obvious one would be to include the hash of the Payload Block in all Certificate Block and Signature Block messages. Or perhaps it should be some kind of session identifier, similar to reboot session ID, except not monotonically increasing? (This could be e.g. hash of payload block, process ID of the process doing the signing, the local time the process was started, and similar things likely to result in unique string.) Or maybe something else? Are the APP-NAME/PROCID of any use here? Section 4.2.2 (about the reboot session ID) also assumes a central syslog process that's tightly coupled with host reboots -- it should be described in terms that make sense in other models, too. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog
