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
