Hi, On the first item, yes, the first item (RSID) is clearly a counter; a time stamp cannot be used, nor can a value that is arbitrarily generated.
To use a time stamp would require a parameter that is differently defined than the current RSID. One approach would be to define a "union" of some sort - or introduce a second parameter to indicate how to interpret the RSID (if it represents a counter or a time stamp, is persisted or not). At this point, I would refrain from either. However, I do think it is fair to state there is no requirement that RSIDs be sequential - all that is required is that they increase; they don't have to increment just by 1. I think this leaves sufficient flexibility for the implementation to distinguish reboot sessions even in the absence of a persistence support, while keeping the scheme sufficiently simple. --- Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, February 05, 2009 1:39 AM To: [email protected] Subject: [Syslog] Syslog-sign: Last minor clarifications/nits I've now gone through all the emails and comments (I think), and this email should contain all the stuff that wasn't covered by the earlier emails yesterday and today: In http://www.ietf.org/mail-archive/web/syslog/current/msg02030.html, Martin asked whether it's OK to use time() (or similar) as RSID. A strict reading of the current text does not seem to allow this. However, if the originator can't reliably store a persistent RSID counter, using a timestamp as RSID would probably provide more useful information to the collector than always sending 0 (even though timestamps are not always increasing, most of the time they are). What do others think? I think Sections 4.2.8 and 5.3.2.8 still need to be clearer about what octets exactly are signed. Here's my suggestion: The signature is calculated over the completely formatted Signature Block message (starting from the first octet of PRI and continuing to the last octet of MSG, or STRUCTURED-DATA if MSG is not present), before the SIGN parameter (SD Parameter Name and the space before it [" SIGN"], "=", and the corresponding value) is added. Section 5.3.2.8: The signature is calculated over the completely formatted Certificate Block message, before the SIGN parameter is added (see Section 4.2.8). Sections 5.3.2, 5.3.2.9, and 9.1 misspell Total Payload Block Length as TBPL (instead of TPBL). Depending on what format (OpenPGP MPI style or ASN.1/DER) we'll use for key blob type 'K', the example in 5.3.2.9 may or may not need updating. Best regards, Pasi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
