Hi, please see inline, delimited <ALEX>
--- Alex -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte Sent: Friday, August 01, 2008 2:52 PM To: [email protected] Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 [EMAIL PROTECTED] schrieb: > Is it possible to sign the same set of messages with multiple > algorithms (by sending multiple Payload and Signature Blocks) to > provide smooth algorithm transition? I think it should be possible. A message can belong to multiple signature groups, so an originator could e.g. use one signature group with SG="0" and VER="0111" and a second one with SG="0" and VER="0121". <ALEX> The same message can be in multiple signature groups and hence be signed multiple times. It is also possible to define multiple signature groups so that each contain exactly the same messages (e.g. SG="3", which basically means administrator-defined which would be anything). This leaves the question whether it should be possible to sign the *same* signature group with multiple algorithms. There are currently no provisions for that. The spec also states that a payload block (containing the certificate information) is valid for the entire reboot session - we currently do not allow to change it during a reboot session. If this is an issue, it will have some ramifications. One way to deal with it would be to change the way a "reboot session" is defined. Thoughts? </ALEX> This leads me to a problem in 4.2.3.: "In all cases, no more than 192 distinct Signature Groups (0-191) are permitted." IMHO that should be removed or changed to "In all cases, no more than 192 distinct SPRI values (0-191) are permitted." Such a limit would clearly prevent using parallel versions for SG="1". Or in another scenario: my syslogd uses SG="3" to assign one signature group per destination. So that limit would prevent the use of more than 192 destinations. <ALEX> I am not sure I understand the issue? The fact that the SPRI parameter may take only values from 0-191 inclusive already implies there can be no more than 192 values? I think the statement is correct as is - the signature group refers to a set of syslog messages while the SPRI value defines what messages that set contains - we do however want to call out that there can be no more than 192 such sets. </ALEX> > Section 4.2.5: When counting messages for the "First Message Number" > field, are Signature Blocks and Certificate Blocks also counted? Whether the FMN counts syslog-sign messages depends on whether these are hashed and included in Signature Blocks. > Should earlier Signature Block and/or Certificate Block messages be > included in Hash Blocks? 4.1: The syslog messages defined as part of syslog-sign themselves (Signature Block messages and Certificate Block messages) do not need to be signed by a Signature Block. Collectors that implement syslog- sign know to distinguish syslog messages that are associated with syslog-sign from those that are subjected to signing and process them differently. I guess there are arguments for both positions but IMHO syslog-sign messages should not be hashed and included because a) I see syslog-sign as a kind of session-layer that should disappear after the verification is done and some log-analyzer (=application layer) takes over, and b) the verifier will have to know to treat them differently anyway and leaving them out avoids several problems and special cases. Either way the standard has to decide for one position to ensure interoperability. Otherwise one might have a sender that does include hashes of syslog-sign messages in its Signature Blocks and a verifier that will not check them but report lost messages. <ALEX> Section 4.1 states that syslog-sign messages are not counted and not signed, so I think the current position is clear. Martin, I agree with your reasoning and argumentation. Essentially, the purpose is to sign a stream of messages, not alter that stream of messages. </ALEX> -- Martin _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
