On Mon, Oct 01, 2001 at 02:58:06PM -0700, Jon Callas wrote: > At 11:21 AM +0200 10/1/01, Balazs Scheidler wrote: > >- I think some more algorithms should be defined in the priority field: for > > hashes SHA1 seems to be sufficient, but OpenPGP DSA is missing at least > > RSA. > > > > That's pretty much intentional; this is one of those cases where the > correct decision of signing algorithm is DSA. RSA signatures are large. > They're the size of the modulus, so for a 1024 bit key, a signature is 256 > bytes. DSA keys are twice the size of the hash, so they're 40 bytes. You > can fit more of them in a syslog packet.
ok. I'm convinced. > > >- In signature blocks, we have 2 version fields, the first one applying to > > the whole syslog-sign protocol, the second to certificate blocks. I don't > > know whether this understanding is correct, since this is not described in > > the rfc. Do we need so many version fields? Can't we use a single version > > field with several bitfields? And if we do, do we need them to be 16 bits > > wide? > > > >- Another question (I know I was not involved in the development of the > >protocol, so I might > > be whining too much): signature groups are limited to 192 in number. I see > > that 192 comes from the fact there are 192 different priority levels. Do > > we need to drag this limitation to this new protocol? I know that SIG can > > be equal to PRI, but I see this as the special case. > > > > One of the goals of syslog-sign is that it can be added to existing syslog > with no further modifications. So yes, we need to drag this limitation in. I understand that upward compatibility is a must. However the size of a field in an extension message (@#sigSIG) doesn't affect unmodified installations. As I see the signature group ID (I mean the SIG value here) occurs only in this @#sigSIG and @#sigCer. Other than that there's a requirement in Signature Group Descriptor '0' and '1' that SIG = PRI. I think this requires that given '0' or '1' mode is used SIG is limited to 191, otherwise it is a two byte identifier completely unrelated to PRI. > > >- First message number: the description is somewhat unclear to me. Maybe it > > should be reworded a bit. > > > > Sure. Do you have any suggestions? One of my jobs is to be the interpreter > of group consensus. If you can say, "Please change X to Y because Z" then > the vast majority of the time your change goes in. The vaguer your request > is, the harder it is for me to come up with some satisfactory thing to do > with it. Your request is pretty vague. I've read through the section > myself, and while you have to read it rather than skim it, it seems > perfectly clear to me. I can change the wording so that it becomes short > declarative sentences rather then compound wordings, but I have no idea if > that will make you happy or irritated. I'm rewording it a bit, but I'm just > guessing at what will make you happy. The odds are all I'll do is make you > get tired of asking. If you don't like my rewording, give me one of your > own. ok. I understand that my request was vague. I'm not a native English speaker and I'd rather leave wording to those who are. :) > > Here's my rewording: > > This is a 48-bit quantity encoded in base 64 as eight bytes. It contains > the unique message number within this signature group of the first message > whose hash appears in this block. > > For example, if this signature group has processed 1000 messages so far and > message number 1001 is the first message whose hash appears in this > signature block, then this field contains 1001. that's ok. > >- Payload blocks: IP addresses are not 128 bits, unless we are speaking > > about ipv6 > > > > This isn't a bug, it's a feature. There's a trivial encoding of IPv4 > addresses into IPv6 addresses. We need to leave room for IPv6 if we expect > to be on the Standards Track. could a note about this added (possibly with a reference how ipv4 addresses are encoded in ipv6)? > > >- I would define an additional relay, which verifies messages on-line and > > also forwards them (possibly signed again). This would be useful on > > firewalls. > > Is this a standard issue or an operational one? As I think about it, if I > had a syslog relay that receives a syslog-sign stream, it will forward > those packets, and insert its own syslog-sign packets in the stream for > whomever gets them. It's one of the cool things about syslog-sign, that you > can do this indefinitely (or until there's so much UDP packet loss that the > only thing you're getting are downstream signatures, but no actual data. > :-). syslog-ng has an extension to syslog: it adds the current hostname at each hop forwarding the given message. Thus the collector at the end sees which path was used to deliver a given message. I used the "hostname" field to add this information into. This of course requires that a modification on the message, thus signatures become invalid. I imagine the following situation: * a "big" intranet connected to the internet with firewalls * business critical (BC) systems protected from the intranet with firewalls * a dedicated BC system providing management services for all the intranet and all BC systems Each log message must end in the management zone, possibly going through two firewalls. We might have a requirement that we _don't_ forward unauthenticated messages, in order to decrease the burden on the log processing engine in the management zone. Since relays in the scheme above are in fact firewalls, so we might trust them to verify and resign messages. Maybe my situation is special, but these is the reasoning behind my original request. As I see this is permitted by the protocol, so an additional section might not be necessary. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
