Sections 4 and 5: The document is a bit vague on how the DSA signature is encoded in the Signature Block; it talks about "OpenPGP DSA" (which might mean the "two MPIs" encoding in RFC 4880), but this is different than the encoding used in most IETF protocols (DER encoding of SEQUENCE of two INTEGERs). Which one is it?
Section 4.2.8 and 5.3.2.8: The text needs to be clearer about the exact data which is signed. Does this mean a complete SYSLOG-MSG (including MSG and other structured data after "ssign", if any), except that STRUCTURED-DATA does not yet contain the SIGN parameter (and the space separating it from the previous parameter)? Also, excluding spaces here seems really strange -- after all, they're included when calculating hashes -- and would seem to complicate implementation (also, it's not totally obvious what spaces exactly would be excluded). Section 4.2 and 5.3.2: Are the SD-PARAMs always in this order, or can they be in any order? Is it possible that some extension will later add new SD-PARAMs to these SD-IDs -- if so, how old implementations should handle them? Section 5.2, key blob type 'P': RFC 2440/4880 don't clearly define what an "OpenPGP certificate" is -- does this mean "Transferable Public Key" (RFC 4880 Section 11.1)? Section 5.2, key blob type 'K': what algorithm, encoded how? Section 5.3.2.*: are the various lengths/indexes referring to the raw data (before base64 encoding), or to the data that's actually sent (after base64 encoding)? Section 5.3.2.5: numbering the first octet "1" is highly unusual in IETF protocols -- if this is intentional, perhaps a note highlighting this would be useful. Section 6.1.1/6.1.2: I'm having some difficulties in understanding exactly how the delay/count parameters are supposed to be used. This text probably needs some clarification. Section 6.2: It wouldn't hurt to repeat the requirement that the payload block isn't changed. Section 8.5: Using TLS/TCP doesn't mean messages can't be lost (see syslog-transport-tls draft, Section 6.3, for details); perhaps should be pointed out here, too. Best regards, Pasi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
