Hoi (dutch for hello:-) I've been a bit passive lately, but starting to catch up ...
Yesterday, I downloaded draft-11, and I see a lot of work has been spent on it. Great work! Also, I continued implementing it and so I found a few items. Furthermore, I did see some improvements to the "old" syslog protocol are made, like long timestamp and long hostname. Great! I know, there has been a bit of discussion about that. I didn't follow that (actively), and _*_don't_*_ want to start that thread again! However, I will raise some remarks on the current draft issuing those. Things I find hard to understand/implement. Please comment on them, by pointing to those threads, (of I missed them). Or maybe the text can be a little clearer. Again, I welcome the improvements. I only raise them to understand (and clarify) how to implement that for an environment where both "rfc3164" and "syslog-sign" should be operated. (mixed). The order of the issues is unsorted, but for the items issuing "compatibility", which can be found at the end. GENERAL (by topic) ================== * TAG (Page 9) -------------- Would it be an improvement to allow a dot (.) in the tag. In general a tag will contain a programname, and a process id like: ``name[number]:'' In some environments, it should welcome (I assume) to extent this an detail a thread-ID. When a dot is allowed the "number" can formatted as a partial-number instead of an int, giving space to an thread id. Note: this enhancement will not break rfc3164, as the tag (then) is part of the "free formatted" part. * "message flow" (introduction) ------------------------------- Although I do understand the setup of syslog-sign and how certificates should be chained to groups of messages, possible (new) readers will find it hard to understand. The explain syslog, I use the word "flow" (or path) and notice that this generally is understand well. Therefore, I suggest to extent the introduction a little, to explain that messages are routed and so create one or more "flows". And that is in important that several flows can be separated and use other "signatures" (to skip a few details). I'm willing write a proposal. * Spaces and crypto (P 16 sec 3.10) ------------------------------------ The current proposal solves my earlier remark(s) about exactness of spaces! However, this implies the crypto routines become complicated. Does everybody accepts this? (Just to mention the topic) * Signature over .. (P16 & P20 (Sec 3.10 & 4.3.8) -------------------------------------------------- Possible, someone will misread these sections (which fields are used to calculated the signature). Maybe we should add a line as `` So the signature is calculated over the completely formatted syslog-message, excluding spaces between field, and also excluding this signature field.'' COMPATIBILITY ============== General ------- Syslog-sign claims to use only "valid" rfc3164 messages (which is compatible: the can be routed by rfc3164 relays) However, some extensions break this. In rfc3164 is written the HOSTNAME should be without a domain. syslog-sign changes this. On page 6 is written "a sender SHOULD ..." use the long version. This means I can not write syslog-sign-daemon that uses short-hostname (to be able so send to "old" syslogd's) and use signatures at the same time. Iff that is true, I will break the rfc:-) This applies both to HOSTNAME and TIMESTAMP. Detail: an alternative is "repeating" hostname and timestamp in the "free format" part of rfc3164, as that rfc suggest. Section 3.1 (page 11) --------------------- The remark "don't need to be backward compatible" is _wrong_. rfc3164-relays are allowed to route on (e.g.) hostname. So, the should be able to parse HOSTNAME. Which means only HOSTNAME-3164 formatted headers should be used! Only a "device" must to understand syslog-sign. And the (offline) signature-checker. Both relay and collector can route en store all kind of (UDP) syslog messages! Note: this implies the collector should store messages as-is, including the PRI field. Most syslogd's don't do so; but that is a implementation detail. I have a syslogd, that does store transparent, to be able to use offline -sign verification! Conclusion ---------- Least but not last, I think I can implement syslog-sign "know". Which (for me) means it the draft is clear. This implies the remarks are mainly suggestions to improve the document, not the standard. John and Jon (and others) GREAT WORK! -- --ALbert Mietus Send prive mail to: [EMAIL PROTECTED] Send business mail to: [EMAIL PROTECTED]
