Hello, I just wanted to let you all know that I have submitted a new draft of syslog sign, as the old one was about to expire. The new draft should appear shortly if it hasn't already; here is a summary of the changes and updates that were made.
The changes were along the lines of what was presented at the Vancouver meeting, the most important of which concerns utilizing structured data to capture the fields of Signature and Certificate Blocks - a prudent use of structured data which avoids having a payload that is essentially "binary". Of course, unfortunately syslog-protocol now appears to be further away from completion than it did earlier, and really we would like syslog protocol to be stable to that respect before basing further work on that. However, at the same time, the consensus of the group by and large seems to be to retain structured data, so this provides perhaps a view of how it can be utilized. At the same time, please note that syslog sign as currently worded is actually not dependent on a specific syslog protocol syntax - if you will, you could send syslog messages with a message body that happens to be formatted respectively conform to the syntax as set forth in syslog-sign. Note that the Payload Block format was not changed. Payload Blocks are essentially carried as part of Certificate Blocks; those utilize structured data, but as Payload Blocks are not associated with an actual syslog message directly it seems as if it is not necessary to change the way Payload Blocks are encoded. Quite possibly, this will of course be subject to further discussion. The cookie field was removed. Identification of a Signature Block respectively Certificate Block can occur through use of an according SD-ID. Another modification that was made, which will surely require more discussion, concerns the reboot session ID. For devices to be able to conform to this, they would need to be able to persist the reboot session ID such that it survives reboots (so to be able to increment after a reboot). The question is to allow for the possibility of allowing devices who cannot support such a feature to still support syslog-sign, with the understanding that in this case, there would be no guarantee that messages would be uniquely distinguished across reboots. It appears that this would still be useful, provided it can be easily distinguished whether or not reboot session ID is supported, which can be accomplished by the choice of ID (0 if not supported, 1 through 9999999999 otherwise). Comments or thoughts? Beyond that, you will find a number of editorial updates with the goal of making the document slightly more readable. Updated sections include for example section 4.4 on Signature Group and Signature Priority. There is of course more work to be done. In addition on closing on the suggested items, one aspect that is currently not addressed and requires discussion concerns any aspects about the message header of syslog messages carrying a Signature or Certificate Block - for example, assignment of a message ID, proper PRI etc. Looking forward to fruitful discussions --- Alex _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
