Hay all,
Aside from the discussion on "the cost of DSA", a few more comments on the
current draft (04).
[ I looked over them, the last time]
* Why is the (H3.2) PRIORITY field call so?
We need a field which stores the version(s) of syslog-sign, the hashing and
signature version. But we should call it "VERSION".
(And it should _not_ be binary/base64.)
* Order of fields (first: cookie or VERSION/prio)
It's just cosmetically. But I would prefer when the cookie comes first. And
the versioning second. This seams more natural to me). Any reason, it isn't?
Did I miss something?
* I don't understand the need for 3.2 priority and 3.4 version?
I think (see above) both are a versionID.
The second one can out. The first one should be on the second's place (as
said before)
* How are fields (cookie, *-ID, hashes, ...) separated?
It is clear there is a space after H3.2 priority. But, ...
In H3.2 is mentioned: "1,2 or 3 characters ... with a space".
So its a string like "abc ", or "kl " or "q ".
The total length, with space is 2, 3 or 4 positions.
In H3.1 is stated it ("the priority") is (exactly) 3 bytes.
HOWEVER, ... In H3.1, the size of the other field are also listed without
such a space/separator. Whereas The text in H3.3 .. H3.11 don't mention
anything about a space, or separator.
Does it mean the isn't one? (We just count the positions)
Or is there a space between each field?
Please clarify this (I hope there is a space).
We need the space, whenever we don't use the base64 encoding for
trivial encoded "numbers".
* Can we extent all ID/number field to "UPTO 12 charters"
(without the terminating space)
Then it will be possible to implement it as "yyyymmdd-seq"; which
is easy, and often used. E.g. in DNS SOA records.
Note: it's just an option to implement it. Not an requirement. But
It can be handy, and it's easy to read.
* Can we change all "number" fields, which now have a fixes length
(and are coded base-64) into variable sized field?
In practice, other thy will/can be a small, 1 or 2 digit
decimal number; like "1 " of "13 " (both with terminating space).
It will save (some) space, without the risk of "overflow".
It will make the message more readable too.
* We have 2 separate hash/signature "objects"; but only 1 "marker".
The H3.2 Version denotes which algorithm is used.
However, there are signatures of:
a) the syslog-messages (that we "guard")
b) the syslog-sign signature-blocks (
(i.e. the signature meant in 3.11)
Question: is it needed that both use the algorithm? Or should we allow them
to
be separate. In the later case, we need a second "version" field.
Hope these remarks are clear. Whenever I find more, I will post them.
Please, questions of comment on my remarks as well.
PS. I didn't see any reaction on my proposal to include an XHDR field (with
full DNS name an highres daytime fields, both as "recommendation" for syslog
and as "requirement" for -sign.
Does it mean, everybody agrees??? Or ...
--ALbert
sent mail to [EMAIL PROTECTED], to address me personal.
sent mail to [EMAIL PROTECTED], to address me for businesses
