[EMAIL PROTECTED] schrieb:
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?
From an implementation perspective I would like to use DER encoding for
keys (key blob type 'K') and signatures. I think that covers all
key/signature types (even beyond DSA) and is supported by all common
libraries.
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
