Re: Syslog-sign: Minor clarifications, part 1

[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