At 11:21 AM +0200 10/1/01, Balazs Scheidler wrote: John may have some comments, too, but here's my comments on your comments:
>I have reviewed the draft and have the following comments: > >- signature blocks description: > "Priority" field is said to be 3 bytes long in the summary, but > details show that it's really 4 bytes (two bytes version, 1 byte hash, 1 > byte signature scheme) > This appears to be correct. John? Chris? Comments? Which part is wrong? >- 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. >- 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. >- 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. 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. >- 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. >- 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. :-).
