Hi,
In the following,
[14] is syslog-protocol
[15] is syslog-transport-udp
[16] is syslog-transport-tls
===
Last paragraph in the Introduction
This specification is independent of the actual transport protocol
selected. The mechanism is especially suitable for use with the
syslog protocol as defined in RFC xxxx [14] because it utilizes the
STRUCTURED-DATA elements defined in that document. It may also be
used with syslog packets over traditional UDP [4] as described in RFC
3164 [10]. It may also be used with the Reliable Delivery of syslog
as described in RFC 3195 [11], and it may be used with other message
delivery mechanisms. Designers of other efforts to define event
notification mechanisms are encouraged to consider this specification
in their design.
Would it be better to RECOMMEND this mechanism be used with [14]? That
would be consistent with the RECOMMENDation in Section 3.
===
Fourth paragraph in Section 3:
When used in conjunction with RFC xxxx [14], the syslog messages
defined in this document carry the signature and certificate data as
STRUCTURED DATA, as defined, while the MSG part of the syslog
messages is simply empty - the contents of the messages is not
intended for interpretation by humans but by applications that use
those messages to build an authenticated log.
Would it be better to state that the MSG part of the message MUST be
empty? It's suggested here but not explicitly stated.
===
From Section 4.1
A Signature Block message that is compliant with RFC xxxx [14] MUST
contain valid APP-NAME, PROCID, and MSGID fields. Specifically, as
value for APP-NAME, "syslog" (without the double quotes) MUST be
used. As value for MSG-ID, "sig" (without the double quotes) MUST be
used. As value for the PRI field, 110 MUST be used, corresponding to
facility 13 and severity 6 (informational). The Signature Block is
carried as Structured Data within the Signature Block message, per
the definitions that follow in the next section.
Perhaps restructure that as:
A Signature Block message that is compliant with RFC xxxx [14] MUST
contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the
value for APP-NAME MUST be "syslog" (without the double quotes).
The value for MSG-ID MUST be "sig" (without the double quotes). The
value for the PRI field MSUT be 110, corresponding to facility 13
and severity 6 (informational). The Signature Block is carried as
Structured Data within the Signature Block message, per the
definitions that follow in the next section.
Similar in Section 5.3.1.
===
Section 4.2.7 gives the definition of the syslog message that needs to
be hashed:
starting with the < of the PRI portion of the header part of the
message and ending with the Unicode byte order mask, BOM.
That needs to be changed as the BOM is not the end of the message.
===
The count for ssign is a maximum of 2-bytes and is a value of between 1
and 99. This will likely fit into a message with a length of 2048 octets
as stated in Section 4.2.7 if the hashes are 160-bytes. Is this
acceptable to the group? We started this with the idea that this
mechanism would be run atop RFC 3164 with a maximum length of 1024 octets.
However, would a greater efficiency be gained by increasing the length of
the syslog-sign message and the length of the Count?
===
The word "monotonically increasing" is used in a few places. I think that
we're actually trying to say "sequentially increasing".
===
The SD-ID values in Section 9 (IANA Considerations) need to be in tables
so that the IANA can cut-n-paste.
===
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
