Thinking a little more about it, I am not sure if we the requirement to sign the same signature group with multiple algorithms by the same originator. If we allow for multiple originators on the same host as I think we are saying we would, they each can have their own definitions of the same signature group and use a different algorithm. Likewise, a single originator can define two signature groups with separate SPRIs that include the same messages, and sign each of them with a different algorithm. With those capabilities, the space should be well covered, and in practice should be able to accomplish everything that we could by allowing multiple algorithms for the same signature group using the same identifier from the same originator on the same host, without requiring the associated completiy. With this, I think the remainder of the issues you bring up are moot.
On the last item, agree, let's make it "MUST NOT be signed". --- Alex -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte Sent: Monday, August 04, 2008 6:50 AM To: [email protected] Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 Alexander Clemm (alex) schrieb: > 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> To allow multiple algorithms inside one signature group then one could use multiple SIGN params with prefixes to identify their algorithm. E.g. [ssign ... SIGN="1;<base64 signature DSA/SHA-1>" SIGN="2;<base64 signature DSA/SHA-256>"]. But I do not like the concept. Just using two Signature Groups in parallel allows the same thing with greater flexibility and simpler implementations. (Maybe with more messages, but that is not negative for a protocol that has to be redundant by design,) > This leads me to a problem in 4.2.3.: "In all cases, no more than 192 > distinct Signature Groups (0-191) are permitted." > > <ALEX> I am not sure I understand the issue? I think the problem is we have different concepts of a "Signature Group". A definition would be useful. The Introduction states "A Signature Group identifies a group of messages that are all kept together for signing purposes by the originator." I would add the list of attributes that I consider the actual identifiers: (HOSTNAME, APP-NAME, PROCID, MSGID, VER, RSID, SG, SPRI). It follows: Two syslog-sign messages with the same values for these fields belong to the same Signature Group. Two syslog-sign messages which values differ in any of these fields do not belong to the same Signature Group. > The fact that the SPRI > parameter may take only values from 0-191 inclusive already implies > there can be no more than 192 values? Yes, indeed. But that makes the sencence only more confusing, because what do the given numbers 0-191 mean if they do not refer to SPRI 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> I am sorry if this appears like nit-picking, but do you say - There can be no more (=follows logically from the definitions/construction)? or - There should be no more (=there could be, but we set an arbitrary upper limit for interoperability)? Maybe we can use an example to test the limits: Say I want to use VER="0111" and VER="0121" in parallel so I have every message signed twice. And I also want to use SG="1". Then I have 384 concurrent Signature Groups. Ennumerating with the identifies as above (HOSTNAME, APP-NAME, PROCID, MSGID are constant) gives the list: 1. (..., VER="0111", RSID="123", SG="1", SPRI="0") 2. (..., VER="0111", RSID="123", SG="1", SPRI="1") ... 192. (..., VER="0111", RSID="123", SG="1", SPRI="191") 193. (..., VER="0121", RSID="123", SG="1", SPRI="0") 194. (..., VER="0121", RSID="123", SG="1", SPRI="1") ... 384. (..., VER="0121", RSID="123", SG="1", SPRI="191") Should this be a valid protocol use or not? > <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> Could we replace "do not need to be signed" by "MUST not be signed" then? -- 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
