Hai All,
I agree with Chris, this draft is looking good!
I've found some small mistakes, witch are shown below.
Also I would like to discuss a (little) "major" change.
Both to make syslog(-sign) more future proof, and to make the reading of the
MSG part even better. It's about introducing a OPTIONAL extra field: XHDR.
But more on that below.
SMALL MISTAKES/CHANGES
* On page 7, the 3 allowed characters ([,],:) aren't proper listed. The
digits after %d are missing.
(sorry, I don't have them here)
* Section 2.3 (MSG part) speaks about "2 message types will be defined".
Either insert the word "special"; or use "3 types".
In syslog-sign, we really have 3 type's of messages:
1) The normal messages, that contain the "log data" the sender
2) Special syslog-sign messages that carry the signatures
3) Special syslog-sign messages that carry the certificates (or key's)
* The numbering of the (sub)section is a little out of order. See e.g. the
ToC
It is hard to find where e.g. (above called) message 2 of 3 is defined. And
which sub-field are part which message type.
My proposal: Insert 2.5 "General layout of syslog-sign messages", which
introduces the names of the 2 special type of messages.
The use H3 and H4 to define those messages, and names (those sections) to
them.
Both H3 and H4 can then more or less use the same sub-numbering: .1 General
.2 field (.2.* $name) .3 building the block
By this the rfc becomes (to my opinion) more readable.
The text of the RFC has hardly to change, only the numbering and
sectionheaders.
SOME remarks on Chris':
> It addresses the comments made that the TAG field should be in the HEADER
rather than in the CONTENT.
I'm also very glad about this! It improves the orginal rfc! Thanks
> What if we broke down the TAG into components that would
> indicate the version and the cookie? Perhaps something like:
> TAG = syslogsignL[pid]:
Personally, I agree with Chris: the TAG shouldn't be "syslog". At least
insert something with "secure" oid.
But I'm questioning Chris proposal to store information in it. Keep is a
constant!
A lot of syslogd (read: a relay/receiver) read this field and use it for
relaying. E.g. to store all messages that are coming van _MyProg_ to another
file.
See e.g. the manpage of FreeBSD syslog.conf (the call it "PROG")
When the TAG isn't a constant, it becomes hard not to break anything. And it
becomes more difficult to manage such systems as well.
> The [pid]: is as we've always known it and could denote the
> current syslogsign or syslogd process.
That is not correct! It should be the processno of the program (the
device/sender), not that of the deamon!
The signatures will be generated in the syslog-lib (within libC in most
systems!)
> I'd also like to
> see the value remain human readable on the wire rather than
> converting it to base 64.
Although out of context; this is important!
RFC3164 demand's human readable text. With signature's this isn't possible
al the time. But when possible, we should stick to this! Always! (so I
agree with Chris)
PROPOSED CHANGE: An extra field is syslog
Intro: As we have described in rfc3164 for some systems, the HOSTNAME and
DATE field in the HEADER do no carry all needed information: No DNS name, no
year, no milliseconds. As we can't put them in the HEADER, the are put in
(the start of) the MSG part (after TAG). By a lot of systems.
For normal syslog, this will do, as it is just text and so it's valid in de
MSG. So it will do for syslog-sign too.
However, I think it would be wise to extent the special syslog-sign messages
with these field. And instead of just add the "somewhere". I would prefer to
do it structural:
When we define an optional field in each syslog message: XHDR, between the
HEADER (with TAG) and the MSG part. And use that field to store those extra
bit's, we document (for new implementations) in which order those extra
information should be
And we can use that definition ourselves in the special syslog-sign
messages.
To do so, we need some extra text in H2.0 (mention the field), on H2.2
halfway page 6 (reference it). And add a section (between 2.2 & 2.3 to
describe this optional field. Also an example in (now) 2.4 will be needed.
In those sections it will be a optional field with a recommended order. In
H3 (or H2.5: "General layout", see above) that field should be recommended,
or better, required
Wehn we agree with this improvement. I'm willing to donate the proposed
textchanges.
--ALbert
sent mail to [EMAIL PROTECTED], to address me personal.
sent mail to [EMAIL PROTECTED], to address me for businesses
