Hai all,
As said before, I'm implementing a open source versions of syslog-sign.
Last week I have given a presentation about it at the EuroBSDCon-2002
(See http://2002.eurobsdcon.org/papers/#mietus).
This (simple) implementation is working, but needs be tested a bit more
before releasing (But mail me for info/src).
Another thing what needs to be done is clearing up the draft. There are
(small) parts of the RFC that aren't clear into detail.
I have made a list of "mistakes/missing part" of the draft-07
That list is shown below.
I hope this will help
NB I wasn't able to "be" at the last IETF55 ;-) Nor was I able to
attent the electronic session. And, due to de stress of the meeting of
Eurobsdcon, I did forget to post this before Nov 19. -- Sorry
----------------
** A Signature Block contains a signature. of itself
There is a (at least) 1 space between the signature and
the hashes before it.
Q: Should the hash/signature be calculated including or
excluding those spaces
** All fields in Signature an Certificate Block should be
separated by space
Adv: It should be exactly 1 space, except before a (terminating)signature;
where 2 spaces are recommended
** Same as above (twice) for Certblocks
** The rfc defines the Fragment Length (field G) of the CertificateBlock
as base64 coded. This seams wrong, as it is a normal, printable number.
(The rfc says that base-64 is only used for binary values, generally)
** The rfc is not uniform in "counting" spaces. Sometimes a terminating space
is part of a field, and the length of the field is "extended" with 1.
Sometimes, the space is situated between 2 field. And the
length(s) count the actual (non-space) content.
Often, it is not clearly specified.
Adv: Always define the space as "between", for Payload, Certificate en
Signature Blocks (not for "normal", rfc3164) messages.
Adv: use "MUST be separated by spaces" ..."RECOMMENDED is to use 1
space, (except as written above)". "receivers/validators MUST
accept any number of spaces.
** The TAG is defined to be ending ('MUST')with a _colon_.
This wrong, as rfc3164 defines it can end with a _space_
Adv Rewrite: it terminates with any not alfanum char.
** I think, it should be "better" to show a signature Block
in an example, not "normal" messages
** Make a note about NOT terminating base-64 coded fields with a
newline. This is normally done in base-64. A short remark can
simplify the implementator's job
** In 3.5 and in 4.2.c (ii) & (ii), is specified PRI should be "XXX"
Rfc3164 does not allow this!
(and so it can't be used here. as all messages should be
processable by rfc3164-compliant syslog(d)'s.
