Subject: [Syslog] Syslog-sign: Minor clarifications, part 1

From: <[email-masked]>
Date: Wed, 23 Jul 2008 15:37:37 +0300

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-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: Martin Schütte <[email-masked]>
Date: Sun, 27 Jul 2008 15:47:04 +0200

> 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.

> (including MSG and other structured data after "ssign", if any),

IMHO this is the desired behaviour.

> implementation (also, it's not totally obvious what spaces exactly

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="]

> 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

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