Re: 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