Hi, couple of responses:
Regarding the exact data that is to be signed: The intent is in essence to sign the entire message, minus the SDE containing the signature itself. If the phrase of omission of spaces is confusing, we should omit. So basically I agree with Martin; the example given would then be correct. Would the resulting text work better: "The signature is calcluated over the completely formatted Signature Block message, excluding the signature field (SD Pameter Name and the space before it [" SIGN"], "=", and corresponding value)". (in 4.2.8; in 5.3.2.8 replace "Signature Block" with "Certificate Block") Regarding the order of SD parameters within and SDE: I looked at syslog protocol and didn't see specific statements regarding this. I don't see a need for flexibility in the order - not sure what the benefits of that would be; interoperability might be easier to facilitate with a set order. So I would suggest including a statement that the order does matter. For extending the SDE, I would argue that while this can be extended, an extension would imply a new version (so within -01 the SDE is to be used as is). Even within -01, it is not prohibited to carry additional information (e.g. other SDEs) although it is recommended not to do so (states that the syslog message SHOULD NOT carry other Structured Data, and that the MSG part SHOULD be empty) Regarding SDEs occurring only once, this is actually mandated per the syslog protocol. I don't think further clarification is required. --- Alex -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte Sent: Sunday, July 27, 2008 6:47 AM To: [email protected] Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 1 [EMAIL PROTECTED] schrieb: [...] > 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), IMHO this is the desired behaviour. > 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). I have no idea what is meant with "excluding spaces between fields". -- Which fields are referred to? And why should that be useful? I would prefer just to omit the SIGN parameter (and the space). So for example this line is signed: <110>1 2008-07-27T14:54:11.020331+02:00 host.example.com syslogd - - [ssign VER="0121" RSID="1217163210" SG="3" SPRI="0" GBC="39" FMN="381" CNT="10" HB="hsal3vls9LYYmILWrRMmDCfXZyNiPZZftv1pCq99SFk= D9aHiwq402fGcQZbJvJokhYWcneWypmdQN5lzlEUe4k= u0PrH7zDcNaQxnTZw1qu5yuE7MmPpGsh2pPMhyWJlMA= 1jcrmsNxVFqn1hYAhdKhZKC2iRibECdqQXwSeR6rfnM= Rg9xSrmaRZgDbQIyTIN8F9kwMAZsOWk7JDy3vZBshlI= Cbf5sknv2zW/pT/OQ+yFh1Ge2Hnn9vaiAU8NeQlwTbA= Kl+hnkGOVcMp+iTQ2StbG3g1Sa4sUS6fcBR3z6+/eqY= MgOdm1ad/Gkm/emuyPNyKThYQVT9s6W8fk7yqJoid+Y= FUY1mt13kFPyoA7yyiR/kIX1dWXXRSahxUMn8rxfunI= az/IpvjG1egbXr2xj0hPfCxKGWpAwbdHMkTjcznOpxQ="] And after inserting the signature this will be sent: <110>1 2008-07-27T14:54:11.020331+02:00 host.example.com syslogd - - [ssign VER="0121" RSID="1217163210" SG="3" SPRI="0" GBC="39" FMN="381" CNT="10" HB="hsal3vls9LYYmILWrRMmDCfXZyNiPZZftv1pCq99SFk= D9aHiwq402fGcQZbJvJokhYWcneWypmdQN5lzlEUe4k= u0PrH7zDcNaQxnTZw1qu5yuE7MmPpGsh2pPMhyWJlMA= 1jcrmsNxVFqn1hYAhdKhZKC2iRibECdqQXwSeR6rfnM= Rg9xSrmaRZgDbQIyTIN8F9kwMAZsOWk7JDy3vZBshlI= Cbf5sknv2zW/pT/OQ+yFh1Ge2Hnn9vaiAU8NeQlwTbA= Kl+hnkGOVcMp+iTQ2StbG3g1Sa4sUS6fcBR3z6+/eqY= MgOdm1ad/Gkm/emuyPNyKThYQVT9s6W8fk7yqJoid+Y= FUY1mt13kFPyoA7yyiR/kIX1dWXXRSahxUMn8rxfunI= az/IpvjG1egbXr2xj0hPfCxKGWpAwbdHMkTjcznOpxQ=" SIGN="39tqZ4p5aWaUs4IOhTRfVT2f95E="] > Section 4.2 and 5.3.2: Are the SD-PARAMs always in this order, or can > they be in any order? I had the impression that the order of SD-PARAMs (and SD-ELEMENTs) should always be considered arbitrary and irrelevant for interpretation, but now that I am looking for it I do not find that in syslog-protocol :-/ > Is it possible that some extension > will later add new SD-PARAMs to these SD-IDs -- if so, how old > implementations should handle them? I think it should be possible to extend the SDs and the exact set of SD-PARAMs should depend on the VERsion. BTW, should it be explicitly required that every SD-PARAM occurs once? It seems obvious, but syslog-protocol allows repeated parameters... -- Martin _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
