Snipping out the agreements, and taking dbh's point about this I-D being in A-D Evaluation and so may be beyond comment:-), see inline
Tom Petch ----- Original Message ----- From: "Miao Fuyou" <[EMAIL PROTECTED]> To: "'tom.petch'" <[EMAIL PROTECTED]>; "'Rainer Gerhards'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 10, 2008 12:00 AM Subject: RE: [Syslog] transport-tls-11 review > > Thanks for your comments! Response inline. > > > -----Original Message----- > > From: tom.petch [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 28, 2007 9:13 AM > > To: Miao Fuyou; 'Rainer Gerhards'; [EMAIL PROTECTED] > > Subject: Re: [Syslog] transport-tls-11 review > > > > The server MUST be implemented to support certificate and > > certificate > > generation, and certificate validation MUST be implemented for all > > clients. The Syslog client SHOULD be implementated to > > support **implemented > > certificate and certificate generation, and certificate validation > > SHOULD be inplemented for Syslog server. > > > > **These both read oddly to me - what is the support for certificate > > (certificates?) as distinct from support for certificate > > generation and certificate validation? If I support > > certificate (without qualification), then I expect that to > > convey support for every aspect thereof so the validation and > > generation is redundant but, as I agreed with Rainer above, I > > think that generation should not be a MUST. > > There are two way for a server to have a certificate: be configured with > one, or generate one by itself. The "support certificate" is actually to > cover the first case. I agree that is not a exact terminology. What is your > suggestion? > Weell, by certificate validation I mean following a chain of certificates back until one reaches a trusted certificate, such as a root CA or trust anchor. OK, many - most? - people don't do that but I am not sure we should connive with them. I prefer certificate validation and certificate generation. RFC2828 is a fun read for this. > > > > Since a receiver may act upon received data, for syslog over > > TLS, it is recommended that the server authenticate the client to > > ensure that information received is authentic. > > > > **this seems to weaken the claim earlier that TLS defends > > against the listed threats - by now I am feeling confused > > about what protection is being offered by what. To meet the > > claims of s.2, I think we need both server and client to > > check certificates for suitable identities and to follow a > > chain to a trust anchor - I have no problem with describing > > other scenarios but think that each such scenario should then > > be qualified with a comment to the effect that this MAY not > > defend against threats ... as identified in s.2 > > Perhaps "authentic" is not an exact term, how about "it is recommended that > the server authenticate the client to ensure that information received is > from trusted client." > suggest " it is recommended that the server authenticate the client to confirm the identity of the client from which the information is received." or something similar, that is that (any kind of) authentication authenticates an identity that the other party is asserting, no more; trusted involves rather more than that, that is having confirmed what the identity is, then that identity is one that can be trusted. Authentication may be 100% successful after which you have established that the client is totally untrustworthy and that this is a phishing attack:-) Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
